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

Sun Feb 15 11:31:37 -02 2015

2015-02-14 15:57 GMT-02:00 Danton Nunes <danton.nunes at inexo.com.br>:

> On Sat, 14 Feb 2015, Evandro Nunes wrote:
>
>  sei que em linhas gerais o ntpdate tem sido descontinuado em alguns linux
>> e
>> em algumas recomendacoes, inclusive do Nic.Br, em favor do ntpd como
>> cliente.
>>
>
> acho que eles não se comparam, suas funções são bem diferentes. o ntpdate
> acerta o relógio uma vez e acabou. o ntpd sincroniza o relógio com
> servidores externos e além disso estima a deriva do relógio local em
> relação à UTC.

não é isso que o ntpdate faz pra descobrir o clock reference quando voce
passa vários servers e samples como argumento? só que ele não mantém uma
referência histórico disso, ele usa só naquele momento, afinal é o que se
propõe a fazer mesmo

 entao o que sobra é a sincronia continua vs periodica como maior diferenca
>>
>
> a maior vantagem do ntpd é a estimativa do drift que você nem menciona.
> isso só é possível com o estimador que lida com dados no tempo e não só em
> um dado instante.

e o que ele faz com essa estimativa de drift na prática que não faça com
base no pooling periódico so servidores? pra mim aquilo sempre foi apenas
um arquivo de log

>
>  - ha 6 semanas hoje, nao ha qualquer diferenca de horario entre os
>> servidores com ntpdate e com ntpd
>>
>> - a afirmacao acima e baseada em um loop ridiculo rodando date com sleep
>> 5,
>> ou seja janela de 5 minutos contra @hourly do ntpdate o que deveria dar
>> uma
>> vantagem pro ntpd mas na pratica nao nao deu
>>
>
> sleep 5 = 5 segundos, não 5 minutos. você compara até que fração decimal
> de segundo? ntpd com boa conexão à internet deve te dar uma medida melhor
> que 20ms.
>

while true ; do date ; sleep 5m ; done

simples saida do date, não tem precisa alguma alem de um segundo, e como
estamos falando na maior parte dos casos, de epoch, não me preocupei com
frações de segundo na observação

use o ntptrace para ver como seu ntpd está funcionando.
>
>  - consomo de banda do ntpd e expressivamente maior que do ntpdate, normal,
>> por ser continuo, na pratica estou falandod e 12 vezes maior consumo de
>> banda, ou seja 1200% a mais de banda; claro a banda é baixissima e pouco
>> relevante na vida real, mesmo com muitos e muitos servers, o impacto de
>> pps
>> gerado provavelmente seria mais preocupantes que de bps mas ainda assim
>> sao
>> 1200% nao da pra ignorar, especialmente se voce mora esta regiao norte do
>> pais ou regioes rurais onde satelite é tudo que voce tem...
>>
>
> contínuo em termos. se me lembro bem, em regime permanente o ntpd atualiza
> sua medida de tempo a cada 17 minutos. dois pacotinhos UDP a cada 17
> minutos não se pode considerar grande coisa.

como assim 2 pacotinhos /17min?
olha so quando ele roda e a media quando currently ta zerado:

# rate -f "udp and port 123" -R -b
=> Currently 0.00  bps/0.00  pps, Average: 0.00  bps/0.00  pps
=> Currently 1.19 kbps/2.00  pps, Average: 608.00  bps/1.00  pps
=> Currently 1.19 kbps/2.00  pps, Average: 810.67  bps/1.33  pps
=> Currently 2.38 kbps/4.00  pps, Average: 1.19 kbps/2.00  pps
=> Currently 1.19 kbps/2.00  pps, Average: 1.19 kbps/2.00  pps
=> Currently 2.38 kbps/4.00  pps, Average: 1.39 kbps/2.33  pps
=> Currently 1.19 kbps/2.00  pps, Average: 1.36 kbps/2.29  pps
=> Currently 2.38 kbps/4.00  pps, Average: 1.48 kbps/2.50  pps
=> Currently 0.00  bps/0.00  pps, Average: 1.32 kbps/2.22  pps
=> Currently 0.00  bps/0.00  pps, Average: 1.19 kbps/2.00  pps
=> Currently 1.19 kbps/2.00  pps, Average: 1.19 kbps/2.00  pps
=> Currently 0.00  bps/0.00  pps, Average: 1.09 kbps/1.83  pps
=> Currently 0.00  bps/0.00  pps, Average: 1.00 kbps/1.69  pps
=> Currently 0.00  bps/0.00  pps, Average: 955.43  bps/1.57  pps
=> Currently 0.00  bps/0.00  pps, Average: 891.73  bps/1.47  pps
=> Currently 0.00  bps/0.00  pps, Average: 836.00  bps/1.38  pps
=> Currently 0.00  bps/0.00  pps, Average: 786.82  bps/1.29  pps
=> Currently 0.00  bps/0.00  pps, Average: 743.11  bps/1.22  pps
=> Currently 0.00  bps/0.00  pps, Average: 704.00  bps/1.16  pps
=> Currently 0.00  bps/0.00  pps, Average: 668.80  bps/1.10  pps
=> Currently 0.00  bps/0.00  pps, Average: 636.95  bps/1.05  pps

logico que é ridiculo, não estou reclamando de miséria, mas isso
multiplicado por N ntpd rodando na rede é exponencialmente mais expressivo
do que N ntpdate rodando na rede

- mais facil colocar 2 linhas no crontab do que configurar o ntpd.conf
>>
>
> sério? sim, configurar um patinete é mais fácil do que uma Fat Boy.
>
>  so que o ntpd em 99% dos casos, especialmente em linux, sobe em modo
>> servidor, ouvindo na porta e com socket udp escancarado pro mundo, sem ACL
>> alguma pre-configurada, ou seja la estao meus sites remotos com seus
>> speedy, velox, gvt, wifi com o ISP local ou link dedicado nas cidades mais
>> expressivas, prontinhos pra serem usados em uma amplificacao ntp
>>
>
> a grande preocupação de segurança aí não é exatamente essa, é limitar a
> funcionalidade desse servidor para que ele não seja abusado como
> amplificador de ataques contra terceiros. e isso vale não só para ntpd como
> para qualquer serviço UDP, por exemplo, DNS.
>

exatamente
um serviço a mais pra se preocupar mesmo quando você não quer servir, quer
ser apenas cliente...

> Esse servidor que ele escancara para o "mundo" é para servir clientes NTP
> em tua própria rede local, de modo que eles possam rodar ntpd ou ntpdate
> sem precisar apelar para um servidor externo.

só que eles não olham a rede directamente conectada como, sei la um
"allow-query { localnets }" no Bind faria; ele simplesmente sobe ouvindo e
respondendo a todos irrestritamente e portanto, sendo potencialmente
abusados numa amplificação...

>  sejamos pragmaticos, praticos, sem teorias de sync continuo vs periodico
>> pq
>> pra mim, essa questao esta superada e o resultado é o mesmo, precisamente
>> o
>> mesmo, sem divergencia de 1 segundo na saida do date, ou seja se houver
>> divergencia sao de fracoes de segundos que, enquanto relevante em sistemas
>> cientificos, em 99% dos outros casos se é abaixo de 1 segundo não é
>> perceptível por sysamdin ou sistema algum, nem OTP
>>
>
> 1 segundo é uma pequena eternidade em nosso metiér, melhor ter relógio
> acertado com a hora legal brasileira com precisão bem melhor que isso. ntpd
> te dá 20ms em condições bem precárias, ntpdate você nem tem ideia de quanto
> está errando (estou falando do bendito drift)

1 segundo
esse também é o meu limite
portanto não me preocupo em olhar drift rate se estou errado 10s, 20s, 59s
com tanto que não seja 60s

e como eu disse, rodando @hourly ou rodando ntpd não houve divergência de
mais de 1 segundo
sendo pragmatico de novo, se o ntpd atua a cada 17m e um ntpd muito podre e
subotimo me da 20ms de falha de precisão, eu tenho o risco de 20ms a cada
17m, que me da 70,4ms por hora, suficiente pro ntpdate ir la e corrigir não
é?

