Para administrar de forma eficaz diversos servidores é indispensável a criação de padronizações que sejam divulgadas, utilizadas e bem difundidas e debatidas entre as pessoas que compõem a equipe de administradores. A experiência que adquiri durante os anos que trabalho com Linux/Unix me força a dizer que uma das piores (senão a pior), coisa que existe no “mundo Linux” é que poucas pessoas seguem uma padronização e um agravante desta situação ainda existe, que é: a padronização totalmente incoerente ou quando a padronização existe apenas na cabeça de quem administrou. O intuito deste post é expor algumas padronizações que utilizo e que adotei durante este tempo que trabalho com tecnologias livre.
– Comentários nos confs
Eu particularmente mantenho os comentários padrões dos arquivos de configuração, porém existem aqueles que não gostam de nenhum comentário nos confs. Vou citar aqui um exemplo, vamos dar uma olhada num trecho do arquivo de configuração do Apache que acompanha o pacote “apache2” na distribuição OpenSuSE :
##
## Server-Pool Size Regulation (MPM specific)
##
# the MPM (multiprocessing module) is not a dynamically loadable module in the
# sense of other modules. It is a compile time decision which one is used. We
# provide different apache2 MPM packages, containing different httpd2 binaries
# compiled with the available MPMs. See APACHE_MPM in /etc/sysconfig/apache2.
# prefork MPM
<IfModule prefork.c>
# number of server processes to start
# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#startservers
StartServers 5
# minimum number of server processes which are kept spare
# http://httpd.apache.org/docs/2.2/mod/prefork.html#minspareservers
MinSpareServers 5
# maximum number of server processes which are kept spare
# http://httpd.apache.org/docs/2.2/mod/prefork.html#maxspareservers
MaxSpareServers 10
# highest possible MaxClients setting for the lifetime of the Apache process.
# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#serverlimit
ServerLimit 150
# maximum number of server processes allowed to start
# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients
MaxClients 150
# maximum number of requests a server process serves
# http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxrequestsperchild
MaxRequestsPerChild 10000
</IfModule>
O exemplo acima ilustra o que é um arquivo de configuração bem estruturado e documentado, como podemos perceber ele explica resumidamente a funcionalidade das diretivas e para tornar a configuração mais completa, ainda indica um link para a documentação oficial do projeto. Se todos os administradores tivessem esse cuidado com certeza muito trabalho seria poupado.
Seguindo o exemplo citado acima, meu arquivo de configuração do postfix “/etc/postfix/main.cf”, tem uma estrutura semelhante com o trecho abaixo:
# http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions
# Verificacoes feitas apos o cliente enviar o enderece do destinatatio
# RCPT TO
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_hostname,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
# http://www.postfix.org/postconf.5.html#reject_unauth_destination
reject_unauth_destination,
# http://www.postfix.org/postconf.5.html#reject_unauth_pipelining
reject_unauth_pipelining,
##check_policy_service inet:127.0.0.1:10001 # http://www.postfix.org/SMTPD_POLICY_README.html
– Particionamento
Configurar um servidor hoje em dia é uma tarefa trivial para alguns administradores de sistema e muitas ferramentas podem ser utilizadas para facilitar esta tarefa. Mas algo que é muito importante e não deve ser esquecido é a padronização dos servidores e na minha opinião a primeira padronização que devemos criar é para o particionamento. Confesso que já ouvi relatos impressionantes de alguns colegas que se depararam com esquemas no mínimo bizarros, alguns exemplos:
- /tmp com 50 mb
- /var/spool/mail com 10 GB
- /boot com reiserfs
Agora eu pergunto:
– Porque o “/tmp” com apenas 50 MB? Está faltando espaço em disco e você economizou com o /tmp, afinal, são apenas arquivos temporários;
– Porque “/var/spool/mail” com 10 GB, pense comigo, se um dia teu server estiver com 5 GB de emails na fila, com certeza existe um problema muito maior no servidor que esta partição sozinha não vai resolver.
– /boot formatado com reiserfs, lógico, pois o sistema deve manter journaling para uma partição que é utilizada apenas no boot do sistema 🙂
Seria hilário se não fosse trágico….
Uma coisa é certa não existe uma padronização universal para todas as modalidades de serviços existentes hoje, mas alguns padrões são inevitáveis:
/usr -> Esta partição não precisa ser enorme, pois é aqui que a maioria dos programas instalados no teu servidor ficarão, sendo assim, pense bem , tu não vai precisar de 20GB nesta partição. Eu em todos os servidores que administro defino apenas 4GB para essa partição, e acho que não deve passar muito disso. Até 8 GB é aceitável…
/var -> Dependendo do tipo de servidor é importante termos um certo histórico de logs , mas cuidado… se esse histórico de logs for tão importante assim, utilize um servidor de logs, é mais inteligente, sendo assim, o máximo aconselhável para esta partição , na minha opinião, é 30GB ;
/tmp -> não precisa alocar 30 GB para esta partição, mas também não deixe apenas 100MB. 1GB tá bom!!
/var/lib/mysql -> acho importante ter uma partição separada para os dados do Mysql ;
/var/cache/squid -> para alguns servidores com Squid é interessante utilizarmos uma partição separada do sistema, e quem sabe até usando Reiserfs, o espaço pode variar.
swap -> cuidado com esse carinha aqui, se teu sistema utilizar muita swap teu server estará em apuros;
Não se esqueça das flags; nosuid, noexec e noatime …nem vou explicar aqui o que são essas flags, acho que isso vai ajudar : http://tinyurl.com/23ck22p
– Documentação
Sempre que faço algum tipo de configuração adicional ou encontro uma flag/falha em algum conf sigo os passos:
– Procuro na documentação oficial do software para ter certeza do que estou fazendo;
– Aplico a flag em alguma máquina virtual para testar o efeito da alteração ;
– Caso a etapa acima não tenha causado nenhum dano ou a morte de alguém aplico a regra no ambiente em produção e deixo em homologação por 24 horas;
– Caso nenhum servidor tenha rebootado inesperadamente depois de alterar a flag eu documento os passos para aplicá-la, e faço isso de 2 formas: a primeira via email para meu superior e a segunda em nosso sistema de documentação
Uma coisa é certa, documentar nunca é demais e esta etapa é uma das mais importantes para fazer um serviço bacana, pois afinal, você pode até morrer, mas a empresa onde você está trabalhando precisa continuar funcionando…certo,estou sendo trágico demais, mas voltando para a realidade, Documentar é preciso, viver não é preciso ….
– Se vai mexer faça backup …
Existem momentos em que vamos apenas adicionar uma flag no “/etc/fstab”, por exemplo, em um servidor que acabou ficando fora do padrão, este tipo de intervenção é tão básica , tão simples, tão idiota que as vezes, simplesmente editamos o arquivo e fod**-se , pois é, é ai que mora o perigo, vou citar um exemplo.
Imagine que vocẽ usa como editor padrão o “vim”, e que sempre que instala um novo servidor tu copia o arquivo “vimrc_example.vim” do “/usr/share/bla/bla/bla”, para tua pasta pessoal , este arquivo é uma mão na roda, deixa o vim todo colorido, gera backup dos arquivos editados e uma porrada de coisas mais. Com isso, imagine você deletando os arquivos de backup que o vim cria , algo como:
cd /etc/
rm -rf *~
Este comando pode até parecer brincadeira, mas a imagem abaixo mostra o que acontece quando não fazemos backup das coisas quando fazemos alguma intervenção no servidor :
É , é isso mesmo, com certeza uma hora ou outra vai dar merda !!!
Bom, vou ficando por aqui. Teremos mais posts sobre o assunto…
Filed under: Sem categoria | Tagged: linux sysadmin | Leave a comment »