OpenNTPD - l'autre démon NTP

• 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).