- Introduction
OpenNTPD est le démon NTP du projet OpenBSD.
En général, c’est un autre démon NTP qui utilisé “par défaut” sous Gnu/Linux, il s’agit de ntpd ( Package Debian ntp)
Attention, dans les 2 cas le binaire s’appelle /usr/sbin/ntpd.
OpenNTPD présente, à mon sens et pour une utilisation générale (synchronistaion du serveur lui-même), deux avantages sur ntpd :
- Il n’ouvre pas de port en local (par défaut).
A ma connaissance il n’est pas possible de restreindre ceci avec ntpd ??? - Sa configuration me semble beaucoup plus facile et limpide que celle de ntpd (même si les fonctionnalités ne sont pas forcément les mêmes).
Un démon NTP présente à mon sens et pour une utilisation générale, deux avantages principaux sur des clients NTP comme ntpdate:
- Les démons (qui utilisent
adjtime) ne provoquent pas de changement brutaux de l’horloge (et encore moins des changements “dans le passé” qui provoquent l’arrêt de certains services) - Les démons peuvent “gérer” les connexions vers plusieurs serveurs NTP (par exemple notion de “retry” ou de priorité).
Tests en vrac
(A noter que les résultats sont surement les mêmes avec ntpd que ceux ci-dessous réalisés avec OpenNTPD)
$ date -R
Sun, 30 Dec 2007 15:22:53 +0100
J’avance d’environ 5 minutes (pas + de 42 minutes) [1]
$ sudo date -s "Sun, 30 Dec 2007 15:28:53 +0100"
dimanche 30 décembre 2007, 15:28:53 (UTC+0100)
On démarre le démon:
$ sudo /etc/init.d/openntpd start
Starting openntpd: ntpd.
Voici les logs:
Dec 30 15:30:17 bipbip ntpd[12524]: adjusting local clock by -333.503437s
Dec 30 15:33:24 bipbip ntpd[12524]: adjusting local clock by -333.484404s
Dec 30 15:36:08 bipbip ntpd[12524]: adjusting local clock by -333.377035s
Dec 30 15:39:48 bipbip ntpd[12524]: adjusting local clock by -333.287172s
Dec 30 15:43:27 bipbip ntpd[12524]: adjusting local clock by -333.168930s
Dec 30 15:45:41 bipbip ntpd[12524]: adjusting local clock by -333.087043s
Dec 30 15:49:47 bipbip ntpd[12524]: adjusting local clock by -332.961041s
Dec 30 15:51:58 bipbip ntpd[12524]: adjusting local clock by -332.854474s
Dec 30 15:56:01 bipbip ntpd[12524]: adjusting local clock by -332.726167s
Dec 30 16:00:20 bipbip ntpd[12524]: adjusting local clock by -332.589575s
Dec 30 16:03:07 bipbip ntpd[12524]: adjusting local clock by -332.470866s
On peut observer que:
-
La correction est d’environ une seconde en l’espace de 30 minutes.
-
L’écart se réduit mais en aucun cas le serveur ne fait un saut “dans le passé” pour revenir à l’heure réelle.
Extraits des man:
L’ajustement réalisé par adjtime() sur l’horloge est exécuté afin que l’horloge soit toujours incrémentée de façon monotone. Utiliser adjtime() pour ajuster le temps prévient les problèmes qui peuvent se poser avec certaines applications (par exemple, make(1)) lors de sauts temporels abrupts positifs ou négatifs de l’horloge système.
Si l’ajustement dans delta est positif, alors l’horloge système est accélérée d’un faible pourcentage (par exemple, en ajoutant une petite quantité de temps à chaque seconde de l’horloge) jusqu’à ce que l’ajustement soit réalisé. Si l’ajustement dans delta est négatif, l’horloge est ralentie selon le même procédé.
(Open)ntpd uses the adjtime system call to correct the local system time without causing time jumps. Adjustments larger than 128ms are logged using syslog. The threshold value is chosen to avoid having local clock drift thrash the log files.
Testons donc maintenant en retardant cette fois d’une minute environ (au lieu d’avancer de 5 minutes)
$ date -R
Sun, 30 Dec 2007 16:01:02 +0100
$ sudo date -s "Sun, 30 Dec 2007 16:00:00 +0100"
dimanche 30 décembre 2007, 16:00:00 (UTC+0100)
Dec 30 16:01:44 bipbip ntpd[12621]: adjusting local clock by 72.942552s
Dec 30 16:05:19 bipbip ntpd[12621]: adjusting local clock by 72.925635s
Dec 30 16:07:42 bipbip ntpd[12621]: adjusting local clock by 72.849986s
Dec 30 16:10:33 bipbip ntpd[12621]: adjusting local clock by 72.782798s
Dec 30 16:12:46 bipbip ntpd[12621]: adjusting local clock by 72.695125s
Dec 30 16:16:33 bipbip ntpd[12621]: adjusting local clock by 72.634382s
Dec 30 16:19:52 bipbip ntpd[12621]: adjusting local clock by 72.513312s
Dec 30 16:23:46 bipbip ntpd[12621]: adjusting local clock by 72.437547s
Dec 30 16:26:51 bipbip ntpd[12621]: adjusting local clock by 72.338498s
Dec 30 16:30:07 bipbip ntpd[12621]: adjusting local clock by 72.245159s
Dec 30 16:33:46 bipbip ntpd[12621]: adjusting local clock by 72.181572s
Dec 30 16:38:02 bipbip ntpd[12621]: adjusting local clock by 72.057567s
Dec 30 16:40:49 bipbip ntpd[12621]: adjusting local clock by 71.994909s
Dec 30 16:45:07 bipbip ntpd[12621]: adjusting local clock by 71.881804s
La correction est d’environ une seconde en l’espace de 45 minutes.
On a donc, dans un sens comme dans l’autre, une correction de l’heure très “douce”, à la manière de la dérive “normale” d’une horloge.
[1]
adjtime() est prévue pour faire de petit ajustement de l’horloge système. La plupart des systèmes impose une limite à l’ajustement qui peut être spécifié dans delta. Dans l’implémentation de la glibc, delta doit être inférieur ou égal à (INT_MAX / 1000000 - 2) et supérieur ou égal (INT_MIN / 1000000 + 2) (respectivement 2145 et -2145 secondes sur les x86).
Si je teste une différence d’une heure on obtient:
Dec 30 18:12:11 bipbip ntpd[12693]: adjusting local clock by -3860.229766s
Dec 30 18:12:11 bipbip ntpd[12693]: adjtime failed: Invalid argument
Donc pour un gros ajustement ntpdate peut être utile… (mais attention aux effets sur les services qui tournent comme par exemple Dovecot).