problèmes de server ntp. Il panique et puis je suis 3h avant

Je ne suis pas sûr de ce que j'ai mal configuré et je ne peux pas mettre en place un server ntp digne de confiance. Notez qu'il ne s'agit que d'un server intranet ntp.

Le server est un système slackware et donc le file de configuration est basé sur le model que j'ai trouvé là:

interface ignore wildcard interface listn 127.0.0.1 interface listn eth0 interface listn eth1 server 3.gr.pool.ntp.org iburst server 1.europe.pool.ntp.org iburst server 0.europe.pool.ntp.org iburst server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift multicastclient 224.0.1.1 # listn on default 224.0.1.1 broadcastdelay 0.008 ressortingct default kod nomodify notrap noquery nopeer ressortingct 3.gr.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery ressortingct 1.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery ressortingct 0.europe.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery ressortingct 192.168.18.0 mask 255.255.255.0 nomodify notrap ressortingct 127.0.0.1 logfile /var/log/ntp.log 

pour un vidage du conf avec commentaires voir: http://pastebin.com/TP0KyRV7

notez que le réseau 192.168.18.0 est l'intranet local utilisé par ce server ntp.

un extrait du journal des derniers mois. Je ne vois aucune information utile.

 30 Nov 15:41:12 ntpd[28591]: 194.177.210.54 interface 192.168.201.210 -> (none) 30 Nov 15:41:12 ntpd[28591]: Deleting interface #1 eth0, 192.168.18.10#123, interface stats: received=136483, sent=136483, dropped=0, active_time=7277307 secs 30 Nov 15:41:12 ntpd[28591]: Deleting interface #0 lo, 127.0.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7277307 secs 30 Nov 15:41:12 ntpd[28591]: 127.127.1.0 interface 127.0.0.1 -> (none) 30 Nov 15:41:12 ntpd[28591]: peers refreshed 30 Nov 15:41:15 ntpd[28591]: ntpd exiting on signal 15 1 Dec 13:56:56 ntpd[1650]: Listen normally on 6 multicast 224.0.1.1 UDP 123 1 Dec 13:56:56 ntpd[1650]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 5 Dec 22:51:42 ntpd[18694]: Listen normally on 6 multicast 224.0.1.1 UDP 123 5 Dec 22:51:42 ntpd[18694]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 27 Feb 14:17:23 ntpd[18694]: Deleting interface #5 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: Deleting interface #4 eth0, fe80::21a:92ff:fe3a:ac17#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 sec s 27 Feb 14:17:23 ntpd[18694]: Deleting interface #3 eth1, fe80::211:6bff:fe32:f77e#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 sec s 27 Feb 14:17:23 ntpd[18694]: Deleting interface #2 eth0, 192.168.18.10#123, interface stats: received=120122, sent=120122, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: Deleting interface #1 eth1, 192.168.201.210#123, interface stats: received=6261, sent=7292, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: 155.207.113.227 interface 192.168.201.210 -> (none) 27 Feb 14:17:23 ntpd[18694]: Deleting interface #0 lo, 127.0.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=7226742 secs 27 Feb 14:17:23 ntpd[18694]: 127.127.1.0 interface 127.0.0.1 -> (none) 27 Feb 14:17:23 ntpd[18694]: peers refreshed 27 Feb 14:17:27 ntpd[18694]: ntpd exiting on signal 15 27 Feb 17:32:45 ntpd[1642]: Listen normally on 6 multicast 224.0.1.1 UDP 123 27 Feb 17:32:45 ntpd[1642]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 12 Mar 22:11:51 ntpd[9153]: Listen normally on 6 multicast 224.0.1.1 UDP 123 12 Mar 22:11:51 ntpd[9153]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 12 Mar 22:11:51 ntpd[9153]: ntpd: time slew +0.000000 s 12 Mar 19:40:09 ntpd[9564]: Listen normally on 6 multicast 224.0.1.1 UDP 123 12 Mar 19:40:09 ntpd[9564]: Joined 224.0.1.1 socket to multicast group 224.0.1.1 

mais de time en time le server ntp cessera de fonctionner. Quand je le vérifie à nouveau, il a dérivé 3 heures d'avance. Et je ne pense pas que ces 3 heures soient un nombre random. Cela peut être lié au fait que je suis à l'heure EET (ou EEST).

