Daemons não iniciam durante o boot no PUIAS (RedHat) 6.4

Question

Eu sou totalmente Linux n00b com vários servidores e desktops PUIAS (RedHat) 6.4. Percebi depois de reiniciar os nós de computação (feitos apenas para fins de teste) que muitos dos daemons que são iniciados manualmente após a instalação inicial (ipmi, mcelog, fail2ban) não estão em execução e precisam ser reiniciados manualmente. Este servidor deve ser executado no nível de execução 3 (sem GUI). Exercício semelhante na mesma versão do SO nos desktops (nível 5) produz resultados totalmente diferentes. Ou seja, todos os daemons são iniciados corretamente.

Isso é exceção e devo editar os scripts /etc/init.d ou talvez apenas escrever os meus que iniciarão os serviços? Existe a outra maneira "correta" de fazer isso?

Eu venho do mundo do OpenBSD, onde os daemons build são simplesmente visualizados editando o /etc/rc.conf.local e todos os outros daemons são iniciados editando o /etc/rc.local.

    

Answer 1

(Eu não estou tentando ser pedante, eu só não sei o quanto você sabe ou não sabe, então eu estou basicamente braindumping aqui)

Primeiro, saiba que a Red Hat escolhe coisas estranhas para instalar e habilitar por padrão. Por exemplo, é RHEL5 ou RHEL6 que instalará avahi e permitirá que ele inicie na inicialização. Acho que ambas as versões instalam e ativam cups para quase todos os perfis de instalação que você pode escolher. O RHEL6 não instala man por padrão, etc, etc.

No RHEL, existem três maneiras de gerenciar serviços:

• Modifique manualmente os links simbólicos abaixo de /etc/rc.d ou /etc/rcX.d
• Use chkconfig (modelado após a ferramenta do IRIX com o mesmo nome)
• use o comando setup fornecido pelo pacote setuptool (que pode ou não ser instalado dependendo do perfil que foi selecionado durante a instalação inicial).

Mais detalhes sobre cada um:

Gerenciamento manual:

A seqüência de inicialização do RHEL / System V é assim:

1. /etc/rc.sysinit é executado, o que obtém a maioria das partes críticas do sistema operacional, como sistemas de arquivos críticos em vigor.

2. init , em seguida, analisa /etc/rcX.d (onde X para o nível de execução que está sendo inicializado) e executa todos os arquivos / links simbólicos contidos nele (em ordem alfabética).

   • Se o nome deles começar e S , o script start será exibido como argv[1] / $1

   • Se o nome deles começar com K , ele pára (ou kills ) o serviço.

   • A convenção diz que as dependências são tratadas alterando o número após o K ou S , que tem o efeito de apenas alterar sua posição alfabética.

3. Executa o que quer que esteja em /etc/rc.local

Os scripts de serviço reais estarão em /etc/rc.d/init.d (que também é linkado com symlink em /etc/init.d ). Se você quiser que um serviço inicie no nível de execução 3 (rede, mas sem GUI), poderá fazer isso:

# cd /etc/rc3.d
# ln -s /etc/init.d/myService S99myService

Usando o chkconfig

O objetivo de chkconfig é basicamente automatizar o processo acima para você. Ele tem a desvantagem de exigir que os initscripts tenham um determinado cabeçalho antes que você possa gerenciar o serviço com chkconfig . Por exemplo, este é o início do serviço de rede:

#! /bin/bash
#
# network       Bring up/down networking
#
# chkconfig: 2345 10 90
# description: Activates/Deactivates all network interfaces configured to \
#              start at boot time.
#
### BEGIN INIT INFO
# Provides: $network
### END INIT INFO

Isso habilita chkconfig e calcula o número necessário para definir / modificar para que as dependências funcionem corretamente. Você perde a capacidade de mudar a ordem, mas, por causa do que precede, dificilmente importa.

chkconfig é mais fácil e é francamente o que eu uso na maior parte do tempo.

Você pode verificar quais serviços estão configurados em quais níveis de execução via chkconfig --list Por exemplo:

[root@ditirlns01 ~]# chkconfig --list | head
NetworkManager  0:off 1:off 2:off  3:off  4:off 5:off  6:off
acpid           0:off 1:off 2:on 3:on   4:on   5:on 6:off
anacron         0:off 1:off 2:on 3:on   4:on   5:on 6:off
arptables_jf    0:off 1:off 2:on 3:on   4:on   5:on 6:off
atd             0:off 1:off 2:off  3:off  4:on 5:on 6:off
auditd          0:off 1:off 2:off  3:off  4:off 5:off  6:off
autofs          0:off 1:off 2:off  3:off  4:on 5:on 6:off
avahi-daemon    0:off 1:off 2:off  3:off  4:on 5:on 6:off
avahi-dnsconfd  0:off 1:off 2:off  3:off  4:off 5:off  6:off
capi            0:off 1:off 2:off  3:off  4:off 5:off  6:off

Ou verifique o status de determinados serviços:

[root@ditirlns01 ~]# chkconfig --list auditd
auditd          0:off 1:off 2:off  3:off  4:off 5:off  6:off

Você pode ativar um serviço usando chkconfig <serviceName> on Continuando o exemplo acima:

[root@ditirlns01 ~]# chkconfig auditd on
[root@ditirlns01 ~]# chkconfig --list auditd
auditd          0:off 1:off 2:on 3:on   4:on   5:on 6:off

Como você pode ver, chkconfig habilite o serviço auditd para os níveis de execução de 3 a 5.

Se você não quiser, pode usar a opção --levels para definir níveis de execução específicos para ativar:

[root@ditirlns01 ~]# chkconfig auditd off
[root@ditirlns01 ~]# chkconfig auditd on --levels=3
[root@ditirlns01 ~]# chkconfig --list auditd
auditd          0:off 1:off 2:off  3:on 4:off  5:off   6:off

Com o setuptool

setup é a mais recente iteração do gerenciamento do sistema, projetada para facilitar um pouco as tarefas administrativas comuns. Funcionaria dessa maneira se a Red Hat instalasse tudo o que fosse necessário para fazê-lo. Mas começando com RHEL6 eles separaram a funcionalidade setuptool entre vários pacotes (eu acho que para torná-lo mais abrangente, sem entupir o menu).

É um wrapper baseado em ncurses bastante auto-explicativo em torno de chkconfig , exceto que ele não permite destacar níveis de execução específicos:

Não há muito a dizer sobre isso além disso.

Deixe-me saber se isso respondeu à sua pergunta.