Todos os segredos estão no /etc..

"Você liga o computador, vê todas aquelas mensagens na tela desde o boot até que o bash lhe dê um prompt, e não entende lhufas." Power Up to Bash Prompt, de Greg O’Keefe

A inicialização do Linux

Na edição passada, criamos "na força bruta" um usuário em nosso sistema. Logamo-nos com ele e, para nossa surpresa, funcionou! Mas o /etc encerra bem mais segredos do que pensamos. Citando Shakespeare, "Há mais coisas entre o céu e a terra do que sonha nossa vã filosofia". Em uma interpretação livre, há mais coisas entre o boot e o prompt do shell...

Inicializando o sistema

Se você usa o LILO (ou mesmo o GRUB), aqui já temos a primeira interação do /etc com o sistema. O LILO é gravado no master boot record do disco de inicialização (setor do HD que é lido durante a inicialização). O /etc não está montado ainda e não pode ser lido, mas a configuração do LILO é guardada no arquivo /etc/lilo.conf. Depois de dado o boot, se for preciso nova configuração do LILO, basta editar o lilo.conf e rodar o comando lilo. As informações do lilo.conf são, então, gravadas no setor de boot. Com o GRUB o procedimento é semelhante. Mais informações sobre como configurar o LILO e o GRUB, consulte as man pages do lilo, lilo.conf, grub, e os diretórios /usr/doc e /usr/share/doc.

Propositadamente, não vamos colocar exemplos dos arquivos de inicialização neste artigo, para forçar o leitor a verificá-los em seu próprio sistema.

Uma vez carregado o kernel, a primeira coisa que ele faz é rodar o programa init. Na verdade, o kernel roda qualquer coisa que estiver em /sbin/init, portanto você pode substituir o binário original por qualquer outro programa e assim criar um sistema dedicado para alguma determinada tarefa. Essa não é a melhor maneira de fazer isso, mas é uma possibilidade.

O programa init lê o arquivo de inicialização inittab, que está no (adivinhe...) /etc.

No inittab estão indicados os scripts de inicialização que devem ser executados durante o boot, e a ordem em que eles aparecem. Também está indicado qual o runlevel default que será utilizado para login.

Além disso, cada vez que o sistema muda de nível de execução (runlevel) o init executa as tarefas reservadas àquele nível descritas no inittab. Por exemplo, supondo que na inicialização o runlevel default seja 3 (modo texto, multiusuário, rede habilitada), o init, durante o boot, inicializa os processos reservados ao runlevel 3. Quando, no prompt do bash, chamamos o ambiente gráfico (startx, kde, gnome), mudamos o runlevel de 3 para 5 (modo gráfico). O init, então, interromperá todos os processos do runlevel 3 e inicializará os processos do runlevel 5. Dando um shutdown na máquina, estamos mudando para o runlevel 6, então todos os processos do runlevel atual são interrompidos e os processos do runlevel 6 são inicializados. Normalmente, os únicos processos do runlevel 6 inicializados são o reboot ou o halt. Como isso é feito?

It’s a kind of magic...

Experimente abrir o inittab. Sugerimos o vi em razão de apresentar os scripts bash com sintaxe colorida. Após todas as linhas com um # na frente (que são apenas comentários), lemos a linha id:3:initdefault: que nada mais é do que a definição do runlevel no qual o Linux será inicializado. No caso é o nível 3, indicando que o sistema deve entrar em modo texto multiusuário. Se no lugar de 3 houvesse 5, o sistema inicializaria diretamente em modo gráfico. Cuidado: não configure para o nível 6, pois o computador entrará em loop e só ficará dando boots.

O próximo passo do inittab é executar o script de inicialização. Esse script é interpretado pelo bash (sim, o mesmo bash que lhe dá o prompt). Em sistemas que seguem o padrão xBSD, como Debian, Slackware e SuSE, o script de inicialização é o /etc/init.d/rcS. Nos sistemas que seguem o padrão System V, como RedHat, Conectiva, Mandrake e TechLinux, o script de inicialização é o /etc/rc.d/rc.sysinit. Esse é um script grande e ligeiramente complexo, mas uma examinada nele com a ajuda de um bom guia de referência do bash fará o leitor compreender o que se passa durante a inicialização. Procure descobrir quais processos ele chama, quais parâmetros são passados, detalhes que não ficam claros com as mensagens mostradas durante a inicialização. Procure, por exemplo, as chamadas para montagem dos filesystems (deve haver um mount -a em algum lugar), a chamada da partição de swap e o ajuste do relógio.

A partir daí, o inittab aponta para outro script de inicialização, o rc. A diferença é que o init passa o número do runlevel como parâmetro ao rc, e assim o sistema pode determinar quais processos inicializar e quais deve finalizar naquele runlevel específico. Isso é conseguido através de um artifício interessante, quase um tipo de mágica: cada runlevel possui um diretório com arquivos cujos nomes indicam quais processos devem iniciar quando se está entrando naquele nível de execução; nesse mesmo diretório, há arquivos indicando quais processos devem ser destruídos.

