L'Internet Rapide et Permanent

Nous avons tous un début (notre naissance) et une fin (notre mort). Nous connaissons en principe la date à peu près exacte de notre début et ignorons généralement jusqu'au dernier moment celle de notre fin, ce qui est probablement plutôt une bonne chose.

Entre les deux évènements, il s'écoule « un certain temps » que seuls ceux qui nous survivent peuvent mesurer avec une assez bonne précision, si ça les intéresse. Pour un fichier informatique, le processus est quasi identique. Il est créé à une certaine date et généralement détruit à une autre, toujours postérieure, de façon volontaire dans le meilleur des cas. Le « toujours postérieure » peut paraitre évident, mais l'est-ce vraiment ? Nous verrons que non.

Quoi qu'il en soit, dans le monde matériel tout du moins, il est possible de mesurer une durée, du moment que l'on dispose d'une unité de mesure, même si l'on ne dispose pas de la notion de date. Mon chat a vécu 18 ans, 9 mois, 6 jours, 2 heures, 25 minutes et 45 secondes. C'est plutôt bien pour un chat, ce serait peu pour un humain, ce serait très peu pour une tortue, mais la tortue étant un animal très lent, ce n'est pas parce qu'elle vit longtemps qu'elle en profite plus. Pour un fichier informatique, tout dépend de la nature de ce qu'il contient (et des accidents qui peuvent se produire).

Dans la chronologie des choses, la durée, c'est bien, mais pouvoir donner une date, c'est pas mal non plus. Wolfgang Amadeus Mozart est mort le 5 décembre 1791 (je n'ai pas trouvé l'heure exacte). C'est plus pratique de se souvenir d'une date que d'un intervalle de temps qui varie sans arrêt, puisque le temps passe. Le 23 juin 2011, la durée qui nous séparait de la disparition de WAM était de 80188 jours, mais nous ne somme déjà plus le 23 juin 2011.

Pour définir une date, il faut définir une origine des dates. En France et dans de nombreux autres pays, cette date est celle (supposée) de la naissance de Jésus Christ. Ainsi Jésus Christ serait né le 00/00/0000:00:00:00 (traditionnellement, minuit) même si l'on sait aujourd'hui que c'est probablement faux. Peu importe, car finalement, ce repère est complètement artificiel, il suffit que l'on s'accorde dessus. Notons tout de même que suivant les cultures, certains pays (certaines ethnies) adoptent une autre origine des temps. Cela complique un peu les choses, mais sans grande gravité, car l'unité de temps (la seconde) étant la même pour tout le monde, les conversions se bornent généralement à de simples additions ou soustractions.

La seconde est l'unité de temps universellement reconnue. Elle est aujourd'hui mesurée avec précision puisqu'elle représente l'intervalle de temps qui s'écoule pendant 9 192 631 770 périodes de la radiation correspondant à la transition entre les niveaux hyperfins de l'état fondamental de l'atome de césium 133. Si vous n'y croyez pas, allez donc consulter le Bureau International des Poids et Mesures. Il n'est pas à la portée de tout le monde de disposer d'une poignée d'atomes de césium 133 et du matériel nécessaire pour en compter les 9 192 631 770 périodes, il nous faudra généralement nous accommoder de systèmes plus simples, mais moins précis. Le pendule d'un mètre, en oscillations de faible amplitude et à une altitude raisonnablement proche du niveau de la mer bat assez bien la seconde. Plus évolué technologiquement, les oscillations propres d'un cristal de quartz bien calibré peuvent servir de référence à une horloge de qualité acceptable.

Nous passerons rapidement sur les faits suivants :

• une minute contient exactement 60 secondes ;
• une heure contient exactement 60 minutes.

La journée elle, est plus compliquée. Vous la voulez sidérale ou solaire ?

