Un serveur Debian Stable (5.0.3) est en cours d'exécution ntpd
et connecté à Internet. Pourtant, l'horloge système est erronée d'environ 5 minutes.
$ /etc/init.d/ntp status
NTP server is running..
Les parties pertinentes (je pense) de /etc/ntp.conf
:
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
Je sais que NTP n'apporte pas nécessairement l'heure à l'heure immédiatement. Cependant, combien d'heures ou de jours devez-vous attendre pour vous attendre à ce que NTP ait fait son travail et synchronisé l'horloge?
Suis-je en train de manquer un autre fichier de configuration ou une autre option, ou simplement de faire quelque chose de mal? Est-ce que ntp (au lieu de par exemple ntpdate ) est le bon outil pour cela? Existe-t-il un moyen rapide de vérifier si la configuration est correcte et si les serveurs NTP choisis renvoient l'heure correcte?
Edit : la sortie de ntpq -p
est:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.nexellent.n .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-madrid .INIT. 16 u - 1024 0 0.000 0.000 0.000
sinister.wzw.tu .INIT. 16 u - 1024 0 0.000 0.000 0.000
dnscache-frankf .INIT. 16 u - 1024 0 0.000 0.000 0.000
Edit 2 : La ntpdate -u 0.europe.pool.ntp.org
commande Turns out ( suggérée par Brent ) revient
17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found
... même si sur d'autres machines cette commande fonctionne bien. Nous allons donc examiner les paramètres réseau / pare-feu pour ce serveur particulier (qui se trouve dans un réseau différent, accessible via VPN).
Résolution : le coupable n'était pas le pare-feu local sur notre serveur, mais les paramètres du pare-feu quelque part dans le réseau environnant. Nous avons donc demandé au fournisseur d'hébergement de serveurs d'autoriser NTP pour nos machines, et maintenant cela fonctionne très bien. Par exemple, ntpq -p
retourne maintenant:
remote refid st t when poll reach delay offset jitter
==============================================================================
ns1.eunet.fi 192.36.144.23 2 u 10 64 1 1.043 0.258 0.001
ns2.eunet.fi 62.142.10.44 2 u 9 64 1 0.671 0.135 0.001
ns3.eunet.fi 62.142.10.44 2 u 8 64 1 0.750 0.277 0.001
(Nous avons également basculé sur les serveurs eunet.fi recommencés par la société d'hébergement, mais c'est à côté du point.) Les commandes dans la réponse de brent ont été utiles car elles m'ont fait comprendre que le problème était dans l'accès réseau aux serveurs NTP, pas dans la configuration NTP lui-même. Merci tout le monde!