Linux - Guia prático para administradores de sistemas/Inicialização do sistema

Origem: Wikilivros, livros abertos por um mundo aberto.
Saltar para a navegação Saltar para a pesquisa

Objetivo[editar | editar código-fonte]

O propósito deste capítulo é explicar como um servidor utilizando o GNU/Linux é inicializado desde a etapa de inicialização do hardware, até o momento que o processo init é inicializado, os scripts de inicialização são executados e o servidor esteja completamente operacional, o processo getty iniciado à espera de logins.

Inicializando o Sistema[editar | editar código-fonte]

O processo de inicialização de sistemas, independentemente do sistema operacional, depende em muito do tipo de hardware em uso. Em dispositivos baseados na arquitetura x86 (intel) quando o computador é inicializado ou reinicializado o processador (CPU) executa uma operação em uma área ( endereço ) conhecido na memória não volátil (flash RAM).


No caso de PCs (Personal Computers) baseados na arquitetura x86, o processo de inicialização (boot) se inicia na BIOS, no endereço 0xFFFF0. O primeiro passo da BIOS é executar o Power On Self Test (POST) que tem como principal função a verificação do hardware e a enumeração e inicialização dos dispositivos locais.


Para inicializar o sistema operacional, a BIOS irá então procurar por dispositivos ativos e válidos que estejam listados (em ordem de preferência) na CMOS (boot device). Os dispositivos de boot podem ser floppy disks, hard disks, flash drivers, dispositivos de rede, etc.


De maneira geral, o Linux é inicializado a partir de um disco rígido, onde a MBR ( Master Boot Record ) contém o boot loader, mas não o kernel. A MBR é apenas um setor de 512 bytes, localizado no cilindro 0, setor 1 do seu disco rígido, e portanto não teria condições de abrigar um kernel Linux, mesmo que comprimido. Portanto na MBR apenas reside o suficiente para carregar o primeiro estágio do boot loader.

Boot Loader - Estágio 1[editar | editar código-fonte]

O primeiro estágio do boot loader, ou primary boot loader, localizado nos setores restantes do primeiro cilindro. A única função do primary boot loader é encontrar o secondary boot loader, ou o segundo estágio do boot loader, e carregá-lo na memória. O objetivo do primeiro estágio é usar um programa pequeno que lê em um unico sistema de arquivos.
No GRUB esse estágio é conhecido como 1.5 o e o estágio 1 é o código que é escrito no MBR .

Boot Loader - Estágio 2[editar | editar código-fonte]

O segundo estágio de boot tem como função carregar o kernel do Linux na memória, e opcionalmente um arquivo que simula a memoria RAM (RAM image file).


Os 2 estágios do boot loader combinados formam o LILO ( Linux Loader ) ou o GRUB ( GRand Unified Bootloader ). Iremos nos focar no GRUB, devido ao fato deste ser um gerenciador de boot mais novo, e que corrigiu algumas das falhas do LILO.


No estágio 2 é possível listar e escolher entre diversos tipos de kernel instalados (definidos em /boot/grub/menu.lst), e inclusive passar parâmetros de boot durante a inicialização do sistema.


Quando o segundo estágio estiver carregado na memória o sistema de arquivos é consultado, a imagem do kernel e a imagem initrd são carregados na memória, e quando esse processo é concluído, o boot loader invoca o kernel.

Carregando o Kernel[editar | editar código-fonte]

A imagem do kernel não é propriamente um executável, porém contém uma série de rotinas que permitem que o kernel que se encontra comprimido (zlib) seja expandido, e carregado na memória.


Não pretendemos aqui esmiuçar todas as etapas desse processo, no entanto é importante notar que durante a carga do kernel, a ram image que foi carregada durante o estágio 2 do boot loader é montado temporariamente como root file system, contendo todos os drivers necessários para que o kernel tenha acesso aos diversos dispositivos que ele precise.