La journée sidérale, encore appelée journée stellaire, est régie par une rotation complète de la terre sur elle-même par rapport aux étoiles. Plus de césium 133 de quartz ou de pendule, nous changeons de méthode de mesure. Il ne faudra donc pas s'étonner si ça ne tombe pas « juste ». La loi de « Murphy » aussi appelée « loi de l'emmerdement maximum » fait qu'une journée dure en gros 86 164,098 903 691 secondes, soit 23 heures, 56 minutes et 4 secondes (jour stellaire, mesuré en 1820). Cette durée, en plus d'être variable en fonction de la lune et des gros tremblements de terre, augmente en moyenne de 2,3 millisecondes tous les 100 ans. Nous considérons qu'une journée dure 24 heures pour aller au plus simple.

La journée solaire est probablement plus proche de nos habitudes puisqu'elle est délimitée par deux levers de soleil consécutifs (ça doit fonctionner aussi avec les couchers et avec le zénith). Sa durée varie de 23 heures 59 minutes et 39 secondes à 24 heures 0 minute et 30 secondes. Nous considérons qu'en moyenne, elle fait pile 24 heures.

L'année est le temps que met la terre pour effectuer une rotation complète autour du soleil. Toujours à cause de Murphy, cette durée serait à peu près de 365 jours 5 heures 48 minutes et 45,2606 secondes. Nous parlons ici de l'année tropique. Toujours pour aller vite, nous considérons que l'année fait exactement 365 jours, sauf pour les années bissextiles qui en font 366. En effet, il faudra bien de temps en temps rattraper l'erreur(2).

Il est simple dans notre calendrier grégorien de savoir si une année est bissextile ou non, il suffit de vérifier que l'année est (divisible par 4 ET non-divisible par 100) OU divisible par 400.

Chacun voyant midi à sa porte, si l'on considère midi (12:00:00) comme étant le moment où le soleil est à son zénith (ombre portée au sol minimale), il est clair que le midi ne se produira pas en même temps partout le long d'un même parallèle. Tout va dépendre de la longitude. Ici encore, nous irons au plus rapide et découperons en tranches à l'intérieur desquelles l'heure sera artificiellement la même. Vous avez reconnu le fuseau horaire. Sauf que…

En se référant aux fuseaux horaires seuls, des pays aussi petits que le nôtre se verraient affublés de deux heures différentes à l'est et à l'ouest et nous ne serions pas les seuls dans ce cas en Europe. Aussi a-t-il été décidé pour ladite Europe, de couper la poire en trois. Peu importe puisque finalement, tout ici n'est que convention. Lorsque nous parlons à notre voisin, nous pouvons considérer que nous voyons tous les deux midi en même temps.

