Quais são os prós e os contras entre essas duas maneiras de sincronizar seu servidor?
Parece-me que seu servidor provavelmente não deriva mais de 1 segundo todos os dias, portanto, a atualização de ntpdate em um crontab estaria ok. Mas ouvi dizer que você poderia usar servidores NTP redundantes aqui
http://www.pool.ntp.org/en/use.html
para manter o tempo sincronizado em caso de falha.
Você tem alguma sugestão?
Respostas:
O algoritmo NTP inclui informações para permitir calcular e corrigir a deriva no relógio do servidor. O NTPD inclui a capacidade de usá-lo para manter o relógio sincronizado e será executado com mais precisão do que um relógio em um computador que não esteja executando o NTPD. O NTPD também usará vários servidores para melhorar a precisão.
O ntpdate não mantém nenhum estado para executar esse serviço para você, portanto não fornecerá o mesmo tipo de precisão. Isso permitirá que você forneça uma lista de servidores que serão utilizados para tentar fornecer um resultado melhor, mas isso não substitui os algoritmos sofisticados fornecidos no NTPD que rastreiam sua deriva de cada um dos servidores ao longo do tempo.
O NTPDATE corrige a hora do sistema instantaneamente, o que pode causar problemas em alguns softwares (por exemplo, destruir uma sessão que agora parece antiga). O NTPD corrige intencionalmente o tempo do sistema lentamente, evitando esse problema. Você pode adicionar a opção -g ao iniciar o NTPD para permitir que o NTPD atualize pela primeira vez um grande problema, que é mais ou menos equivalente à execução do ntpdate uma vez antes de iniciar o NTPD, prática recomendada ao mesmo tempo.
Quanto a questões de segurança, os servidores ntp não se conectam novamente em conexões não iniciadas, o que significa que o firewall deve saber que você iniciou a solicitação ntp e permitir o tráfego de retorno. Não deve haver necessidade de deixar portas abertas para conexões arbitrárias para que o NTPD funcione.
Na página do manual ntpdate (8):
O ntpdate pode ser executado manualmente conforme necessário para definir o relógio do host ou pode ser executado a partir do script de inicialização do host para definir o relógio no momento da inicialização. Isso é útil em alguns casos para ajustar o relógio inicialmente antes de iniciar o daemon NTP ntpd. Também é possível executar o ntpdate a partir de um script cron. No entanto, é importante observar que o ntpdate com scripts cron artificial não substitui o daemon NTP, que usa algoritmos sofisticados para maximizar a precisão e a confiabilidade, minimizando o uso de recursos. Finalmente, como o ntpdate não disciplina a freqüência do relógio do host, assim como o ntpd, a precisão do uso do ntpdate é limitada.
O ntpd é preferido em relação ao ntpdate porque você obtém uma correção suave do tempo, em vez de saltar no relógio. Que sentido você faz dos seus registros quando há um tempo para trás neles? O ntpdate também alternará de forma transparente entre os servidores, conforme necessário.
Quanto à exigência de portas abertas (como mencionado por Kyle), versões mais recentes do ntpd (por exemplo, 4.2.4 no meu servidor Debian) podem ser configuradas para transmitir / multicast para a LAN, com autenticação criptográfica.
Editar: veja também esta pergunta .
Geralmente, recomendo que você execute o NTPD e sincronize seus servidores com um servidor de horário designado na sua organização. Esse servidor interno normalmente estará sincronizando com um dos servidores NTP públicos (como você vinculou).
Eu usei o método ntpdate sem nenhum problema, mas parece mais hackeado do que executar um verdadeiro daemon ntpd.
Ouvi falar de problemas com a inclinação do relógio em máquinas virtuais executando o ntpd. Também ouvi falar de pessoas que corrigem esse problema executando trabalhos regulares do cron que chamam ntpdate em vários servidores de pool. Eu não tive esses problemas, mas já os ouvi várias vezes.
Como mencionado em outro lugar, o NTP fornece uma correção de tempo suave. Se os aplicativos em seu servidor não se importarem com a falta de segundos inteiros ou a repetição dos mesmos segundos, o ntpd não ganhará muito com o ntpdate.
Se, por outro lado, você possui aplicativos sensíveis ao tempo sensíveis a segundos ou, pior ainda, sensíveis a segundos parciais, então o ntpd é de longe a melhor escolha. As atualizações de data e hora do Novell eDirectory para manuseio de colisão de atualizações, que se tornam críticas se as atualizações ocorrerem muito rapidamente (como durante a corrida de login matinal). Um servidor syslog precisa ter um tempo preciso de pelo menos meio segundo para manter registros sãos.
Para minha caixa MythTV em casa, percebo quando faltam apenas alguns segundos para o que meu provedor de cabo considera tempo, então uso NTP nisso. Para o servidor de monitoramento da UPS em funcionamento, uso o ntpdate crontabbed pelos mesmos motivos apontados por Kyle Hodgson, como é um host bastião, não quero essa porta aberta, mesmo que eu tenha bloqueado o aplicativo; para esse aplicativo, estar um segundo fora da verdade não é terrível.
Quanto à redundância, mantemos pelo menos dois hosts de tempo em nossa rede e apontamos todos os hosts internos para esses dois. Esses dois rastreiam diferentes hosts NTP da Internet. Além disso, eles são configurados em um acordo de Pares, para que possam manter o tempo entre si de maneira consensual se o nosso link de Internet cair. Definitivamente, é possível projetar um NTP robusto.
Em um servidor em que o acesso e a proteção são críticos, usei o raciocínio de que xntpd, a versão do ntpd em que eu confiava, exigia uma porta UDP aberta 123. Como eu preferia ter apenas os tcp 22 e 80 abertos, usei o ntpdate em um crontab. Eu nunca ouvi uma boa razão pela qual ela precisava disso, ou não uma que eu me lembre.
Um dos contras do uso de uma chamada ntpdate não criptografada é que ele não pode lidar com a correção de desvio com elegância. ntpdate, iirc, atualiza o relógio assim que possível, indicando que você está desatualizado - os daemons ntp geralmente corrigem a deriva suavemente. Isso tem o benefício de que seus logs são mantidos sãos - você pode imaginar, em um servidor Web ocupado, por exemplo, que se o RTC se desviou alguns minutos, que a leitura dos logs da Web no dia seguinte pode inferir que as pessoas foram capazes de acessar de forma segura URLs antes do login, pois os acessos à Web estariam fora de ordem.
Você não precisa usar o crontab, é para isso que serve o ntpd.
Inicialmente, quando o tempo está acabando, uma maneira é simplesmente parar o ntpd, depois executar ntpdate ntp.server.compara sincronizá-lo novamente e iniciar o ntp novamente.
Se você tem uma rede grande, eu provavelmente configuraria dois servidores locais de ntp e pedia que todos os hosts os usassem.
Consulte esta discussão para entender por que o "ntpdate" ainda é desejado e está em uso.
Para resumir: ntpd é lento em comparação ao fazer um ajuste de tempo massivo, mesmo com a opção -g.
Para uso doméstico, o ntpdate não é nada demais. Existe uma razão para ser "mais lento". Qualquer pessoa que use um cron com ntpdate em um ambiente de PRODUCTION ENTERPRISE é apenas um idiota.