Le time du BIOS est réglé sur l'heure locale (comment puis-je vérifier cela depuis linux?)

Après avoir exécuté ntpdate 3.gr.pool.ntp.org , j'obtiens ce qui suit:

 root@halki:~# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +postmortem.csd. 122.231.59.246 2 u 18 64 1 15.646 21.219 0.471 *ntp.jine.se 192.36.144.22 2 u 16 64 1 78.292 3.687 0.251 +static-ip-85-25 192.168.100.15 2 u 15 64 1 50.748 -2.676 1.071 LOCAL(0) .LOCL. 10 l 25 64 1 0.000 0.000 0.000 

Y a-t-il quelque chose qui ne va pas avec mon file ntp.conf?

Peut-être avec les parameters de timezone de mon système?

Je ne suis pas sûr de savoir comment les vérifier. Je sais que j'ai sélectionné "Europe / Athens" lors de l'installation il y a quelques années, mais en écho à la variable timezone $ TZ renvoie une string vide.

date semble correcte pour le moment, mais je ne peux pas être certain que ça restra comme ça.

 root@halki:~# date Thu Mar 12 20:22:39 EET 2015 

quelqu'un peut-il donner quelques indications sur ce qui pourrait être faux / quoi vérifier?

MODIFIER

dans slackware linux, le file de configuration de l'horloge matérielle se trouve dans /etc/hardwareclock . Ceci est réglé sur "localtime" dans mon cas. Ce file est vérifié lors du démarrage par /etc/rc.d/rc.S afin de régler l'horloge en UTC ou en heure locale.

Il semble y avoir quelque chose qui ne va pas avec le CCF.

 root@halki:/etc# hwclock --show --debug hwclock from util-linux 2.21.2 hwclock: Open of /dev/rtc failed: No such file or directory No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method. 

Cela ne semble pas normal. Peut-être qu'il manque quelque chose dans mon kernel, mais quelqu'un peut-il vérifier?

mais de time en time le server ntp cessera de fonctionner. Quand je le vérifie à nouveau, il a dérivé 3 heures d'avance. Et je ne pense pas que ces 3 heures soient un nombre random. Cela peut être lié au fait que je suis à l'heure EET (ou EEST).

Si cela signifie une machine redémarre et puis time foiré, Il peut être à cause de votre operating system, à tort, pense que l'horloge matérielle indique l'heure UTC. Ensuite, il ajoute 3 heures au time qui a répondu par le matériel.

Ainsi, si le problème survient après un redémarrage, dites au operating system que le matériel stocke le time en tant qu'heure locale (qui, par votre date de sortie, est dans le timezone EET):

 # hwclock --localtime 

Réglez ensuite l'heure du système par date -d , jusqu'à ce que vous obteniez l'heure correcte. En fin de count, économisez ce time dans l'horloge matérielle:

 # hwclock --systohc 

Le time du BIOS est réglé sur l'heure locale (comment puis-je vérifier cela depuis linux?)

hwclock dit quelle date est stockée ici mais il ne vous dira pas qu'il est correct de le voir comme UTC ou heure locale; Il attend que vous l'informiez à ce sujet.

Je ne suis pas sûr de savoir comment les vérifier. Je sais que j'ai sélectionné "Europe / Athens" lors de l'installation il y a quelques années, mais en écho à la variable timezone $ TZ renvoie une string vide.

Votre timezone est imprimé par date . Vérifiez /etc/timezone qui peut contenir le nom du timezone, par exemple Europe / Athens ou /etc/localtime qui peut contenir (ou être lié à un file contenant) des données zoneinfo; comme les files résident dans /usr/share/zoneinfo .

Il devrait y avoir un file de configuration sous /etc qui indique si l'horloge matérielle est réglée sur UTC ou heure locale. Ce drapeau devrait être utilisé au redémarrage pour ajuster l'heure du système si nécessaire. Sur Ubuntu, le file est /etc/default/rcS .

Il devrait également y avoir un endroit où vous pouvez append des drapeaux à la command ntpd quand il démarre. Ajoutez -g aux drapeaux, et ntpd cessera de paniquer au redémarrage. Par défaut, il refusera de démarrer si l'horloge est éteinte de plus de 1000 secondes. Il semble que vous êtes hors de plusieurs fois cette panique si ntpd comme prévu. L'option -g empêchera la panique de démarrage.