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

Evandro Nunes evandronunes12 at gmail.com
Sat Feb 14 15:07:56 -02 2015


prezados

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.
mas na pratica o que eu percebo é que os argumentos pra essa troca,
sicronia continua, referencia de multiplos servidores e multiplas amostras,
na prática não são uma vantagem do ntpd ou desvantagem do ntpdate ja que:

- o ntpdate pode (e deve) ser usado contra multiplos servidores, a man page
diz: quanto mais, melhor
- o ntpdate pode pegar multiplos samples de cada servidor, de fato por
padrao ao menos em sistemas bsd ja sao 4 samples sem o sysamdin configurar
nada
- uma vez obtidos multiplos samples de multiplos servidores, o algoritimo
que vai ajustar a hora é exatamente o mesmo no ntpd e no ntpdate

entao o que sobra é a sincronia continua vs periodica como maior diferenca

eu tenho feito um teste simples e pratico, rodando ntpd e ntpdate em
maquinas distinas, no caso do ntpdate eu rodo:

- @reboot (just in case...)
- @hourly

dizem que um servidor deveria atrasar 1 segundo a cada ano, e alguns dizem
com que HZ do kernel acima de 2000 esse atraso pode chegar a 1.89 segundos
ao ano, ou seja @hourly deveria ser mais que suficiente e a sincronia
continua do ntpd nao parece justificavel savo intervencao explicita no
relogio do sistema

na minha comparacao ainda fiz questao de cuidar para que

- ao menos 5 servidores no ntpdate
- mesmos 5 primeiros servidores listados no conf do ntpd

e minhas conclusoes baseadas em observacao pratica sao:

- 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

- 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...

- mais facil colocar 2 linhas no crontab do que configurar o ntpd.conf

minha ultima observacao acima na verdade é o que motivou meu teste
eu tenho que cuidar de diversos sites, em diversas cidades, com uma equipe
enxuta e sistemas hibridos e mistos. padronizo borda e firewall mas
internamente cada equipe tem sua autonomia entao eu preciso definir as
regras basicas a serem seguidas seja em em linux-based, bsd-based,
routeros, ou o que seja
e o que notei, olhando meu proprio quintal, é que existe uma vontade muito
grande de subir o ntpd e esquecer

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

claro, ai que entra bcp, melhores praticas, e o trabalho exatamente que eu
tive que fazer, definir as regras gerais pra uso de ntp e recomendacao
interna de como configura-lo, ou nao usa-lo se for o caso...

com base nas minhas observacoes, eu conclui e padronizei o seguinte:

- usar preferencialmente ntpdate, com uma lista recomendada de servidores,
samples, e em frequencias recomendas, ou seja no Wiki compartilhado entre
as equipes esta colada a linha no cron como deve ficar
- se desejar usar ntp como cliente, configurar acl e nao ouvir na udp/123,
ta la o exemplo de ntp.conf no Wiki interno
- se precisar ntpd em modo servidor, configurar acl com especial atencao,
usar o mesmo daemon pra cliente e nao usar ntpdate, esta la o sample conf
no Wiki interno

entao vem a primeira questao que quero saber a opiniao dos colegas

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

ou seja eu perco alguma coisa (de novo, com pragmatismo) que eu nao
percebi, usando ntpdate preferencialmente?

o que me chama atencao é que se um ambiente como o meu, existe o deslize
(normalmente por falta de tempo nas pessoas terem que pensar em tudo) de
subir o ntpd sem cuidar da udp/123 escancarada (e dai veio a necessidade de
uma bcp e padronizar rpaticas internas), que dira com os 99% do mundo e dos
linux, mikrotik, etc, que vem com ntpd escancarado quando se liga o
servico...

nesse sentido se a recomendacao por exemplo do Nic.Br fosse em favor de
ntpdate ao inves de ntp, nao seria mais seguro pro mundo todo?

afinal no proprio site do nic.br nao se chama atencao as melhores praticas,
falta no minimum um paragrafo sugerindo nao ouvir na UDP/123 se for apenas
cliente e configurar controle de acesso explicitamente e responsavelmente
se precisar do NTPD em modo servidor...

no proprio ntp.br chega-se ao preciosismo de ensinar compilar a partir dos
fontes e monitorar, mas o sample conf nao cuida da seguranca

de novo, o ponto é, um sample sugerido de ntpdate seria mais facil, menos
sucetivel a erros por parte de quem vai subir o NTP, pq como todo daemon, o
ntpd da um "trabalhinho a mais" que seria eliminado pelo uso do ntpdate em
modo cliente...

entao, na pratica, pra que ntpd se nao for pra servir?

por favor nao levem a mal, minha intencao é exatamente oposta a criticar
quem use ntpd, é entender qual vantagem do ntpd eu posso estar ignorando,
ja que nas minhas percepcoes estou inclinado a recomendar algo que vai
exatamente no sentido oposto do que nic.br e varios sites de linux
recomendam, que é descontinuar o ntpdate em favor do ntpd...

estou no caminho do djb e do paul vixie que historicamente se atacam e
concordam em poucos pontos, mas ambos defendem ntpdate em modo cliente, mas
preciso validar ou rever minha posicao, entao... o que eu perco? ntpd pra
que?

obg,



More information about the gter mailing list