Em Debian, esses diretórios são /etc/rc0.d, etc/rc1.d, ... , etc /rc6.d, no RedHat teríamos /etc/rc /d/rc0.d, /etc/rc.d/rc1.d, ... , /etc/rc.d/rc6.d, cada um deles correspondente a um runlevel. Dentro de cada diretório há arquivos cujos nomes começam com S, seguido de dois números. O S indica que esse processo deve ser inicializado nesse runlevel, os números indicam a ordem em que os serviços devem ser inicializados. Os arquivos iniciados com K indicam quais processos devem ser finalizados naquele runlevel.

Os arquivos iniciados com S e K na verdade são links simbólicos para os scripts de inicialização de cada serviço, localizados no diretório init.d. Para variar um pouco, as distribuições não seguem um padrão: no Debian o caminho é /etc/init.d, no RedHat, é /etc/rc.d/init.d. Como podem observar, ficou fácil entender (e configurar) quais serviços devem ser iniciados e terminados em cada runlevel. Faça uma experiência: muito provavelmente o leitor possui o banco de dados MySQL instalado em seu sistema. Caso ele não esteja configurado para inicializar no runlevel padrão (normalmente é o 3 ou o 5, consulte seu inittab), crie um symlink no rc(número).d correspondente. Por exemplo, supondo que o runlevel padrão é o 3. Para sistemas System V, faremos:

# cd /etc/rc.d/rc3.d
# ln -s /etc/rc.d/init.d/mysql S80mysql
Em sistemas xBSD, as instruções são:
# cd /etc/rc3.d
# ln -s /etc/init.d/mysql S80mysql
No SuSE, siga os passos abaixo:
# cd /sbin/init.d/rc3.d
# ln -s /sbin/init.d/boot.d/mysql S80mysql

Quando o sistema for inicializado, o MySQL vai rodar automaticamente. É aí que reside a mágica: um simples link simbólico faz com que o sistema decida se aquele script deve rodar ou não.

Observe: na maioria dos runlevels, sempre o último processo a ser inicializado pelo init é o rc.local. Normalmente, o link para ele está com o nome S99local. No rc.local estão todas as tarefas específicas daquela máquina, e normalmente é onde o administrador do sistema coloca algum script personalizado para rodar. Devemos tomar cuidado, entretanto, com a chamada "síndrome do rc.local": a triste falta de padrão entre as distribuições faz com que uma solução que funcione bem no rc.local de uma simplesmente não funcione ou cause efeitos indesejados em outra. Todo cuidado é pouco!

Ei, você aí, me dá um login aí!

Depois de processar os rcs, a próxima tarefa configurada no inittab é inicializar alguns gettys. Um getty é um gerenciador de terminais, cada um representa um console a ser ligado ao Linux. Esse console pode ser virtual (a maioria das distros inicializa seis gettys) ou podem ser consoles reais, que se comunicam por portas seriais.

O getty simplesmente apresenta a tela de login para o terminal ao qual ele está ligado. Quando o usuário digita o seu login, o getty passa essa informação para o comando login, que imediatamente pede uma senha. Se a senha para aquele login coincidir com as senhas configuradas nos arquivos passwd e shadow, o controle da máquina é passado para o bash. Na verdade, no arquivo passwd está o programa que deve obter o controle. Normalmente é o bash, mas é possível colocar qualquer coisa. Experimente colocar um outro programa no lugar do bash e veja o que acontece. Logicamente, os arquivos passwd e shadow também estão no diretório /etc.

Normalmente, as distros rodam um getty de funcionalidade reduzida chamado mingetty, que trabalha apenas com terminais virtuais, mas que, em contrapartida, são minúsculos e ocupam uma quantidade ridícula de memória. Mesmo assim, é possível economizar "uns trocados" de memória diminuindo o número de gettys inicializados no sistema. Basta, no inittab, comentar (ou seja, colocar um # no início) as linhas dos terminais virtuais, que você quer desabilitar. Eu, por exemplo, diminuí em minha máquina o número de terminais de seis para três.

Enfim, console...

Assim que o bash toma o controle do console, ele procura seus arquivos de configuração, que estão (adivinhe onde?) no /etc. São eles profile e bashrc. Esses arquivos contêm a configuração global do bash, e todos os usuários quando entrarem no sistema terão seus "bashes" controlados por esses arquivos. No diretório /home de cada usuário podemos encontrar um ou mais dos seguintes arquivos:

.profile, .bash_profile, .bashrc e .bash_login. Esses arquivos devem ser editados quando se deseja que as configurações valham para aquele usuário apenas. Para alterações que valham para todos os usuários, utilize os arquivos do /etc. Não é o escopo deste artigo discorrer sobre a configuração do ambiente bash, mas sugerimos que o leitor "brinque" um pouco com os arquivos de configuração. Uma boa fonte de informação é a man page do bash. E não esqueça de ANTES fazer cópias de segurança!

Agradeço ao Augusto Campos pelas dicas sobre inicialização do SuSE.

Na próxima edição falaremos sobre networking e configurações de rede.