Esse mecanismo permite que tenhamos imagens de kernel pequenas, e device drivers compilados como módulos e carregados, quando necessários, através de um arquivo que pode ser montado como um sistema de arquivos existente apenas na memória. Tal artifício permite que o kernel seja completamente carregado sem que um disco físico seja de fato acessado. Em uma etapa futura da carga do kernel, esse sistema de arquivos temporários será substituído pelo root file system padrão.


Esse mecanismo garante uma grande flexibilidade a sistemas Linux uma vez que permite inclusive que o próprio root file system resida em um servidor remoto (NFS).

Threads do Kernel[editar | editar código-fonte]

Após a inicialização básica, o kernel cria também vários processos no espaço de usuário. Estes aparecem na listagem de diretórios entre colchetes, a exemplo do [kswapd], [kjournald], etc. Destes processos que aparecem no inicio da listagem de processos, normalmente com números identificadores baixos, 1 (init), 2, 3..., apenas o init é um processo de usuário completo, os demais são na verdade partes do kernel que por razões de escalonamento foram organizados para se parecer com processos. Assim que as threads do kernel são criadas, o papel destes na inicialização termina, e o processo de ativação de todos os outros serviços fica a cargo do init através de scripts de inicialização.


A nomenclatura do processo na coluna CMD corresponde a [NomeDoProcesso/Numero], onde Numero significa o processador em que o processo está alocado.


linux:/etc/init.d # ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0  2008 ?        00:00:59 init [3]
root         2     1  0  2008 ?        00:00:00 [migration/0]
root         3     1  0  2008 ?        00:01:13 [ksoftirqd/0]
root         8     1  0  2008 ?        00:07:45 [events/0]
root        11     1  0  2008 ?        00:00:00 [khelper]
root        12     1  0  2008 ?        00:00:00 [kthread]
root        22    12  0  2008 ?        00:00:06 [kblockd/0]
root        63    12  0  2008 ?        00:00:00 [cio_chp]
root        64    12  0  2008 ?        00:00:00 [cio]
root        65    12  0  2008 ?        00:00:00 [cio_notify]
root        66    12  0  2008 ?        00:00:00 [kslowcrw]
root       117    12  0  2008 ?        00:00:00 [appldata]
root       131    12  0  2008 ?        00:01:30 [pdflush]
root       132    12  0  2008 ?        00:00:12 [pdflush]
root       133     1  0  2008 ?        00:01:16 [kswapd0]
root       134    12  0  2008 ?        00:00:00 [aio/0]
root       140    12  0  2008 ?        00:00:00 [cqueue/0]
root       160     1  0  2008 ?        00:00:00 [kmcheck]
root       388     1  0  2008 ?        00:00:17 [kjournald]
root       437     1  0  2008 ?        00:00:03 /sbin/udevd --daemon
root       707     1  0  2008 ?        00:00:00 /usr/sbin/vsftpd
root      1405     1  0  2008 ?        00:00:00 [kjournald]
root      1407     1  0  2008 ?        00:00:01 [kjournald]
root      1409     1  0  2008 ?        00:00:05 [kjournald]
root      1411     1  0  2008 ?        00:03:24 [kjournald]
root      1413     1  0  2008 ?        00:00:02 [kjournald]
root      1415     1  0  2008 ?        00:00:00 [kjournald]
root      1417     1  0  2008 ?        00:00:00 [kjournald]
...


O Processo INIT
[editar | editar código-fonte]

Após a carga e inicialização, o kernel inicia o primeiro programa em user space. Até esse momento, nenhuma outra aplicação baseada em blibliotecas padrão C é executada.


De modo geral, em desktops e servidores linux padrão, após a carga do kernel, o programa /sbin/init é executado, porém isso não é obrigatório. Dispositivos embarcados, por exemplo, não requerem uma inicialização extensiva através do init. É possível por exemplo, após a inicialização do kernel, iniciar um utilitário shell e a partir deste iniciar os processos necessários.


