[GTER] ntpdate vs ntpd (aka, ntpd pra que?)

[Gustavo De Nardin (spuk)]

2015-02-15 11:43 GMT-02:00 Evandro Nunes <evandronunes12 at gmail.com>:
> 2015-02-15 2:52 GMT-02:00 Gustavo De Nardin (spuk) <gustavodn at gmail.com>:
>
>> 2015-02-14 15:07 GMT-02:00 Evandro Nunes <evandronunes12 at gmail.com>:
>> > preciso validar ou rever minha posicao, entao... o que eu perco? ntpd pra
>> > que?
>>
>> O ntpdate acerta o relógio num dado instante. A função do NTPD é
>> manter o relógio acertado. Inclusive, por default, há situações em que
>> o daemon ntpd referência não acerta o relógio, porque ele não dá
>> saltos de tempo pra trás, nem muito grandes pra frente, por exemplo.
>> Se o servidor que tu usa como fonte de tempo tiver algum tipo de
>> problema e de repente mudar a hora pra alguma coisa maluca, o ntpd não
>> vai aplicar a maluquice no teu relógio, ele percebe que houve algo
>> errado, já o ntpdate vai tacar a hora errada obtida do servidor fonte,
>> porque é a função dele.
>>
>
> Acho que nao esta muito preciso isso ai nao. Ngm usa ntpd (ou n deveria
> usar sequer ntpdate) com um único servidor de referencia. A maluquice de um
> server sera ignorada e outros não tao divergentes serão usados de
> referencia.

Creio que seja comum usar 1 fonte interna de tempo, para os servidores
internos, que ela sim usa 3+ fontes externas de tempo. Na verdade o
que eu aprendi foi que se deve configurar 1 ou alguns servidores NTP
internos, sincronizando com externos, e internamente usar apenas os
teus próprios servidores, pois o que mais interessa é ter o tempo
consistente internamente (ou: entre os sistemas relacionados). Nesse
caso só se tem 1 ou uns poucos servidores NTP acessando externamente,
e o acesso a eles em geral é bloqueado por uma firewall.


>> Mas me parece que a questão real seria: quão importante é
>> sincronização de tempo pra ti (ou pro teu ambiente, ou pra quem você
>> trabalha)?
>>
>
> nao
> exatamente ao contrario
> a importância e relevancia é tamanha que me fez testar, comparar,
> documentar praticas internas pras opções 1 e 2, gerar recomendações de
> cenário 3 (client + server)... o ponto era apenas ntpd-vs-ntpdate :-)
> sincronizar é mais que preciso, é uma obrigação... regulatória inclusive no
> meu caso e provavelmente legal com o novo marco civil pra diversos outros
> casos

É interessante a questão que levantou quanto ao marco civil, pode ser
o caso mesmo.

Como já foi mencionado, o ntpdate, a princípio, faria o tempo do
sistema dar um pulo para o tempo certo, e isso é indesejável em muitos
casos depois que o sistema inicializou. Mas reli a documentação do
ntpdate e percebi que ele faz ajuste por "slew" ao invés de pulo caso
a diferença de tempo seja menor que 0,5s, e é possível mandar ele
fazer por slew sempre, então não é sempre o caso que ele vai dar
pulos. Mas ao ler a documentação também se percebe o seguinte texto:
"""... Disclaimer: This program has known bugs and deficiencies and
nobody has volunteered to fix them in a long time. The good news is
the functionality originally intended for this program is available in
the ntpd and sntp programs. See the Deprecating ntpdate
(http://support.ntp.org/Dev/DeprecatingNtpdate) topic in the NTP
Support wiki for a thorough discussion and analysis of the issues. See
the -q command line option in the ntpd - Network Time Protocol (NTP)
daemon page and/or the sntp- Simple Network Time Protocol (SNTP)
Client page. After a suitable period of mourning, the ntpdate program
will be retired from this distribution. ..."""

Ou seja, até o pessoal que mantém ele já está avisando para não usar e
que será retirado de circulação, o substituto é o 'sntp', então se
você quiser mesmo ajustar o tempo via cronjob, deveria usar ele ao
invés do ntpdate.

Mas a questão é mais referente ao ajuste do tempo contínuo X
instantâneo. Isso já foi respondido, e inclusive você mesmo demonstra
conhecer a questão no email original. Se você conhece bem teus
requisitos e sabe que pode usar ajuste periódico via cronjob,
sucesso... Mas como é difícil saber os requisitos de tudo que roda num
sistema hoje em dia, fica mais fácil configurar um daemon
especializado na questão de manter o tempo correto. Por isso a boa
prática é essa: diferente do que você está propondo, o mais fácil,
para resolver o problema de ajuste de tempo num sistema, é configurar
o ntpd, ao invés de pensar em todos os problemas que o ajuste
períodico, possivelmente por saltos, pode acarretar.

O teu método de aferição (sleep + date) deveria ser desnecessário,
pois o ntpdate mostra a diferença do local para a referência, e o ntpd
tem esse dado disponível continuamente (ntpq -p). Aliás, mais uma
vantagem de usar o ntpd: já tem disponível todo um ferramental para
acompanhar o funcionamento e diagnosticar problemas.

Quanto ao uso de banda, você não diz como chegou aos "1200%" a mais de
uso de banda pelo ntpd, mas afirma que o uso de banda pelo ntpd seria
contínuo, o que é incorreto, pois ele faz poll periódico, e esse
período aumenta conforme o relógio local fica bem disciplinado, sendo
que para realizar a sincronização inicial costuma se usar mais
consultas (iburst). Ou seja, dependendo de como configurar o ntpdate
(frequência, quantidade de servidores, ...), é bem possível que ele
use mais banda que o ntpd ao longo do tempo.

Mas de qualquer modo, você é quem deve conhecer os requisitos dos
sistemas que administra, e portanto deve saber se um ou outro métodos
são suficientes. A própria documentação do ntpdate sugere esse uso,
mas com ressalvas: """... It is also possible to run ntpdate from a
cron script. However, it is important to note that ntpdate with
contrived cron scripts is no substitute for the NTP daemon, which uses
sophisticated algorithms to maximize accuracy and reliability while
minimizing resource use. Finally, since ntpdate does not discipline
the host clock frequency as does ntpd, the accuracy using ntpdate is
limited. ..."""

t'