Como configurar o servidor ntp local sem acesso à internet no Ubuntu?

Question

Eu tentei vários guias sobre como configurar um servidor ntp local no Ubuntu, mas nenhum parece funcionar corretamente. Meus servidores estão à deriva no tempo por algum motivo e eu tenho que manter seu tempo juntos porque eu executo bancos de dados que exigem isso.

• Eu tenho 8 servidores LTS 14.04 do Ubuntu, nenhum deles tem acesso à internet
• Eu quero executar um servidor ntp em um (ou mais, se for melhor) dos servidores e ter todos os outros servidores conectados ao (s) servidor (es) ntp para definir o horário

Atualmente, meu servidor (ip .24) executa este /etc/ntp.conf:

server 127.127.1.0 prefer
fudge  127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

# Give localhost full access rights
restrict 127.0.0.1

# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap

broadcast 192.168.178.0

E nos "clientes":

# Point to our network's master time server
server 192.168.178.24 iburst
fudge 192.168.178.24  stratum 10

restrict default ignore
restrict ::1
restrict 127.0.0.1
restrict 192.168.178.24 mask 255.255.255.255 nomodify notrap noquery

driftfile /var/lib/ntp/drift

minpoll 4
maxpoll 5

Observação: Eu usei o Multi-Tabbed Putty para enviar os seguintes comandos para todos os clientes ntp ao mesmo tempo. Parei os serviços ntp para todos, exceto o servidor, usei sudo ntpdate 192.168.178.24 para que eles recuperassem a data e reiniciassem os serviços ntp posteriormente. Isso foi bem sucedido. Todos os servidores mostraram a mesma data logo após o término do comando. Após cerca de 10 minutos, meus servidores mostram o seguinte:

Fr 30. Sep 11:16:53 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016 (server .24) 
Fr 30. Sep 11:16:50 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:17:05 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016

Como tê-los corretamente sincronizados com o servidor ntp? E como posso diminuir o tempo de pesquisa? Parece que meus servidores estão ficando sem sincronização rápida, então preciso que eles recuperem o horário "correto" novamente ...

Com a hora "correta", quero dizer uma hora que é a mesma para todos os servidores. Não precisa necessariamente ser o tempo exato do mundo correto (se você chamar assim).

Editar: Eu tentei a configuração sugerida. Tanto quanto eu entendi, é assim que minhas configurações de servidor / cliente devem ser. Enquanto isso, vi que meu servidor .24 está passando por um momento pior. O servidor .20 é o mais preciso e eu estou usando o servidor .20 agora para hospedar o servidor ntp. Desculpe pela confusão.

Configuração do servidor:

# Use the local clock
server 127.127.1.0 prefer
fudge  127.127.1.0
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

# Give localhost full access rights
restrict default

# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap

broadcast 192.168.178.0

Para os clientes:

# Point to our network's master time server
server 192.168.178.20 iburst

restrict default

driftfile /var/lib/ntp/drift

minpoll 4
maxpoll 5

ntpq -as e ntpq -pe no servidor:

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 41906  963a   yes   yes  none  sys.peer    sys_peer  3
  2 41907  8811   yes  none  none    reject    mobilize  1

ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.           5 l   60   64  377    0.000    0.000   0.000
 192.168.178.0   .BCST.          16 u    -   64    0    0.000    0.000   0.000

Cinco vezes a saída semelhante como essa (esses servidores se deslocam no tempo):

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 62104  9024   yes   yes  none    reject   reachable  2


ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 hadoop20.xx LOCAL(0)         6 u   27   64  377    0.151  63591.8 33407.0

Para dois (mais provável?) clientes em atividade:

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1  7757  963a   yes   yes  none  sys.peer    sys_peer  3

ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*hadoop20.xx LOCAL(0)         6 u   18   64  377    0.183    7.883   3.015

edição 2:

Eu usei sudo service ntp stop , sudo ntpdate 192.168.178.20 , aguarde o término do ntpdate, sudo service ntp start em todos os clientes. Ainda existem apenas 2 clientes sucessivos e 5 clientes rejeitados.

Os clientes rejeitados mostram essa saída. Os valores de delay + offset parecem altos porque os clientes com falha se desviam no tempo. Talvez eles não estejam confiando no servidor para atualizar o tempo porque o atraso / deslocamento é tão alto?

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 20981  905a   yes   yes  none    reject    sys_peer  5

ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 hadoop20.xx LOCAL(0)         6 u   34   64    3    0.166  18665.9 16201.3

Eu também tentei usar este link resposta, ele funciona por cerca de 30 segundos, em seguida, o estado muda para "rejeitar" novamente! O mesmo para ntpdate -s 192.168.178.20 . É mais provável que esteja relacionado aos clientes ntp que rejeitam o horário do servidor. Existe uma maneira de forçá-los a mudar o tempo?

    

Answer 1

Não faça isso. A sério. Apenas não faça. As pessoas continuam tendo a ideia de que o NTP é projetado para permitir que um monte de máquinas tenha o mesmo tempo . Não é. Ele foi projetado com muito cuidado para permitir que muitas máquinas tenham a coisa mais próxima possível do tempo correto , o que não é a mesma coisa.

Se você tiver acesso a uma janela, poderá criar um servidor de camada de estratos meio decente

Mas se você realmente precisa fazer o que está fazendo, precisa perceber que está corrompendo o ntpd, e isso significa entender o que você está fazendo.

No servidor

server 127.127.1.0 prefer
fudge  127.127.1.0 stratum 10

significa " use o relógio indisciplinado local como se fosse autoritativo ", que é o que você quer. Não sei por que você está forçando o estrato 10, no entanto; considere eliminar o stratum 10 e deixar o driver fornecer seu estrato padrão de 0. Nos clientes

server 192.168.178.24 iburst
fudge 192.168.178.24  stratum 10

não faz sentido algum. fudge 127.127.x.y é reservado para forçar o uso de vários tipos de drivers de relógio locais. Não faz sentido dar-lhe qualquer outro endereço. Elimine a linha fudge dos clientes e aponte-os para o servidor. Você também está usando uma rede fechada, então descarte todas as coisas de segurança até conseguir o seguinte:

restrict default

Se isso ainda não funcionar, precisaremos ver a saída de ntpq -c as e ntpq -c pe no servidor e em um cliente mal comportado, após pelo menos dez minutos de execução ininterrupta .

Editar : você escreve em um comentário abaixo que " eu acho que o deslocamento / jitter é realmente alto porque os clientes com falha deriva no tempo ".

Eu acho que você pode estar certo. O blog deste sujeito sugere que ele teve a mesma experiência: que o relógio do cliente era tão ruim que enganou o local ntpd em pensar que o servidor não era confiável. Ele escreveu

the reason for the huge jitter finally seems clear! Our clock drifts so fast that the offset will go up by several seconds through our few measurements

Dado que são os seus clientes cujo tempo passa mais rapidamente, que não estão a sincronizar (marcando o servidor como "rejeitar"), acho que está a ver o mesmo efeito. Sua solução foi usar adjtimex para ajustar manualmente o relógio do kernel (ajustando o valor tick ) até que o relógio do sistema fosse menos instável, quando o ntpd teve a chance de reconhecer o servidor como sendo OK e sincronizar com ele. Provavelmente, você deveria tentar primeiro o pior cliente e ver se isso ajuda.