O arquivo de configuração que determina o funcionamento do processo init é o /etc/inittab, entretando pelo fato desse arquivo não ter uma sintaxe fácil de compreender, as distribuições Linux atuais utilizam-se deste para, a partir de um processo (/etc/init.d/rc), determinar o conjunto de scripts que deverão ser executados, dependendo do runlevel escolhido.


Por padrão esses scripts são armazenados sob a estrutura de diretórios /etc/rc.d/rc[0-6,S].d/ e são na verdade scripts simples, baseados em sh (base na verdade) com a função de além de realizar configurações simples durante o processo de boot (hostname, endereço ip, rotas, etc) também são responsáveis por iniciar, parar e reiniciar os daemons que devem ficar em execução no servidor.


No decorrer do processo init, o programa getty é invocado e executado a partir do arquivo de configuração /etc/inittab com a finalidade de abrir conexões ttys (sejam dispositivos reais ou virtuais localizados em /dev) como por exemplo: consoles virtuais, portas seriais, portas do modem, dentre outros, e iniciar a autenticação do usuário chamando o processo login, o qual fica no estado de espera, aguardando o nome do usuário e senha. Caso as informações estejem corretas, uma conexão tty será liberada para o usuário autenticado.

Níveis de Execução (runlevel)[editar | editar código-fonte]

0 - Nível em que o sistema está completamente desligado

1 ou S - representa o modo de monousuário

2 - Primeiro modo multiusuário (sem rede)

3 - Modo multiusuário

4 - Não Usado ( "definível" )

5 - Modo multiusuário (X11)

6 - Reboot (Nível onde o sistema ficará reinicializando)

GRUB : O GRand Unified Boot Loader[editar | editar código-fonte]

O GRUB é o gerenciador de boot mais popular nos dias atuais, e também o padrão das maiores distribuições Linux existentes ( Suse, RedHat, Fedora ). A vantagem mais perceptível do GRUB é que ele transformou o processo usual de 2 estágios em um processo de 3 estágios (1, 1.5 e 2), onde no estágio intermediário ( 1.5 ) o boot loader toma conhecimento do sistema de arquivos onde o kernel reside e não mais acesso a um setor "raw" do disco rígido. Não requer, como o LILO, que o setor de boot seja atualizado a cada modificação no arquivo de configuração. Após o GRUB ser instalado no setor de boot (MBR) com o  comando grub-install o seu arquivo de configuração será lido a cada inicialização, o que garante uma maior flexibilidade a esse gerenciador de boot.


O GRUB não faz distinção entre discos IDE e SCSI, ou seja, existe uma referência na ordem de como os discos são reconhecidos na BIOS influenciando na nomenclatura dos dispositivos válidos no GRUB, por exemplo, se um servidor tiver 02 discos rígidos IDE, 01 SCSI e 01 floppy disk, o GRUB identificará da seguinte forma:

--> Primeiro disco: IDE ( hd0 )

--> Segundo disco: IDE ( hd1)

--> Terceiro disco: SCSI ( hd2 ) 

--> Floppy Disk: ( fd0 )

Nesse exemplo, caso o segundo disco tenha 02 partições, a representação pelo GRUB será: (hd1,0) e (hd1,1).

Como instalar o GRUB no disco master da controladora IDE primária?

grub-install '(hd0,0)'


Exemplo de um arquivo de configuração GRUB (/boot/grub/grub.conf)

default=0
timeout=10
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
title OpenSuse 11.0
     root (hd0,0)
     kernel /boot/vmlinuz-2.6.9-5 ro root=/dev/hda1
title WindowsXP
     rootnoverify (hd0,0)
     chainloader +1

Scripts de Inicialização [editar | editar código-fonte]

Exemplo do script de inicialização do sshd:


Observação: O campo # Default-Start, no exemplo abaixo, significa que os valores padrões para a inicialização do serviço de sshd pelo script de inicialização, serão os níveis de execução 3 e 5. No campo # Default-Stop, informa que esse serviço estará parado quando os níveis de execução forem 0, 1, 2 e 6.

