Unix Tip: Comandos NTP
ITworld.com – Envie suas perguntas Unix hoje!
Veja dicas e truques adicionais Unix
A coluna da semana passada introduziu NTP, o Protocolo de Tempo de Rede e o conceito de cronometragem altamente precisa. Embora existam numerosos comandos para ajudar os administradores de sistemas a manter um tempo bastante preciso nos sistemas que eles gerenciam, os mais óbvios são muito limitados. Como resultado, a maioria das redes sofre de grandes discrepâncias no tempo do sistema. Diferenças de tempo como as mostradas abaixo (tiradas de uma rede real) não são incomuns:
host01: Thu Oct 14 10:50:23 EDT 2004
host02: Thu Oct 14 10:43:53 EDT 2004
host03: Thu Oct 14 10:41:52 EDT 2004
host04: Thu Oct 14 10:50:13 EDT 2004
host05: Thu Oct 14 10:33:59 EDT 2004
host06: Thu Oct 14 14:48:17 GMT 2004
host07: Qui Out 14 10:52:04 EDT 2004 *
host08: Qui Out 14 10:52:33 EDT 2004
host09: Qui Out 14 10:49:55 EDT 2004
host10: Qui Out 14 10:33:20 EDT 2004 *
host11: Qui Out 14 10:51:22 EDT 2004
Apenas dentro destes onze sistemas sequencialmente pesquisados, podemos ver uma variabilidade considerável no tempo reportado. Embora as sondagens tenham ocorrido durante alguns segundos, as diferenças de tempo são consideravelmente maiores do que alguns segundos. Existe, de facto, uma diferença de 18 minutos e 44 segundos entre o primeiro e o último tempo reportado. Se tivéssemos pesquisado toda a rede, a diferença entre o primeiro e o último tempo reportado teria sido ainda maior.
Para forçar sistemas como estes a aproximarem-se mais do tempo, o administrador de sistemas pode usar qualquer um dos vários comandos com diferentes graus de sucesso.
O comando data
O comando data que permite ao administrador de sistemas definir a data e a hora é o comando mais óbvio para corrigir a hora num sistema, mas depende do administrador de sistemas ter uma referência de tempo bastante precisa. Este comando também é executado um sistema de cada vez. Usando o comando date para colocar dois sistemas em sincronia, é improvável que um administrador de sistema aproxime as horas do sistema mais do que dentro de alguns segundos um do outro. O comando date não é claramente o comando de escolha quando a sincronização é importante. E, numa rede com várias centenas de sistemas, esta abordagem pode ser tediosa e imprecisa.
Se um administrador de sistemas emitisse um comando de data num laço como o mostrado abaixo, os tempos do sistema estariam mais próximos do que os mostrados acima, mas continuariam a variar em tantos segundos quanto o laço levasse para ser completado. E, claro, essa variação de tempo será cada vez mais significativa se uma senha tiver que ser digitada para cada comando ssh.
for host in `cat host_list`do ssh $host "date 10141045"done
O comando date é claramente apenas minimamente útil na sincronização de sistemas. Os relógios do sistema que tendem a ganhar ou perder tempo, mesmo que apenas na ordem de alguns segundos por dia, irão rapidamente alargar novamente os intervalos de tempo. Além disso, sistemas configurados para outros fusos horários — como o sistema que reporta a hora como GMT na lista mostrada acima, teriam seus relógios desligados por horas se usássemos o comando de data como mostrado.
O comando rdate
O comando rdate, uma escolha muito melhor para sincronizar relógios em uma rede, requer que um administrador de sistema selecione um sistema acessível à sua rede, presumivelmente um que mantenha uma hora bastante precisa para usar como referência de tempo para o resto.
O laço seguinte produziria resultados muito melhores do que o mostrado acima. Afinal, o tempo necessário para completar este loop não terá nenhum efeito prejudicial já que cada comando rdate irá sincronizar até a hora no servidor de referência quando esse comando for executado.
for host in `cat host_list`do ssh $host "rdate timekeeper"done
Além disso, o comando rdate não sobrepõe o fuso horário no sistema alvo. Em vez de definir a hora literalmente para um valor que é fornecido na linha de comando, rdate solicita dados de tempo que são independentes do fuso horário. Em outras palavras, se você executar “rdate” em um sistema usando GMT, a hora no sistema GMT será definida corretamente.
O comando rdate é geralmente executado na inicialização do sistema ou através do cron uma vez por dia ou uma vez por hora para alinhar os relógios nos sistemas em uma LAN. Em comparação com os relógios indisciplinados do sistema mostrados anteriormente, isto é uma grande melhoria. Entretanto, do ponto de vista de cada sistema cujo relógio é zerado com rdate, algumas coisas muito incomuns podem acontecer. Os relógios podem saltar para frente ou para trás no tempo cada vez que o comando rdate é executado. Este comportamento pode levar a algumas interpretações muito estranhas de eventos sensíveis ao tempo.
ComandosNTP
NTP claramente tem vantagens consideráveis sobre os comandos de data e rdate. Para um, o NTP fornece uma maneira de sincronizar os relógios do sistema com precisão incomum e fazer os ajustes necessários suavemente, evitando os saltos no tempo que comandos como o rdate frequentemente causam. Vamos dar uma olhada mais de perto.
NTP fornece dois comandos para ajuste de tempo: o comando ntpdate — que define o tempo do sistema tanto quanto o comando rdate faz (ou seja referenciando um sistema remoto para obter a hora atual) e o daemon NTP — ntpd ou xntpd — que fornece um mecanismo muito mais elaborado para chegar e sincronizar com a hora apropriada.
O comando ntpdate
O comando ntpdate — geralmente usado, como o comando rdate, na inicialização do sistema, sob demanda ou periodicamente através do cron — sincroniza a hora numa base “ad hoc” de maneira similar ao rdate. No entanto, o comando ntpdate tem duas vantagens muito importantes sobre o rdate.
Por uma coisa, ntpdate faz referência a um servidor NTP, não apenas a um cronometrista confiável acessível à sua rede. Como os servidores NTP estão geralmente ligados à hierarquia NTP (e, em última análise, a um relógio atómico altamente preciso), é quase garantido que são mais precisos do que qualquer servidor que simplesmente tenha um bom chip de relógio.
Para outro, ntpdate pode recolher um número de amostras de tempo de várias fontes de tempo (ou seja, múltiplos servidores NTP) e depois seleccionar a hora que parece mais precisa. Assim, o comando ntpdate não só faz referência a uma fonte de tempo que é mais provável de ser precisa do que as selecionadas para uso com rdate, mas também faz referência a vários sistemas e aplica um processo de seleção sofisticado.
Um comando ntpdate pode se parecer com isto:
# ntpdate 129.6.15.28
14 Out 10:52:41 ntpdate: adjust time server 129.6.15.28 offset -0.003350 sec
Na verdade, se o comando ntpdate estiver instalado no seu sistema (/usr/sbin/ntpdate na maioria dos sistemas Solaris), você pode tentar esse exato comando ntpdate agora mesmo. O servidor de referência neste exemplo é um servidor NTP no NIST em Gaithersburg, Maryland.
Alternately, você pode tentar um comando ntpdate como este:
# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Out 14:57:41 ntpdate: ajustar o servidor de tempo 216.200.93.8 offset 0.015733 sec
Neste caso, múltiplos servidores NTP são consultados.
O Daemon NTP
Enquanto o comando ntpdate fornece um nível de controle de tempo que é uma ordem de magnitude melhor que rdate, o daemon NTP vai um passo gigantesco além do ntpdate com seus algoritmos sofisticados para maximizar a precisão e confiabilidade. Usado corretamente, o daemon NTP também usa uma quantidade mínima de recursos de rede — vamos examinar esta questão na próxima semana.
O daemon NTP fornece algoritmos sofisticados que sincronizam suavemente os relógios do sistema através de um processo de aproximação sucessiva. Quanto mais tempo o daemon rodar, mais próximo o tempo do sistema corresponde ao da sua fonte. Ele faz grandes ajustes rapidamente e depois ajustes menores ao longo do tempo para evitar ultrapassar o tempo apropriado.
Pode levar minutos ou horas para o NTP se aproximar de um nível fino de precisão mas, uma vez que o faz, a confiabilidade do tempo no sistema pode ser surpreendentemente precisa. Dito isto, a precisão do tempo do NTP está, no entanto, finalmente ligada à precisão das fontes de tempo que ele refere. Cada servidor NTP tenta sincronizar para UTC (ou seja, Tempo Universal Coordenado) usando a melhor fonte de tempo e caminho de transmissão disponível. Se o conjunto de servidores referenciados transmitir tempos que não estejam muito próximos uns dos outros, o NTP considerará um ou mais desses servidores de tempo a serem quebrados e os descontará. Então, para obter um tempo preciso usando o NTP, sua escolha de servidores de tempo deve ser precisa.
Novos que chegam ao NTP devem observar que rodar o processo NTP daemon NÃO faz necessariamente de um sistema um servidor NTP. Se um sistema habilitado para NTP desempenha o papel de cliente ou servidor é determinado pelos arquivos de configuração do daemon naquele sistema — algo que iremos examinar na coluna da próxima semana.
Esta história, “Dica Unix”: NTP Commands” foi originalmente publicado pelo ITworld .