C'est un peu plus embêtant lorsqu'un système informatique marseillais (pourquoi faudrait-il absolument qu'il soit parisien ?) discute via l'Internet avec un système informatique situé à Hydaburg (Canada). Puisque nous sommes dans le domaine de l'abstraction, pourquoi ne pas considérer un temps universel, une heure universelle, dé-corrélée de la position solaire, mais la même pour toute la planète, à l'instant T ? Les anglais ont tiré les premiers, et l'heure UTC(3) aussi appelée heure GMT(4) a été définie comme étant l'heure solaire sur le méridien passant par Greenwich. En ce qui nous concerne, dans l'Europe de l'ouest, nous avons droit à l'heure CET(5). Depuis 1973 nous avons même droit à l'heure CEST(6), ce machin qui nous fait sauter une heure au printemps et nous la rajoute un peu après l'automne, parait-il pour économiser l'énergie. Mais ne nous éloignons pas trop du sujet initial. Ce genre d'idée remonte à loin dans l'Histoire, défendue par des personnes qui n'étaient pas reconnues comme étant des idiots pourtant.

Bref, l'important est qu'il y ait une heure de référence, la même pour tous, et peu importe si le soleil est au rendez-vous ou pas. Dans le monde virtuel de l'informatique, il n'y a ni jour ni nuit. Un bit est un bit, il n'a pas d'horloge biologique, n'a pas besoin de lumière, d'obscurité, il ne lui faut qu'un peu d'énergie électrique pour se maintenir en vie.

Dans le monde réel toutefois, lorsqu'un ministre dans un bureau parisien (ce n'est pas de ma faute si c'est organisé ainsi) probablement climatisé (donc énergivore) décide que c'est mieux pour les économies d'énergie de placer par exemple sur une toiture un maçon couvreur travaillant à Oloron-Sainte-Marie en plein mois de juillet à 14h alors que, solairement parlant, il est tout juste midi, peut-être oublie-t-il un détail qui peut avoir une certaine importance pour la santé du maçon en question. Puisque nous en sommes à divaguer, notons aussi que le ministre doit se taper un col de chemise empesé, serré au cou par une cravate, le tout surmonté d'un veston où la transpiration est bannie, ce qui impose de fait l'usage de la climatisation et de tout un tas d'adjuvants chimicocosmétiques, généralement assez peu recommandables sur le plan purement écologique, voire sanitaire. Le maçon, lui, a plus de chance, car il peut s'affubler d'un vieux « T-Shirt » délabré et déjà sale, qui accepte parfaitement la transpiration sans pour autant qu'il paraisse plus maculé ni plus odorant.

Mais revenons à nos bits. Je crée un fichier, je le modifie plusieurs fois, j'y accède en lecture encore plus souvent (à quoi servirait d'écrire si ce n'est pour être lu) et finalement, je le détruis. Il est clair que pour la cohérence, il vaut mieux que je le modifie et/ou le consulte après l'avoir créé et avant de l'avoir détruit faute de quoi j'y perdrais mon latin.

Évident ? Ça ne l'est pourtant pas. J'ai mis mon ordinateur à l'heure (UTC). Je crée un fichier. Mon système de fichier va enregistrer l'heure de création. Nous sommes le 28 mai 2011, à 17h 53 minutes et 25 secondes.

J'éteins alors mon ordinateur. Son horloge CMOS (celle qui persiste à fonctionner, en principe, lorsque l'ordinateur est hors tension) aurait dû continuer à égrener le temps, sauf que la pile est morte silencieusement. Lorsque je redémarre mon ordinateur, le lendemain pourtant, il croit que nous sommes le 1 janvier 1970 (GNU/Linux n'est-ce pas). J'ouvre donc le fichier pour le lire avant de l'avoir créé…

Il est possible de reproduire le phénomène en copiant simplement le fichier sur une machine qui n'est pas à la même heure que l'autre. Téléphonez donc à un américain à 8h (CEST) pour lui dire que c'est l'heure de se lever…

Notons au passage qu'un certain système dont nous tairons le nom positionne l'horloge CMOS non pas sur l'heure UTC mais sur l'heure locale. Ceux qui auraient la curieuse idée de placer ce système en « dual boot » avec un GNU/Linux, auront quelques soucis pour rester à l'heure, en passant d'un système à l'autre.

Il y a dans notre monde des choses qu'il ne faut pas mélanger.

Les systèmes informatiques ont des travaux répétitifs à exécuter. Étant répétitifs, quoi de plus simple que de trouver un moyen de les déclencher de façon automatique ? cron est justement là pour remplir cet office. Cron se fonde sur l'heure à la minute pour exécuter une tâche. Si on lui subtilise justement cette minute, la tâche ne sera pas exécutée. Il ne doit pas y avoir de trous dans l'écoulement du temps, du moins pas de gros trous (inférieurs à une minute en ce qui concerne cron). Si une horloge n'est plus à l'heure, il faut l'accélérer ou la ralentir pour qu'elle rattrape son retard ou perde son avance sans créer de trous ni de recouvrements, du moins lorsque le système est opérationnel. Rien n'interdit en revanche de mettre l'horloge à l'heure au moment du démarrage de la machine, du moins à condition que le saut dans le temps se fasse dans le futur et non dans le passé, ce qui devrait être en principe toujours le cas.

Nous pouvons ici apercevoir le problème qu'il y aurait à utiliser l'heure locale, avec ses sauts temporels bisannuels. Qu'est-il advenu de tout ce que nous avions à faire le 28 mars 2010 entre 2 et 3 heures ?

Pire encore. Ne prévoyez rien à faire le 31 octobre 2010 entre 2 et 3 heures (ni le 30 octobre 2011 aux même heures (etc.)) sauf éventuellement s'il s'agit de tâches particulièrement attrayantes, vous aurez à les accomplir deux fois…

Nous pouvons maintenant évoquer l'heure juste, en sachant à peu près de quoi l'on parle. Grâce aux propriétés du césium 133, nous savons fabriquer des horloges de très grande précision : les horloges atomiques. Sauf cas particulier (GPS), nous ne ferons pas intervenir ce que notre bon Albert Einstein a découvert et nommé « principe de la relativité ».

Si grande soit la précision, elle n'est pas parfaite et il faudra donc de temps en temps réajuster. En réalité nous utilisons une moyenne calculée sur un peu plus de 300 horloges atomiques réparties dans le monde. La précision obtenue sera suffisante pour nos besoins. Il nous faut maintenant rendre cette information accessible à qui en a l'utilité sans l'altérer dans le transport. Le transport, ça introduit des parasites et ça prend du temps. Les parasites rendent l'information inutilisable à l'arrivée, le temps de transport introduit un retard qu'il faut savoir évaluer exactement.

Nous ne pouvons pas nous permettre de ne disposer que de l'accès aux horloges de référence pour avoir l'heure. D'abord ces dernières seraient submergées de requêtes, ensuite il faut prévoir le cas où elles seraient injoignables pendant « un certain temps ». Nos machines disposent donc d'une horloge locale à quartz, dont la fonction est de compter le temps qui passe lorsque la machine est éteinte. Lorsqu'elle est en service, c'est un autre dispositif qui prend le relais, piloté par le système d'exploitation. Le système peut bien entendu lire l'heure sur l'horloge à quartz sauvegardée par pile et même la réajuster.

NTP est donc un protocole dont le but est de permettre non seulement d'obtenir l'heure à peu près exacte à un instant T, mais aussi et surtout de permettre au système d'exploitation de calculer le temps qui passe en se basant sur l'horloge locale de la machine, mais en tenant compte de sa dérive pour la corriger le plus finement possible.

Dans le principe général, au réveil du système, il va lire l'horloge matérielle de la machine, puis va, s'il est configuré pour, interroger un serveur sur l'Internet qui lui donnera l'heure avec une précision de quelques centaines de millisecondes.

S'il s'agit d'une station de travail classique, qui reste rarement en service plus de 12 heures sans interruptions, il est probable que cela suffira, la dérive de l'horloge système n'introduisant pas d'erreur significative sur un temps aussi court.

Si l'on a besoin de plus de précision ou si l'on a affaire à un serveur qui peut rester en service plusieurs mois sans interruptions, il faudra mettre en œuvre un système plus sophistiqué capable de piloter l'horloge locale du système en corrigeant sa dérive au fil du temps. La dérive peut varier en fonction de la température, des champs électromagnétiques, etc. C'est ici que NTP prendra toute sa dimension.

Avant de passer à la pratique et d'installer ce qu'il faut sur notre machine, voyons un peu comment la distribution de l'heure « juste » est distribuée sur l'Internet.

3-3-1. Strate 0▲

3-3-2. Strate 1▲

3-3-3. Strate 2▲

3-3-4. Et au dessous▲

Debian fournit un paquetage qui concerne directement le protocole NTP. Il propose un service qui non seulement peut synchroniser l'horloge système à partir d'autres serveurs de temps, mais fournit lui-même un serveur de temps. Autrement dit, sur notre réseau, nous allons pouvoir monter un ou deux serveurs NTP qui serviront à leur tour à synchroniser tous les nœuds de notre réseau.

Il s'agit du paquet ntp qui nous servira ici pour expérimenter plus en détail le fonctionnement.

3-4-1. Remarque▲

Sachant tout cela, lançons-nous.

aptitude install ntp

Le service ntpd s'installe et démarre.

Debian propose une configuration par défaut qui pourra suffire, mais voyons un peu. Tout se trouve dans /etc/default/ntp et surtout dans /etc/ntp.conf. Commençons par ntp.conf :

# cat /etc/ntp.conf 
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

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


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: 
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page 
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

Pour l'instant, contentons-nous de constater que notre service peut se synchroniser sur l'un des quatre serveurs NTP fournis par Debian. S'il y en a pour quatre, il va y en avoir pour huit. Nous allons ajouter les serveurs du pool français, ce qui donnera finalement :

...
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic
server 0.fr.pool.ntp.org iburst dynamic
server 1.fr.pool.ntp.org iburst dynamic
server 2.fr.pool.ntp.org iburst dynamic
server 3.fr.pool.ntp.org iburst dynamic
...

Pourquoi en mettre autant ? NTP va de toute façon sélectionner le serveur avec lequel il s'entend le mieux et au bout d'un « certain temps » ne discutera quasiment plus qu'avec lui, en s'en gardant éventuellement d'autres sous le coude au cas où.

Il est temps de s'intéresser à l'outil ntpq fourni dans le lot, qui permet de contrôler le fonctionnement de notre serveur.

Commençons par lui demander de recharger sa configuration :

# /etc/init.d/ntp restart

Et voyons ce que nous dirait la commande :

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-213.186.39.202  88.191.101.3     3 u   43   64    3   17.127   10.092   1.230
-88.191.208.84   145.238.203.10   3 u   40   64    3   18.941  -45.045   1.139
+88.191.101.34   192.93.2.20      2 u   40   64    3   19.318   11.263   0.996
-213.186.41.134  207.3.130.6      2 u   40   64    3   17.213   15.455   1.118
-91.121.121.160  131.188.3.220    2 u   39   64    3   21.275    6.880   3.824
*91.121.104.170  193.190.230.65   2 u   38   64    3   21.073   12.006   4.265
+94.23.220.143   195.220.94.163   2 u   36   64    3   20.804   12.691   1.020
-87.98.139.226   62.8.242.2       3 u   35   64    3   20.792   -3.948   3.181

Comme prévu, il y a huit serveurs dans la liste :

• remote indique ici l'adresse du serveur interrogé. Le petit signe qu'il y a à gauche de l'adresse veut bien entendu dire quelque chose. Pour l'instant, retenons que le * indique le serveur qui semble le plus fiable ;
• refid indique la source à laquelle se synchronise le serveur remote ;
• st indique la strate des serveurs remote. La préférence va d'abord aux strates les plus levées, soit la strate 2. Ceci implique que notre serveur sera au mieux de strate 3.

Les autres informations n'ont pour l'instant pas grande valeur, car notre serveur n'est pas encore bien stabilisé. La preuve, le temps de rédiger ces quelques lignes, la situation a déjà évolué :

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-213.186.39.202  88.191.101.3     3 u   36   64  357   17.217    1.182   3.122
-88.191.208.84   145.238.203.10   3 u   35   64  377   17.565  -51.037   0.975
*88.191.101.34   192.93.2.20      2 u   29   64  377   17.867    3.183   2.149
-213.186.41.134  207.3.130.6      2 u   28   64  377   16.988    9.902   2.725
+91.121.121.160  131.188.3.220    2 u   34   64  377   20.976    2.370   1.816
+91.121.104.170  193.190.230.65   2 u   28   64  377   20.959    6.212   2.228
+94.23.220.143   195.220.94.163   2 u   29   64  377   20.518    4.290   2.148
-87.98.139.226   62.8.242.2       3 u   32   64  377   20.754   -9.506   1.717

Et le temps de se préparer et de boire un thé :

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-213.186.39.202  88.191.101.3     3 u   32   64  377   17.318    1.310   1.510
-88.191.208.84   145.238.203.10   3 u   28   64  377   17.237  -48.239   0.733
-88.191.101.34   192.93.2.20      2 u   13   64  377   17.702    2.224   1.260
+213.186.41.134  207.3.130.6      2 u   13   64  377   17.504    4.112   2.381
-91.121.121.160  131.188.3.220    2 u   22   64  377   21.311    0.590   1.485
*91.121.104.170  193.190.230.65   2 u   12   64  377   21.145    5.391   2.067
+94.23.220.143   195.220.94.163   2 u   16   64  377   21.000    3.879   1.862
-87.98.139.226   62.8.242.2       3 u   15   64  377   20.980   -9.606   0.910

Nous savons ce que * indique. Le + indique que le serveur est encore dans la course, mais non sélectionné pour la synchronisation, le - indique que le serveur est pour l'instant hors course, mais pas définitivement écarté. Nous constatons que tous les serveurs de strate 3 sont hors-course. Un x indiquerait un serveur définitivement rejeté.

L'algorithme de sélection du serveur de référence est très fin. Il tient compte de plusieurs paramètres :

• la strate du serveur de référence (st) ;
• son accessibilité (reach) ;
• son temps de réponse (delay) ;
• la variation de son temps de réponse au cours du temps (jitter).

Les valeurs temporelles sont exprimées en millisecondes, dans la réponse de ntpq.

La bonne lecture de la valeur reach ne s'invente pas. Elle représente en base octale le résultat des huit dernières tentatives de connexion au serveur. Ainsi, 377 en base 8 s'écrit 11111111 en binaire, ce qui signifie que les huit dernières tentatives ont abouti. Ceux qui se sont intéressés aux annales du disque-monde savent à quel point le chiffre 8 est lourd de sens magique. Ceux qui ne le savent pas pourront toujours se procurer quelques exemplaires de ces annales, qui leur permettront de passer avantageusement le temps nécessaire à une bonne synchronisation de leur serveur.

Une autre méthode pour observer l'état de notre serveur NTP est d'utiliser la commande ntpdc. Cette commande peut s'utiliser en ligne de commande simple ou en mode interactif. Ainsi, la commande :

root@artemis:~# ntpdc localhost

renvoie juste un prompt :

ntpdc>

Une fois dans ce mode, la commande dmpeers va donner quelque chose d'assez similaire à ntpq :

ntpdc> dmpeers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
.diane.ensma.fr  178.33.165.8     2  128  377 0.05756 -0.001025 0.08131
.core-0.fr.zerol 178.33.165.8     2  128  377 0.05353 -0.000892 0.07669
 ntp.yoinks.net  178.33.165.8     2  128  377 0.16534  0.000262 0.07133
 ks311970.kimsuf 178.33.165.8     3  128  377 0.05753 -0.003685 0.09981
 ns208372.ovh.ne 178.33.165.8     3  128  377 0.05756 -0.002469 0.06572
 sdebns001.news- 178.33.165.8     2  128  377 0.05759 -0.018808 0.08270
 mail.hezzel.org 178.33.165.8     2  128  377 0.05341 -0.002134 0.07578
*dnscache-geneva 178.33.165.8     2  128  377 0.07358 -0.001767 0.05539

Comme les noms sont tronqués, il peut être intéressant d'utiliser la commande listpeers :

ntpdc> listpeers
client    diane.ensma.fr
client    core-0.fr.zeroloop.net
client    ntp.yoinks.net
client    ks311970.kimsufi.com
client    ns208372.ovh.net
client    sdebns001.news-serv.net
client    mail.hezzel.org
client    dnscache-geneva.eu.verio.net

La commande sysinfo est sans doute la plus instructive :

ntpdc> sysinfo
system peer:          dnscache-geneva.eu.verio.net
system peer mode:     client
leap indicator:       00
stratum:              3
precision:            -22
root distance:        0.09793 s
root dispersion:      0.03679 s
reference ID:         [81.93.183.116]
reference time:       d1ad7065.00ca686b  Thu, Jun 23 2011  9:57:25.003
system flags:         auth monitor ntp kernel stats
jitter:               0.001083 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

Nous savons ainsi que notre serveur :

• se synchronise actuellement sur dnscache-geneva.eu.verio.net ;
• fonctionne en mode client ;
• n'a pas de saut temporel prévu (leap indicator) ;
• qu'il est de niveau 3 ;
• et qu'en gros, tout va bien.

Le RFC-1035 détaille tous ces paramètres, pour ceux qui sont vraiment très curieux. Juste quelques explications à propos du leap indicator :

• 00, tout va bien ;
• 01, la dernière minute avait 61 secondes ;
• 10, la dernière minute avait 59 secondes ;
• 11, tout va mal (horloge non synchronisée).

Ces machines étant destinées en principe à tourner 24/7, il nous suffira d'installer le paquet ntp et configurer le daemon pour qu'il se synchronise sur notre (nos) serveur(s) de référence. Ces serveurs deviendront à leur tour des serveurs NTP de strate 4, qu'il sera d'ailleurs inutile d'utiliser comme tels.

L'outil ntpdate sera sans doute le mieux approprié. Cet outil se contentera d'aller chercher l'heure « juste » sur nos serveurs chaque fois que l'interface réseau sera activée. Il y aura naturellement une dérive, mais un système comme GNU/Linux arrive à rendre cette dérive négligeable sur la durée de service. Nous partons du principe que les stations de travail sont redémarrées au moins une fois par semaine et que nous disposons d'une distribution Debian ou dérivée (les autres distributions doivent toutefois fournir des outils similaires).

Le paquet ntpdate contient l'utilitaire du même nom, ainsi qu'un « wrapper » maison : ntpdate-debian, qui ne fait qu'appeler ntpdate en tenant compte des informations définies dans le fichier /etc/default/ntpdate.

Ce « wrapper » sera appelé à chaque initialisation d'une interface réseau (script dans /etc/network/if-up.d).

Au final, avec un /etc/default/ntpdate de cette forme :

# The settings in this file are used by the program ntpdate-debian, but not
# by the upstream program ntpdate.

# Set to "yes" to take the server list from /etc/ntp.conf, from package ntp,
# so you only have to keep it in one place.
NTPDATE_USE_NTP_CONF=no

# List of NTP servers to use  (Separate multiple servers with spaces.)
# Not used if NTPDATE_USE_NTP_CONF is yes.
NTPSERVERS="<serveur1> [<serveur2>]"

# Additional options to pass to ntpdate
NTPOPTIONS=""

5-2-1. Où ça se complique▲

Les deux ne font pas bon ménage et il est bon de préciser quelques points qui peuvent poser des problèmes sur les serveurs :

• ntpdate ne fonctionnera pas si le service ntpd est actif ;
• ntpd refusera de synchroniser une horloge dont la dérive est supérieure à 1000 secondes, estimant que dans ce cas, l'intervention d'un administrateur est indispensable.

Autrement dit, dans le cas d'un serveur qui a été arrêté et qui, lors de son redémarrage, présenterait une dérive importante de son horloge, ne se mettra pas à l'heure avec le seul service ntpd. Il est donc bienvenu d'exécuter ntpdate avant d'avoir démarré le service ntpd ou à défaut, après avoir momentanément arrêté ce service.

Le service ntpd dispose tout de même d'une option qui permet d'outrepasser la règle des 1000 secondes (ntpd -g). Voici ce que dit le man à ce propos :

-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options.

Pour ceux qui n'aiment pas ntpdate, l'option -q permet à ntpd fonctionner d'une manière similaire. Le man dit :

-q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option.

Ainsi, ntpd invoqué avec les options -g et -q devrait permettre de se passer de ntpdate sur les stations de travail. Je n'ai pas testé ce mode de fonctionnement.

Sur une distribution de type Debian, les options d'appel de ntpd sont configurées dans le fichier /etc/default/ntp.