#! /bin/sh
# Copyright (c) 1995-2000 SuSE GmbH Nurenberg, Germany.
#
# Author: Jiri Smid <feedback@suse.de>
#
# /etc/init.d/sshd
#
#   and symbolic its link
#
# /usr/sbin/rcsshd
#
### BEGIN INIT INFO
# Provides: sshd
# Required-Start: $network $remote_fs
# Required-Stop: $network $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start the sshd daemon
### END INIT INFO

SSHD_BIN=/usr/sbin/sshd
test -x $SSHD_BIN || exit 5

SSHD_SYSCONFIG=/etc/sysconfig/ssh
test -r $SSHD_SYSCONFIG || exit 6
. $SSHD_SYSCONFIG

SSHD_PIDFILE=/var/run/sshd.init.pid

. /etc/rc.status

# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_failed        set local and overall rc status to failed
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status

# First reset status of this service
rc_reset

case "$1" in
    start)
        if ! test -f /etc/ssh/ssh_host_key ; then
            echo Generating /etc/ssh/ssh_host_key.
            ssh-keygen -t rsa1 -b 1024 -f /etc/ssh/ssh_host_key -N ''
        fi
        if ! test -f /etc/ssh/ssh_host_dsa_key ; then
            echo Generating /etc/ssh/ssh_host_dsa_key.

            ssh-keygen -t dsa -b 1024 -f /etc/ssh/ssh_host_dsa_key -N ''
        fi
        if ! test -f /etc/ssh/ssh_host_rsa_key ; then
            echo Generating /etc/ssh/ssh_host_rsa_key.

            ssh-keygen -t rsa -b 1024 -f /etc/ssh/ssh_host_rsa_key -N ''
        fi
        echo -n "Starting SSH daemon"
        ## Start daemon with startproc(8). If this fails
        ## the echo return value is set appropriate.

        startproc -f -p $SSHD_PIDFILE /usr/sbin/sshd $SSHD_OPTS -o "PidFile=$SSHD_PIDFILE"

        # Remember status and be verbose
        rc_status -v
        ;;
    stop)
        echo -n "Shutting down SSH daemon"
        ## Stop daemon with killproc(8) and if this fails
        ## set echo the echo return value.

        killproc -p $SSHD_PIDFILE -TERM /usr/sbin/sshd

        # Remember status and be verbose
        rc_status -v
        ;;
    try-restart)
        ## Stop the service and if this succeeds (i.e. the
        ## service was running before), start it again.
        $0 status >/dev/null &&  $0 restart

        # Remember status and be quiet
        rc_status
        ;;
    restart)
        ## Stop the service and regardless of whether it was
        ## running or not, start it again.
        $0 stop
        $0 start

        # Remember status and be quiet
        rc_status
        ;;
    force-reload|reload)
        ## Signal the daemon to reload its config. Most daemons
        ## do this on signal 1 (SIGHUP).

        echo -n "Reload service sshd"

        killproc -p $SSHD_PIDFILE -HUP /usr/sbin/sshd

        rc_status -v

        ;;
    status)
        echo -n "Checking for service sshd "
        ## Check status with checkproc(8), if process is running
        ## checkproc will return with exit status 0.

        # Status has a slightly different for the status command:
        # 0 - service running
        # 1 - service dead, but /var/run/  pid  file exists
        # 2 - service dead, but /var/lock/ lock file exists
        # 3 - service not running

        checkproc -p $SSHD_PIDFILE /usr/sbin/sshd

        rc_status -v
        ;;
    probe)
        ## Optional: Probe for the necessity of a reload,
        ## give out the argument which is required for a reload.

        test /etc/ssh/sshd_config -nt $SSHD_PIDFILE && echo reload
        ;;
    *)
        echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload|probe}"
        exit 1
        ;;
esac
rc_exit

Ativando , desativando e listando scripts de inicialização[editar | editar código-fonte]

Para listar os scripts passíveis de utilização, ativos ou não basta usar o seguinte comando:

linux:/etc/init.d # chkconfig --help
usage:
        chkconfig -t|--terse [names]            (shows the links)
        chkconfig -e|--edit  [names]            (configure services)
        chkconfig -s|--set   [name state]...    (configure services)
        chkconfig -l|--list [--deps] [names]    (shows the links)
        chkconfig -c|--check name [state]       (check state)
        chkconfig -a|--add   [names]            (runs insserv)
        chkconfig -d|--del   [names]            (runs insserv -r)
        chkconfig -h|--help                     (print usage)
        chkconfig -f|--force ...                (call insserv with -f)

        chkconfig [name]           same as chkconfig -t
        chkconfig name state...    same as chkconfig -s name state
linux:/etc/init.d # chkconfig -l

Makefile 0:off 1:off 2:off 3:off 4:off 5:off 6:off SuSEfirewall2_init 0:off 1:off 2:off 3:off 4:off 5:off 6:off SuSEfirewall2_setup 0:off 1:off 2:off 3:off 4:off 5:off 6:off aaeventd 0:off 1:off 2:off 3:off 4:off 5:off 6:off acct 0:off 1:off 2:off 3:off 4:off 5:off 6:off alsasound 0:off 1:off 2:on 3:on 4:off 5:on 6:off apache2 0:off 1:off 2:off 3:off 4:off 5:off 6:off appldata 0:off 1:off 2:off 3:on 4:off 5:on 6:off atd 0:off 1:off 2:off 3:off 4:off 5:off 6:off auditd 0:off 1:off 2:off 3:on 4:off 5:on 6:off autofs 0:off 1:off 2:off 3:on 4:off 5:on 6:off autoyast 0:off 1:off 2:off 3:off 4:off 5:off 6:off cmm 0:off 1:off 2:off 3:off 4:off 5:off 6:off cpuplugd 0:off 1:off 2:off 3:off 4:off 5:off 6:off cron 0:off 1:off 2:on 3:on 4:off 5:on 6:off cryptcheck 0:off 1:off 2:off 3:off 4:off 5:off 6:off dbus 0:off 1:off 2:off 3:on 4:off 5:on 6:off dumpconf 0:off 1:off 2:off 3:off 4:off 5:off 6:off earlysyslog 0:off 1:off 2:off 3:off 4:off 5:on 6:off evms 0:off 1:off 2:off 3:off 4:off 5:off 6:off gpm 0:off 1:off 2:off 3:off 4:off 5:off 6:off gssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off haldaemon 0:off 1:off 2:off 3:on 4:off 5:on 6:off hsnc 0:off 1:off 2:off 3:off 4:off 5:off 6:off idmapd 0:off 1:off 2:off 3:off 4:off 5:off 6:off joystick 0:off 1:off 2:off 3:off 4:off 5:off 6:off kadmind 0:off 1:off 2:off 3:off 4:off 5:off 6:off kpropd 0:off 1:off 2:off 3:off 4:off 5:off 6:off krb524d 0:off 1:off 2:off 3:off 4:off 5:off 6:off krb5kdc 0:off 1:off 2:off 3:off 4:off 5:off 6:off ldap 0:off 1:off 2:off 3:on 4:off 5:on 6:off lirc 0:off 1:off 2:off 3:off 4:off 5:off 6:off lm_sensors 0:off 1:off 2:off 3:off 4:off 5:off 6:off mdadmd 0:off 1:off 2:off 3:off 4:off 5:off 6:off mon_fsstatd 0:off 1:off 2:off 3:off 4:off 5:off 6:off mon_statd 0:off 1:off 2:off 3:off 4:off 5:off 6:off multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off mysql 0:off 1:off 2:off 3:off 4:off 5:off 6:off named 0:off 1:off 2:off 3:off 4:off 5:off 6:off netdump-server 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:on 3:on 4:off 5:on 6:off nfs 0:off 1:off 2:off 3:on 4:off 5:on 6:off nfsboot 0:off 1:off 2:off 3:on 4:off 5:on 6:off nfsserver 0:off 1:off 2:off 3:off 4:off 5:off 6:off nmb 0:off 1:off 2:off 3:off 4:off 5:off 6:off novell-zmd 0:off 1:off 2:off 3:off 4:off 5:off 6:off nscd 0:off 1:off 2:off 3:on 4:off 5:on 6:off ntp 0:off 1:off 2:off 3:off 4:off 5:off 6:off openct 0:off 1:off 2:off 3:off 4:off 5:off 6:off pcscd 0:off 1:off 2:off 3:off 4:off 5:off 6:off pkcsslotd 0:off 1:off 2:off 3:off 4:off 5:off 6:off portmap 0:off 1:off 2:off 3:on 4:off 5:on 6:off random 0:off 1:off 2:on 3:on 4:off 5:on 6:off raw 0:off 1:off 2:off 3:off 4:off 5:off 6:off resmgr 0:off 1:off 2:on 3:on 4:off 5:on 6:off rpasswdd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rpmconfigcheck 0:off 1:off 2:off 3:off 4:off 5:off 6:off rsyncd 0:off 1:off 2:off 3:off 4:off 5:off 6:off running-kernel 0:off 1:off 2:on 3:on 4:off 5:on 6:off rxstack 0:off 1:off 2:off 3:off 4:off 5:off 6:off saslauthd 0:off 1:off 2:off 3:off 4:off 5:off 6:off sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off sharedvol_mount 0:off 1:off 2:off 3:off 4:off 5:off 6:off skeleton.compat 0:off 1:off 2:off 3:off 4:off 5:off 6:off slpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off slurpd 0:off 1:off 2:off 3:on 4:off 5:on 6:off smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off smbfs 0:off 1:off 2:off 3:on 4:off 5:on 6:off snmpd 0:off 1:off 2:on 3:on 4:off 5:on 6:off squid 0:off 1:off 2:off 3:off 4:off 5:off 6:off sshd 0:off 1:off 2:off 3:on 4:off 5:on 6:off suseRegister 0:off 1:off 2:off 3:on 4:off 5:on 6:off svcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off synctime 0:off 1:off 2:off 3:on 4:off 5:on 6:off syslog 0:off 1:off 2:on 3:on 4:off 5:on 6:off sysstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off tsm 0:off 1:off 2:off 3:off 4:off 5:off 6:off updateconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off vmlogrdr 0:off 1:off 2:off 3:off 4:off 5:off 6:off vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off xdm 0:off 1:off 2:off 3:off 4:off 5:on 6:off xfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off xinetd 0:off 1:off 2:off 3:on 4:off 5:on 6:off xpram 0:off 1:off 2:off 3:off 4:off 5:off 6:off z90crypt 0:off 1:off 2:off 3:off 4:off 5:off 6:off xinetd based services:

       chargen:            off
       chargen-udp:        off
       daytime:            off
       daytime-udp:        off
       echo:               off
       echo-udp:           off
       klogin:             off
       kshell:             off
       ktelnet:            off
       netstat:            off
       rexec:              off
       rlogin:             off
       rsh:                on
       rsync:              off
       servers:            off
       services:           off
       swat:               off
       systat:             off
       telnet:             on
       time:               off
       time-udp:           off
       vnc:                off
       vsftpd:             off

Ativando e desativando o serviço sendmail:

linux:/etc/init.d # chkconfig sendmail 3
linux:/etc/init.d # chkconfig sendmail -l
sendmail                  0:off  1:off  2:off  3:on   4:off  5:off  6:off
domsles10:/etc/init.d # chkconfig sendmail off
linux:/etc/init.d # chkconfig sendmail -l
sendmail                  0:off  1:off  2:off  3:off  4:off  5:off  6:off
linux:/etc/init.d # chkconfig sendmail 35
linux:/etc/init.d # chkconfig sendmail -l
sendmail                  0:off  1:off  2:off  3:on   4:off  5:on   6:off