Como eu sempre costumo dizer tem uma parte da informática que não é lógica, esta área é envolta por uma espessa nuvem de forças contrárias a vontade do administrador e que costumam entrar em ação quando ele mais acredita que tudo vai dar certo. Os mais incrédulos chamam esta força de “lei de Murphy” mas imagino que seja algo mais do que apenas isso.

Exemplos de forças contrárias a vontade do Sysadmin

Um bom exemplo de força contrária a nossa vontade é a que causa o conhecido problema de “fio entupido”. Quem nunca teve problemas com a conexão de rede que foi resolvida apenas esperando um tempo para sujeira escoar e depois tudo voltou ao normal? 🙂

Outro problema é a complexa “teoria do fusca” em que você precisa fechar todos os programas e reiniciar o computador, tal como acontecia com os “fusquinhas” que de vez enquando enguiçavam sem qualquer motivo aparente e então bastava desligá-lo, dar uma olhada no motor e tentar a ignição novamente que já está tudo em em ordem!

Problemas como esse são rotineiros na administração de sistemas e um caso bem comum e sazional nesta área é o causado pelo horário de verão.

A simplicidade da teoria nem sempre funciona

O verão aqui no Rio é sinônimo de praia, sol, amizade e curtição; mas pra mim e demais administradores de sistema cariocas e de diversos outros estados brasileiros, todo ano temos o mesmo problema. Este período corresponde ao que que se precisa adiantar o relógio nos servidores em uma hora e depois de alguns meses voltar ao normal.

Como uso Debian/Ubuntu teoricamente é molezinha: Alguns dias antes do dito horário de verão começar basta instalar o pacote tz-brasil atualizado e esperar que no dia certo a mágica acontecerá (ou deveria).

# aptitude update
# aptitude install tz-brasil

Seria perfeito se apenas isso funcionasse, mas a tal “força” citada antes entra em ação exatamente neste momento! Parece que tudo está OK, já que não aparece nenhuma mensagem de erro e ai é só dormir em paz esperando o dia da virada … mas qual seria a graça se tudo funcionasse!? O Sysadmin vive de bugs, assim como o médico vive das doenças, os advogados vivem de processos contra alguém e os urubus de carniça… (acho que peguei pesado 🙂 )

O radicalismo prático sempre funciona

Esse ano não foi diferente. Tudo pronto pra virada em pleno feriadão e qual não foi a surpresa ao verificar que apesar do mesmo procedimento ter sido feito em sete servidores, três deles foram desobedientes!?

Pra encurtar a história que envolveu algumas horas comparando arquivos de configuração, fazendo buscas no Google e perguntando a outros passam pelo mesmo problema eu cheguei a um resumo nada trivial mas que funcionou.

Passo a Passo para se livrar da dor de cabeça no próximo ano

1º A primeira coisa a fazer é criar um arquivo de texto igual a este aqui, em qualquer lugar e com qualquer nome:

Rule    BrazilSP  2007    only    -       Oct     14      0:00    1:00    S
Rule    BrazilSP  2008    only    -       Feb     17      0:00    0       -
# Zone  NAME                    GMTOFF  RULES/SAVE      FORMAT  [UNTIL]
Zone    America/Sao_Paulo       -3:00   BrazilSP        BR%sT

3º Digamos que você tenha salvo o arquivo em /tmp/hv2007.zic. Então execute o seguinte comando:

# zic /tmp/hv2007.zic

Com isso você já criou e instalou o arquivo que define o intervalo de horário de verão.

4º Agora é preciso que você defina a sua timezone como America/Sao_Paulo ou a sua zona correta (veja a última linha do arquivo que criamos), caso não seja esta, com o comando tzconfig ou tzselect. Basta digitar um deles no terminal e se guiar pelas perguntas que serão feitas. (Qual a região?, Qual o País?, Qual a Localidade?)

Confira se está direitinho com:

# cat /etc/timezone

Isso deverá retornar a zona configurada no seu sistema

5º Estando tudo em ordem, verifique se o link /etc/localtime aponta corretamente para /usr/share/zoneinfo/America/Sao_Paulo (ou para o arquivo correspondente a sua zona. Uma forma bacana (e radical) de fazer isso é apagando-o e recriando corretamente assim:

# rm /etc/localtime ; ln -s /usr/share/zoneinfo/`cat /etc/timezone` /etc/localtime

Observe que estou usando a informação do /etc/timezone para criar o link corretamente. Note ainda que alguns sistemas fazem uma cópia do arquivo de zona ao invés do link. Na realidade você só precisa se preocupar em fazer a cópia, caso o seu /usr ou /usr/share seja uma partição separada do “/”, pois este arquivo precisa estar disponível antes que todas as demais partições sejam montadas – se este for o seu caso, ao invés de “ln -s” use “cp” na linha acima.

Se você fez tudo certo o seu sistema já está configurado e isso pode ser verificado com dois comandos:

# date ; hwclock

Seg Out 15 21:03:02 BRST 2007
Seg 15 Out 2007 20:02:42 BRST -0.033410 segundos

O comando date, mostra a hora do sistema e que deverá ser exatamente igual a todos os relógios que você tiver, já o comando hwclock mostra a hora do relógio de hardware (o BIOS) e estará no horário normal (sem horário de verão).

E se tudo mais falhar?

Geralmente o problema está no link /etc/localtime que está apontando para o arquivo de zona errada, ou no caso de ser uma cópia, ele não é uma cópia com as regras atualizadas.
Evidentemente que estou considerando que seu relógio estivesse certo antes da virada para o horário de verão então se o problema for diferença de alguns minutos a culpa foi do relógio errado o que só pode ser corrigido ajustando-se manualmente (recomendável que sempre se ajuste pela BIOS para não ter problemas com logs e procesos de tempo real).
Certifique-se ainda que a informação de timezone esteja certa no arquivo /etc/timezone e que deverá ser a mesma ajustada pelo tzconfig/tzselect e a mesma da ultima linha do arquivo que criamos.
Nos servidores que eu cuido não tive problemas mais após esses ajustes, mas se ainda tiver algo errado tente o seguinte comando:

# TZ='America/Sao_Paulo'; export TZ

Se após isso o relógio do sistema funcionar redondo inclua esta variável no arquivo /etc/environment ou todo esse comando no arquivo /etc/profile.

No próximo login deverá estar tudo OK.