Mise en place d'un serveur de référence
Nous allons utiliser le paquetage ntp, mais avant, il est bon de savoir où trouver des serveurs de temps qui nous serviront de référence.
Debian propose de tels serveurs :
$ host 0.debian.pool.ntp.org
0.debian.pool.ntp.org A 87.106.98.153
0.debian.pool.ntp.org A 213.186.41.134
0.debian.pool.ntp.org A 81.93.183.116
$ host 1.debian.pool.ntp.org
1.debian.pool.ntp.org A 91.121.48.21
1.debian.pool.ntp.org A 195.5.228.18
1.debian.pool.ntp.org A 88.191.11.98
$ host 2.debian.pool.ntp.org
2.debian.pool.ntp.org A 91.121.149.114
2.debian.pool.ntp.org A 91.121.201.31
2.debian.pool.ntp.org A 91.194.60.128
$ host 3.debian.pool.ntp.org
3.debian.pool.ntp.org A 212.85.158.10
3.debian.pool.ntp.org A 88.191.12.184
3.debian.pool.ntp.org A 194.57.169.1
Ubuntu en propose un également :
$ host ntp.ubuntu.com
ntp.ubuntu.com A 91.189.94.4
Il faut s'intéresser au FQDN plutôt qu'aux adresses IP qui sont susceptibles de changer dans le temps.
Il en existe beaucoup d'autres. Il est certainement intéressant de visiter le NTP POOL PROJECT. Nous y apprendrons que pour la France, nous pouvons disposer de :
$ host 0.fr.pool.ntp.org
0.fr.pool.ntp.org A 91.121.104.170
0.fr.pool.ntp.org A 193.55.167.1
0.fr.pool.ntp.org A 193.55.167.2
$ host 1.fr.pool.ntp.org
1.fr.pool.ntp.org A 88.191.223.200
1.fr.pool.ntp.org A 94.23.220.143
1.fr.pool.ntp.org A 87.98.188.218
$ host 2.fr.pool.ntp.org
2.fr.pool.ntp.org A 91.121.45.45
2.fr.pool.ntp.org A 91.121.154.174
2.fr.pool.ntp.org A 94.23.33.75
$ host 3.fr.pool.ntp.org
3.fr.pool.ntp.org A 188.165.36.97
3.fr.pool.ntp.org A 81.93.183.116
3.fr.pool.ntp.org A 95.130.9.63
Il en existe d'autres en France, que l'on peut retrouver sur le Comité Réseau des Universités. Ils ne sont généralement pas destinés au « end-user ».
Installation
Sachant tout ceci, lançons nous.
aptitude install ntp
Le service ntpd s'installe et démarre.
Configuration
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 4 il va y en avoir pour 8, nous allons ajouter les serveurs du pool français, ce qui donnera au final :
...
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 toutes façons 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ù.
Observation avec « ntpq »
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 :
# service 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 8 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, l' - 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.
Observation avec « ntpdc »
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).