>  ou seja eu perco alguma coisa (de novo, com pragmatismo) que eu nao
>> percebi, usando ntpdate preferencialmente?
>>
>
> perde a estimativa de quanto você está errado, que é muito importante em
> qualquer medida.
>
> faz como você quiser, mas depois não reclama se não conseguir cruzar seus
> logs com terceiros, ou prejudicar um cliente porque o relógio estava
> adiantado 1 maldito segundo.
>

a maior parte dos sistemas de log, salvo qmail, por default usam epoch como
medida convertido pra algum timezone
estamos então falando de epoch, onde 1 segundo faz diferença mas um drift
rate abaixo disso nao
em um processo legal nunca soube de um perito que tivesse contestado a
aceitação de logs como evidencia condicionado ao drift time, inclusive
sequer tem perito que vira e fala "agora me da o drift log do relógio usado
pra garantir essa hora", ao contrario é regra comum na pericia aceitar até
2s de divergência entre logs, o que ja seria exagero, um relógio 0.59s
atrasado so vai mostrar divergência de 1s entre registros

meu iPad por exemplo tem sempre uma divergência de 1 segundo de qualquer
outro sistema, sei la o motivo ja que ele deveria estar sincronizado com a
Apple ou operadora, mas 1 segundo não faz diferença sequer pra OTP, ou seja
uso Google Authenticator e afins numa boa com esse atraso. uso até Apache
mod_authn_otp a partir desse ipad, e o mod authn otp por padrão so valida o
token por 6 segundos

minha referencia do que não pode acontecer, continua sendo 1segundo de
diverencia

mas voltando a um ponto:
se o ntpd vai acabar na pratica trabalhando a cada 17m, colocar o ntpdate
*/17 ao invés de @hourly vai me dar o mesmo "risco" de atraso então? e eu
só não terei o drift rate?

outra coisa, que também estou muito errado, ou o ntpdate me serve melhor, é
essa rastreabilidade do quanto estou divergente

# grep ntpdate /var/log/messages
(ntpdate -s -p 6 a.ntp.br b.ntp.br c.ntp.br gps.ntp.br time.apple.com
ntp.isc.org)
15 Feb 9:00:57 ntpdate[57891]: adjust time server 200.160.7.193 offset
-0.000846 sec
(ntpdate -s -p 6 a.ntp.br b.ntp.br c.ntp.br gps.ntp.br time.apple.com
ntp.isc.org 2.freebsd.pool.ntp.org)
15 Feb 10:00:11 ntpdate[57896]: adjust time server 200.160.7.186 offset
0.000596 sec
(ntpdate -s -p 6 a.ntp.br b.ntp.br c.ntp.br gps.ntp.br time.apple.com
ntp.isc.org 2.freebsd.pool.ntp.org)
15 Feb 11:00:41 ntpdate[57903]: adjust time server 200.160.7.186 offset
-0.000077 sec

eu consigo ver pelo offset do ntpdate uma precisão maior de divergência ka
no drift file a precisão é menor:

# tail -F /var/db/ntpd.drift
0.000
0.000
0.001
0.000
0.000
0.000
0.001
0.000
0.000
0.000

então -0.000846, 0.000596, -0.000077 é mais relevante que 0.000 e pra
chegar em 0.001 eu nem sei a referencia de quando era 0.000,
alem do que o driftfile so me mostra o current offset, se voce não
acompanhar com um -F ou não fazer algo por conta propria voce não tem a
referencia histórica que a saída do ntpdate no crontab da
ou seja, de novo, se um perito fanfarrão pedir o driftfile, não vai servir
pra nada ja que os momentos de divergência não serão estimados registro a
registro do log

pessoalmente acho o drift inutil, "ah eu estava 0.001 segundos errados da
ultima vez que o ntpd sincronizou"... e dai? e antes disso? e antes de
antes disso? como tem sido sua referencia historica? 0.001 é melhor que
-0.001 no seu sistema? as coisas estão "piores" ou "melhores" do que
costumam estar normalmente? o drift não vai responder nada disso... voce
vai ter que monitorar de outras formas; o ntpdate vai dar essa referencia
periodica/historica sempre, e com "-s" no cron voce tem ela nos logs

>
> -- Danton.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>