Ntp causando problemas

Question

Eu tenho um servidor FreeIPA rodando no Centos 6 e uma de suas funções é fornecer sincronização de tempo para hosts do cliente. NTP é a versão 4.2.6

O problema é que sua própria sincronização NTP não está funcionando corretamente & Eu não consigo ver porque. Isso está afetando as funções de autenticação / Kerberos.

O servidor FreeIPA não pode acessar diretamente a Internet, então precisa usar outro servidor que possa ver a internet.

Aqui está uma listagem nptq do servidor de horário "master" cujo endereço IP é 10.20.1.23.

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*46.101.52.119   81.174.136.35    2 u  111  128  377   10.234    0.865   3.491
+51.141.4.8      85.199.214.102   2 u  121  128  377   14.806   -0.365   2.858
+178.62.16.103   195.66.241.3     2 u  117  128  377   10.677    0.816   1.931
+129.250.35.250  249.224.99.213   2 u  100  128  377   14.064   -1.678   1.525

Todas as coisas bem normais. 46.101.52.119 está sendo usado como referência

Aqui está a saída de outro cliente usando esse servidor para sincronização de horário

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.20.1.23       46.101.52.119    3 u  230  256  377    0.439  1095.65  34.637
 127.127.1.0     .LOCL.           5 l  49m   64    0    0.000    0.000   0.000

Não há problema em me dizer que 10.20.1.23 está usando 46.101.52.119 como seu ref

Mas quando eu vou para mim servidor FreeIPA eu recebo

# ntpq -pn
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.20.1.23       LOCAL(0)         6 u   97  128  377   32.193  92334.0  17.646

O refid é diferente e diz-me que temos cerca de um minuto & meio desvio. Na verdade, eu coloco os relógios dentro de um segundo à mão, mas agora ele está sendo retirado pelo ntpd.

    

Answer 1

Veja também: Por que NTP sincronizando com o servidor LOCAL em vez de remoto?

O que parece estar acontecendo é que o relógio local está correndo muito rápido em relação à fonte de tempo com a qual ele está tentando sincronizar. Como resultado, ele destrói a fonte de sincronização e combina com o que acha ser a melhor resposta, que é o próprio timesource do kernel local. Há algumas coisas que você pode fazer para ajudar a aliviar essa condição e tentar melhorar o formato do seu relógio local.

Primeiro, para aliviar o problema, você pode definir o relógio local como um estrato superior ao das fontes de sincronização. Um exemplo no seu arquivo ntp.conf seria:

server 127.0.0.1
fudge 127.0.0.1 stratum 16   ## or some value greater than it's synchronization peer

Isso tornará uma fonte menos desejável quando o NTP iniciar a seleção de pares para sincronização.

Em seguida, se o relógio local estiver realmente fora de sintonia, você poderá ajustá-lo usando adjtimex . TENHA CUIDADO, você está jogando com o relógio de hardware neste momento. Um exemplo seria algo como:

# adjtimex -p         ## List out how the clock is currently running...
     mode: 0
   offset: 0
frequency: 0
 maxerror: 0
 esterror: 0
   status: 64
time_constant: 4
precision: 1
tolerance: 32768000
     tick: 9900
 raw time:  1272299204s 17444us = 1272299204.017444
return value = 5

E ajuste o valor do campo "tick":

adjtimex -t 9800

Reinicie o ntpd e veja como ele se comporta. Se isso fizer com que o jitter seja mais aceitável, deixe-o assim ou ajuste-o novamente, se necessário. O NTP pode ser um pouco obscuro e espero ter ajudado, mas se você precisar de mais informações, eu confio na fonte em link

Referências

link

link