Le réseau / protocole NTP.

Laurent Archambault

<archi.laurent AT gmail.com>

Copyright © 2007 Copyright (c) Laurent Archambault. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Historique des versions

Version 1.0

10 fév 2007


Table des matières

Protection
1. Le réseau et serveur NTP.
1. Un peu d'histoire.
2. Network Time Protocole(NTP).
2.1. Protection.
3. Architecture.
4. Installation depuis une distribution.
5. Installation depuis les sources.
5.1. Les dépendances.
6. Les programmes complémentaires à NTP.
6.1. Les programmes pour ajuster les horloges internes.
7. Les divers programmes NTP.
7.1. ntpd
7.2. tickadj
7.3. sntp
7.4. ntpdate
7.5. ntptrace
7.6. ntptime
7.7. ntpq
7.8. ntpdc
7.9. ntp-wait
8. ntp-keygen
8.1. Quelques informations.
8.2. Activation du mode « autokey ».
9. Authentification via « autokey + IFF »
9.1. Coté serveur.
9.2. Coté client.
9.3. Contrôle de l'authentification.
9.4. Renouvellement des clés.
9.5. Le fichier « leap-second »
9.6. Remarques et contrôles sur « autokey »
10. /etc/init.d/ntpd
11. /etc/init.d/ntp-client
12. Configuration de votre réseau NTP
12.1. Les modes d'associations serveurs/clients.
12.2. Les modes opératoires.
12.3. Les relations spécifiques entres serveurs.
12.4. Schéma NTP
13. Configuration de serveurs (ntp.conf).
14. Configurer le fichier « ntp.conf »
14.1. Déclaration de serveurs classiques (strate N+1).
14.2. Déclaration de votre serveur en strate 1.
14.3. Les restrictions.
14.4. broadcast delay seconds
14.5. driftfile driftfile
14.6. enable | disable [auth | bclient | calibrate | kernel | monitor | ntp | stats]
14.7. Paramètres pour les traces/l'historique.
14.8. Les fichiers de traces.
15. Les fichiers de traces.
15.1. Les traces dans /var/log/messages
15.2. Le fichier /var/log/ntpd.log
16. NTP et les pare-feux
17. Mémo de commandes utiles ou fréquentes.
18. Conclusion.
Glossaire
A. Informations disponibles sur Internet.
B. Exemple de configuration d'un serveur strate 3 sur internet :
C. Exemple de configuration pour un client (serveur) strate 4 et internet :

Liste des tableaux

1.1. Explications des options pour ntpdate.
1.2. Explications des options.
1.3. Explications des codes de marquage.
1.4. Explications des symboles pour les relations.
1.5. Explications des symboles pour les relations.
1.6. Explications des méthodes d'authentifications.
1.7. Explications des options.
1.8. Explications des options.
1.9. Explications des valeurs.

Protection

Ce document peut être librement copié, distribué et/ou modifié selon les termes et conditions de la GNU Free Documentation Licence, version 1.1 ou ultérieure, la dernière version est disponible ici : www.gnu.org/licences/fdl.html

Important

Cette documentation ne prend en compte que l'installation et la configuration du protocole NTP pour des machines Gnu/Linux. Beaucoup d'autres systèmes d'exploitation possèdent une adaptation de NTP, qui reste très similaire.

Chapitre 1. Le réseau et serveur NTP.

Table des matières

1. Un peu d'histoire.
2. Network Time Protocole(NTP).
2.1. Protection.
3. Architecture.
4. Installation depuis une distribution.
5. Installation depuis les sources.
5.1. Les dépendances.
6. Les programmes complémentaires à NTP.
6.1. Les programmes pour ajuster les horloges internes.
7. Les divers programmes NTP.
7.1. ntpd
7.2. tickadj
7.3. sntp
7.4. ntpdate
7.5. ntptrace
7.6. ntptime
7.7. ntpq
7.8. ntpdc
7.9. ntp-wait
8. ntp-keygen
8.1. Quelques informations.
8.2. Activation du mode « autokey ».
9. Authentification via « autokey + IFF »
9.1. Coté serveur.
9.2. Coté client.
9.3. Contrôle de l'authentification.
9.4. Renouvellement des clés.
9.5. Le fichier « leap-second »
9.6. Remarques et contrôles sur « autokey »
10. /etc/init.d/ntpd
11. /etc/init.d/ntp-client
12. Configuration de votre réseau NTP
12.1. Les modes d'associations serveurs/clients.
12.2. Les modes opératoires.
12.3. Les relations spécifiques entres serveurs.
12.4. Schéma NTP
13. Configuration de serveurs (ntp.conf).
14. Configurer le fichier « ntp.conf »
14.1. Déclaration de serveurs classiques (strate N+1).
14.2. Déclaration de votre serveur en strate 1.
14.3. Les restrictions.
14.4. broadcast delay seconds
14.5. driftfile driftfile
14.6. enable | disable [auth | bclient | calibrate | kernel | monitor | ntp | stats]
14.7. Paramètres pour les traces/l'historique.
14.8. Les fichiers de traces.
15. Les fichiers de traces.
15.1. Les traces dans /var/log/messages
15.2. Le fichier /var/log/ntpd.log
16. NTP et les pare-feux
17. Mémo de commandes utiles ou fréquentes.
18. Conclusion.

1. Un peu d'histoire.

Malgré la présence d'une horloge basée sur un quartz dans chaque machine, il n'en reste pas moins qu'elles ne sont pas fiables. Certaines transactions informatiques nécessitent une grande précision horaire. La nécessité de pouvoir synchroniser des machines sur une plage horaire fiable était donc nécessaire. C'est le début du TP (Protocole horaire) en 1983.

En 1985, le professeur « David L. Mills » lance le protocole NTP supérieur en qualité à TP. C'est également la mort du protocole TP, qui faute de grande précision est toujours obsolète de nos jours. Désormais seul le protocole NTP est utilise et procure une très grande précision. Son protocole se base sur la référence du temps UTC. En 1988, la version 1.0 ou stable de NTP est née. En 1989, Digital Équipement Corporation présente le DTSS (Digital Time Synchronisation Service). Suite à divers reproches concernant les 2 protocoles, la communauté NTP utilise désormais l'algorithme de Marzullo crée par DTSS, c'est la version 3.0 de NTP. Depuis 1994, la version du protocole NTP est la version 4.0; son développement continu.

La version 4.0 de NTP apporte une précision de l'ordre de la micro seconde pour un réseau rapide. Il faut également parler du protocole SNTP (S pour simple). C'est une dérive du protocole NTP, avec une précision de la seconde uniquement. Le protocole NTP étant universel, il ne prend pas en compte les décalages horaires, et les passages en heures d'hiver et d'été. Ceci est fait par la machine elle-même. Ce protocole intervient sur les fréquences de l'horloge, afin qu'elle puisse restituer de bonnes données horaires (adjtimex...). Ces modifications sont réalisées par augmentation d'une fréquence interne. Le temps est soit exacte, soit en avance, mais jamais en retard ce qui permet au logiciel de calcul de restituer des valeurs acceptables ou correctes...

Je ne vais pas expliquer les diverses trames possibles ni l'algorithme en détail, c'est pourtant très intéressant, mais cela nécessiterait également un ajout de plusieurs pages à ce même document. Vous avez dans le glossaire de ce document le lien du site NTP, pour trouver ces informations.

2. Network Time Protocole(NTP).

Le protocole NTP utilise le protocole UDP sur le port 123. Il est défini dans la RFC-1305, pour de plus amples renseignements. L'algorithme prend en compte beaucoup de paramètres et de variables. J'ai volontairement extrait 3 paramètres importants utilisés par NTP pour une meilleure compréhension de ce protocole :

  1. le décalage de temps entre l'horloge interne et le temps de référence (clock Offset),

  2. le temps de transmission des signaux aller/retour (roundtrip),

  3. le nombre d'erreurs relatives de l'horloge interne de l'ordinateur avec l'horloge de référence (Dispersion).

2.1. Protection.

Ce protocole est protégé par une licence très similaire à la GPL. Elle n'est pas contraignante, mais protège le travail effectué par de nombreuses personnes.

De plus amples informations sont disponibles sur cette page : http://www.eecis.udel.edu/~mills/ntp/html/copyright.html

3. Architecture.

A l'exception de besoins spécifiques comme les transaction boursières, les contrôles aériens et autres, qui nécessitent une référence de temps très proche pour réduire les latences. Dans toutes les autres situations, comme pour la mise à jour horaire d'un réseau classique composé de serveurs et de stations, une architecture NTP est impérative. Cette architecture est hiérarchisée, il existe 16 niveaux ou couches possibles (strates).

Ce terme de « strate » va être utilisé très couramment dans ce document : il est synonyme de niveaux ou couches. Ces niveaux permettent également une bonne répartition des flux sur le réseau. Le déploiement de serveurs (NTP) est exponentiel, il varie en fonction de la demande. Vous devez donc adapter les niveaux de strate en fonction du nombre de clients, tout en prenant en compte la répartition géographique.

En se basant sur sa référence, la « strate » d'un serveur est forcément égale à la formule : « strate N+1 ».

Il est possible dans un réseau de prendre des références multiples, mais aussi des références aux niveaux N+0, N-1, N-2... Ceci peut rester valable pour un serveur mais pas pour un client classique. A vous de donner les restrictions nécessaires, à vous également de communiquer votre adresse de messagerie pour autoriser ou non les futurs clients/serveurs.

Comme vous pouvez le lire, les solutions ne manquent pas, pour adapter votre réseau ou les clients à un réseau NTP. Il est important de prendre en compte qu'un serveur classique mérite les mêmes soins qu'un client ordinaire. C'est une chaîne ou chaque maillon à son importance. Le protocole NTP est suffisamment précis pour remplir cette fonction dans les strate 4,5 et même 6. Il ne faut pas confondre strates et niveaux de précision. Les relations entre les strates de même niveau peuvent être unidirectionnelles, ou bidirectionnelles.

Une bonne architecture NTP doit apporter :

4. Installation depuis une distribution.

Pour une Mandriva™2007, il suffit de faire urpmi ntp, et elle résout toutes les dépendances. La taille totale des fichiers installés est de 3 Mo.

Pour satisfaire les dépendances, les paquetages suivants vont être installés:
 ntp-4.2.0-31.2mdv2007.0.i586
 ntp-client-4.2.0-31.2mdv2007.0.i586
 Procéder a l'installation des 2 paquetage? (3 Mo) (O/n)
 ftp://ftp.free.fr/mirrors/ftp.mandriva.com/MandrivaLinux/official/current/i586/media/main/updates/ntp-client-4.2.0-31.2mdv2007.0.i586.rpm
 ftp://ftp.free.fr/mirrors/ftp.mandriva.com/MandrivaLinux/official/current/i586/media/main/updates/ntp-4.2.0-31.2mdv2007.0.i586.rpm
 installation de ntp-client-4.2.0-31.2mdv2007.0.i586.rpm ntp-4.2.0-31.2mdv2007.0.i586.rpm depuis /var/cache/urpmi/rpms
 Préparation ...                 ##########################################################
      1/2: ntp-client            ##########################################################
      2/2: ntp                   ##########################################################

Rien de spécial pour l'installation, c'est fiable et rapide, par contre vous n'avez pas l'option debug incluse.

5. Installation depuis les sources.

Le site d'origine pour NTP, dispose des dernières versions stables et en développement, vous pouvez télécharger les sources via ce lien : www.ntp.org.

En se basant sur une distribution Gentoo™, donc basé sur la compilation, voici comment faire.

5.1. Les dépendances.

Les librairies et logiciels ci-dessous doivent être installés avant de procéder à la compilation des sources NTP. Ces étapes sont faites automatiquement, cette liste est fournie pour information. A signaler également un développement similaire, « OpenNtp » mais est réservé au système d'exploitation OpenBSD™ en particulier.

Le logiciel « OpenSSL » et ses librairies sont obligatoires si l'option with-crypto est activée. « SElinux> » est utilisé si votre Gentoo utilise un noyau « SEcure Linux ».

 sys-libs/ncurses-5.2
 sys-libs/readline-4.1
 kernel_linux? ( caps? ( sys-libs/libcap ) )
 openntpd ( net-misc/openntpd )
 ssl ( dev-libs/openssl )
 selinux ( sec-policy/selinux-ntp )

Voici les paramètres nécessaires pour une bonne compilation, l'option debug est fortement recommandée. Pour l'intégration de pilotes d'horloges pour la compilation, référez vous à la section strate1 pour plus de détails.

 ./configure --prefix=/usr \
  --host=i686-pc-linux-gnu \
  --mandir=/usr/share/man \
  --infodir=/usr/share/info \
  --datadir=/usr/share \
  --sysconfdir=/etc/ntp \
  --localstatedir=/var/lib \
  --disable-linuxcaps \   
  --disable-parse-clocks \     # pour les strate 1+DCF77 : enable-parse-clocks et --enable-all-clocks
  --disable-ipv6 \
  --enable-debugging \
  --with-crypto \
  --build=i686-pc-linux-gnu

Au final c'est beaucoup de fichiers; la liste suivante ne comporte que les fichiers exécutables. Chaque programme sera expliqué indépendamment par la suite.

 /usr/sbin/ntpd
 /usr/sbin/ntpdate
 /bin/tickadj
 /usr/bin/sntp
 /usr/bin/ntptrace
 /usr/bin/ntptime
 /usr/bin/ntpq
 /usr/bin/ntpdc
 /usr/bin/ntp-wait
 /usr/bin/ntp-keygen
 /etc/init.d/ntpd
 /etc/init.d/ntp-client

6. Les programmes complémentaires à NTP.

Compte tenu du nombre et des spécifications par plate-forme, ce chapitre ne traite que des options et de l'exploitation de programmes les plus connus sous Gnu/Linux.

6.1. Les programmes pour ajuster les horloges internes.

Un PC est composé de 2 horloges, l'une est toujours en fonctionnement (CMOS), même l'ordinateur hors tension, et l'autre est l'horloge système. Toutes ces horloges tentent de garder une référence horaire la plus précise possible. Pour information l'horloge CMOS dérive plus ou moins dans une journée, et est moins précise que l'horloge système. Les programmes ci-dessous permettent de corriger ceci, en complément de NTP.

6.1.1. Le programme « adjtimex » (version 1.16-r11).

Ce programme est valable uniquement pour Gnu/Linux; il utilise l'algorithme d'ajustement d'horloge de David L. Mills (fondateur de NTP) . Ce programme utilise le noyau Gnu/Linux pour régler avec finesse l'horloge, et donc du système. J'insiste sur les mots « horloge système ». Elle ne modifie nullement les données de l'horloge CMOS, contrairement au programme suivant hwclock. Pour Gnu/Linux, l'horloge système est gérée intégralement par le noyau, lequel permet des ajustements.

Dans toutes les situations, il est préférable d'activer le protocole NTP sur une machine pour remplacer les programmes qui suivent. Ceci reste valable uniquement si le réseau NTP est fiable et dispose de plusieurs références, et également si votre liaison ethernet/internet... est également fiable. Pour les autres situations, installez adjtimex et éventuellement hwclock.

Toutefois pour de très fortes dérives, effectivement adjtimex peut être utilisé. Cette action évite de questionner le serveur NTP très régulièrement pour maintenir l'heure, avec un programme comme ntpd -q ou ntpdate. Ceci uniquement si aucun serveur NTP est présent sur la machine incriminée...

Voici les paramètres pour le compiler :

 /configure --prefix=/usr \
 --host=i686-pc-linux-gnu \
 --mandir=/usr/share/man \
 --infodir=/usr/share/info \
 --datadir=/usr/share \
 --sysconfdir=/etc/ntp \
 --localstatedir=/var/lib \
 --build=i686-pc-linux-gnu

Ceci installe les fichiers suivants :

 /usr/sbin/adjtimexconfig
 /usr/sbin/adjtimex
 /etc/init.d/adjtimex
6.1.1.1. Les paramètres de lectures.

Ces paramètres sont accessibles pour un utilisateur autre que « root », cette information provient de la documentation officielle. Pour une Gentoo™, le programme est présent dans le répertoire : « /usr/sbin/ », ce qui exclut l'accès à ce programme par des utilisateurs autres que « root ».

6.1.1.1.1. adjtimex -print
                                            --- current ---    -- suggested --
 cmos time     system-cmos       2nd diff    tick      freq     tick      freq
 1173423889      420.359768     420.359768    9999    485440
 1173423899      420.365956       0.006187    9999    485440
 1173423909      420.372163       0.006207    9999    485440     9993   -872598
 1173423919      420.378369       0.006206    9999    485440     9993   -866347
 1173423929      420.384574       0.006205    9999    485440     9993   -858535
 1173423939      420.390781       0.006207    9999    485440     9993   -872597
 1173423949      420.396988       0.006206    9999    485440     9993   -866347
 1173423959      420.409198       0.012210    9999    485440     9987   -891622

Sans aide, les données fournies par le programme ne sont pas très compréhensibles.

Les valeurs « maxerror » (Nr erreurs) et « raw time » (heure au format RAW) ne font qu'augmenter.

La valeur « tick » est intéressante; elle représente le nombre de micro secondes additionnées par le noyau vis à vis des battements d'horloge. Cette valeur doit être comprise en 9000 et 11000. La valeur par défaut est à 10000. L'augmentation de ce chiffre par 1 représente 100 pulsations par seconde en plus, ou l'équivalent de 8,64 secondes par jour supplémentaire.

Autre valeur intéressante, le paramètre frequency représente la fréquence de l'horloge du noyau (système). Elle peut être négative ou positive, mais comprise entre les valeurs -6553600 et 6553600. Un facteur de 65536 représente 1 micro seconde par jour, ou 0,0864 seconde par jour.

Il est possible de combiner tick et frequency pour ajuster les décalages horaires. A titre d'exemple, les paramètres --tick 10000 --frequency 6553600 sont identiques à --tick 10001 --frequency 0, et représentent un ajout de 8,64 secondes par jour.

Pour une plus grande précision d'ajustement, vous pouvez appliquer cette formule selon l'exemple suivant : Pour une correction positive de 8 secondes, il suffit de faire soustraire ce décalage à 8.64 soit 0.64. Ceci donne la formule suivante : (1 << 16)*0.64 * 0.0864 = 485452. Dont les « << » me posent un problème mathématique...Mais cette formule fait partie de la documentation officielle. Voici le résultats à obtenir : adjtimex --tick 9999 --freq 485452.

En utilisant la commande adjtimex --compare, adjtimex passe en mode comparaison entre les 2 horloges, et vous propose des valeurs de corrections, ce qui est tout de même pratique.

6.1.1.2. Le script « adjtimexconfig ».

L'ajustement de l'horloge système comme vous avez pu le constater n'est pas très facile manuellement. C'est pourquoi à mon avis le programme adjtimexconfig existe, pour nous simplifier ce travail. Son fonctionnement est très simple, il suffit de le lancer en tant que « root » et d'attendre. Voici un résultat en exemple :

 adjtimexconfig 
 Comparing clocks (this will take 70 sec)... adjusting system time by  -63.0318  sec/day
 Done

Nous retrouvons ici la nécessité d'être super administrateur pour lancer cette commande, car le programme affiche « fait (done) ». Ce qu'il a fait est relativement simple, il a modifié les paramètres de gestion de l'horloge du noyau afin de corriger dans mon cas, les 63,0318 secondes par jour de retard. Les paramètres de modifications opèrent de manière douce; le changement semble minime lors d'une relance de ce programme. Les effets seront plus perceptibles à long terme.

Les valeurs modifiées pour corriger les moins 63 secondes sont TICK=9993 et FREQ=-663757. Ce script utilise la commande adjtimex --adjust qui est identique à l'option --compare à l'exception près qu'elle envoie au noyau Linux les valeurs TICK et FREQ, en ne gardant que les dernières valeurs.

6.1.2. Le programme « hwclock ».

Comme expliqué précédemment, ce programme est chargé de régler/modifier l'horloge CMOS, afin de procurer une bonne stabilité ou exactitude horaire. Ceci reste valable en particulier lors d'arrêt fréquent du PC, donc applicable pour une station de travail. En prenant en compte, que cette même station peut se mettre à jour via la protocole NTP dès son arrivée sur un réseau, je ne vois pas trop la nécessite d'utiliser ce programme. Il est par ailleurs non installé par défaut dans les distributions Gnu/Linux, prouvant peut-être son emploi plus ou moins obsolète, en particulier pour les serveurs.

A toute fin utile, vous trouverez des informations détaillées pour sa configuration ici : http://www.linux-france.org/article/sys/heure/index.html.

Pour information, le calibrage de l'horloge CMOS nécessite des tests sur une semaine à intervalles réguliers...

7. Les divers programmes NTP.

7.1. ntpd

Ce programme est le plus important pour un réseau NTP, c'est aussi le programme résidant pour la diffusion du protocole NTP. Il met et maintien le système à l'heure synchronisé avec les serveurs de temps. Le protocole utilisé est NTP en version 4, mais il reste compatible avec les versions antérieures, en mode dégradé tout de même.

ntpd au démarrage demande plusieurs échanges ou connexions entres serveurs pour se mettre à jour. C'est une manière de se protéger d'un éventuel serveur non synchronisé. Au lancement, si l'horloge CMOS possède plus de 1000 secondes de décalage par rapport à ntpd, celui ci refusera de la mettre à jour. C'est une protection du protocole, qui peut être forcée par l'option -g, ou plus simplement par la mise à jour de l'horloge CMOS.

Dans des conditions classiques, ntpd maintient l'horloge système à jour progressivement et continuellement. Le décalage est inférieur à 128 ms théoriquement. Lors de congestion au niveau réseau, cette valeur peut être atteinte ou dépassée par ntpd. Il est possible d'utiliser l'option -x pour corriger ce problème. Toutefois cette valeur intervient directement sur l'algorithme; elle doit être utilisée avec précaution.

Voici les différentes options pour son lancement :

ntpd - NTP daemon program - Ver. 4.2.4
USAGE:  ntpd [ -<flag> [<val>] | -- <name>[{=| }<val>] ]...
Flg Arg Option-Name    Description
-4 no  ipv4           Résolution DNS au format IPv4.
-6 no  ipv6           Résolution DNS au format IPv6.
-a no  authreq        Nécessite une authentification cryptée pour les broadcast/multicast
                      et le mode PEER.
                      - Interdit cette option: authnoreq (-A).
-A no  authnoreq      L'inverse de l'option -a.
                      - Interdit cette option: authreq (-a).
-b no  bcastsync      Permet une synchronisation par broadcast pour les clients.
-c Str configfile     Fichier de configuration, défaut est "/etc/ntp.conf".
-d                    Mode debug (à utiliser comme -d -D1 ou 2 ...).
-D level              Spécifie le niveau de debuggage.
-f Str driftfile      Fichier de dérive horaire (/etc/ntp.drift).
-g no  panicgate      Permettre une mise à jour si le décalage est au moins égal
                      à 1000 secondes.
-i Str jaildir        Répertoire d'emprisonnement (chroot) (Jail directory).
-I Str interface      Écoute sur l'interface réseau.
                      - Peut apparaître plusieurs fois.
-k Str keyfile        Chemin des clés symétriques (/etc/ntp.keys). 
-l Str logfile        Chemin du fichier de log.
-L no  novirtualips   Ne pas écouter les IP virtuels.
-n no  nofork         Ne "chroot" pas.
-N no  nice           Tourne en mode prioritaire (nice X: -20(prioritaire) à 19 (lent)).
-p Str pidfile        Chemin du fichier PID.
-P Num priority       Priorité du processus.
-q no  quit           Procède à la mise à jour et quitte.
-r Str propadelay     Broadcast/delais de diffusion.
-U Num updtinterval   Intervalle en secondes entre des scans ou des sauts d'interfaces
                      pour récupérer des données.
-s Str statsdir       Fichier de statistiques.
-t Str trustedkey     Numéro de clés de confiance - peut apparaître plusieurs fois.
-u Str user           Lancer avec le "userid" ou "userid:groupid".
-v Str var            Utilise des variables en lecture/écriture comme argument (ARG).
                      - Peut apparaître plusieurs fois.
-V Str dvar           Utilise les variables en lecture/écriture comme 
                      définitions (RW|DEF).
                      - peut apparaître plusieurs fois.
-x no  slew           Dévie de moins de 600 secondes.
-v opt version        Affiche la version et quitte.
-? no  help           Affiche l'aide et quitte.
-! no  more-help      Affiche les informations détaillées.
-> opt save-opts      Sauve les options dans un fichier de configuration.
-< Str load-opts      Charge les options du fichier de configuration.
                     - desactive par --no-load-opts.
                     - peut apparaître plusieurs fois.

En utilisant la commande ntpd -d -D1, il est possible de faire passer ntpd en mode debug. Dans cette situation ntpd renvoie à l'écran énormément d'informations : les erreurs du fichier ntp.conf sont indiquées tout au début. C'est l'une des seules solutions pour connaître la présence d'erreurs à l'intérieur du fichier de configuration (ntp.conf).

ntpd peut être utilisé en mode client, ou de façon similaire à ntpdate. Il suffit pour cela de le lancer via cette commande :

ntpd -q

7.2. tickadj

Ce programme lit la fameuse valeur tick dans le noyau et renvoie cette valeur à l'écran. Il permet aussi pour les anciens noyaux qui ne gèrent pas l'horloge comme actuellement, de passer des valeurs de modifications. Ce programme n'est plus utilisé sur Gnu/Linux, utilisé par Solaris, HP-UX... Vous pouvez trouver de plus amples informations sur : http://sunsite.ualberta.ca/Documentation/Misc/ntp-4.0.99a/tickadj.htm/

7.3. sntp

Ce programme utilise le protocole Simple Network Time Protocol qui est une version réduite du protocole NTP. Celui ci est de loin le moins précis et le moins utilisé. Bien que Microsoft l'utilise, y compris dans Active Directory... Il n'est pas compatible avec NTP, et même interdit d'emploi sur ce même réseau.

7.4. ntpdate

Ce programme est le client ou l'équivalent de la commande ntpd -q (met à jour puis quitte). Ce programme ne fonctionne pas si ntpd est lancé sur la même machine. Son emploi est réservé aux clients pour la mise à jour de leurs horloges.

ntpdate n'égale pas ntpd car celui est actif en permanence. ntpdate doit être lancé périodiquement pour maintenir le décalage horaire à une valeur acceptable, d'où une dérive plus grande possible. La précision horaire devrait rester inférieure à 1 seconde, suffisante pour une station de travail.

Lors d'une demande de mise à jour par ntpdate, si celui-ci rencontre un décalage supérieur à 0,5 seconde, il modifie ce décalage par appel de la fonction dans le noyau settimeofday(). Pour un décalage inférieur à 0,5 seconde, c'est la routine adjtime() qui est appelée.

Tableau 1.1. Explications des options pour ntpdate.

Option

Explication

-4

Fait les résolutions DNS en IPV4 (par défaut).

-6

Fait la résolution DNS en IPV6.

-a nr

Bien que déconseillé à ce niveau, active l'authentification et utilise la clé spécifique (ex : key 1).

-B

Force l'utilisation de la routine adjtime() si le décalage est supérieur à (+-) 128 ms. Si le décalage est supérieur à (+-) 128 ms, la mise à jour peut être très longue (heure).

-b

Force la mise à jour par la routine settimeofday(). Cette routine est plus rapide, et donc cette option peut ou doit être utilisée au démarrage de la station...

-d

Passe en mode debug, pour résolution de problème (si compilé avec cette option).

-e authdelay

Spécifie une valeur en seconde pour la période d'authentification.

-k keyfile

Pour les clés, ntpdate utilise par défaut la valeur /etc/ntp.keys, cette variable permet de choisir un autre fichier et son répertoire.

-o version

Affiche la version.

-p samples

Spécifie le nombre d'échantillons à recevoir par serveur. Cette valeur doit être comprise en 1 et 8, la valeur par défaut est 4.

-q Interroge

Interroge sans faire de mise à jour.

-t timeout

Permet de régler le timeout des connexions, par défaut cette valeur est à 1, elle doit être un multiple de 0,2 seconde.

-u

Permet d'utiliser des ports non privilégiés (<1023) en UDP, à utiliser lors de problème avec des pare-feux. Par défaut l'option -d utilise des ports non privilégiés.

-v

Affiche la version du logiciel.



7.5. ntptrace

Cette commande permet en quelque sorte de remonter un réseau; c'est un script en Perl. C'est une commande intéressante, mais dont les données qui lui sont nécessaires dépendent de la configuration des autres serveurs.

7.6. ntptime

Ce programme utilise la routine ntp_gettime() du noyau pour lire et afficher les variables utilisées par le noyau. La commande ntpdc kerninfo produit les mêmes résultats.

C'est un excellent programme pour connaître si votre serveur fonctionne bien, il suffit de le lancer. La ligne suivante apparaît lors de la phase d'initialisation du serveur (strate 16) :

 ntp_gettime() returns code 5 (ERROR)

Attention tout de même ntpd dès son lancement nécessite environ 4 minutes pour se stabiliser/calibrer. Il suffit d'attendre pour lire ceci :

 ntp_gettime() returns code 0 (OK)

Tableau 1.2. Explications des options.

Option

Explication

-c

Affiche le temps d'exécution pour l'appel à la routine.

-e est_error

Estimation des erreurs (us).

-f frequency

Affiche la fréquence.

-h

Affiche l'aide.

-m max_error

Affiche le maximum des erreurs (us).

-o offset

Affiche la valeur courante « offset ».

-r

Affiche le temps unix et NTP au format RAW.

-s status

Pour affecter un bit de status ...

-t time_constant

log2 of PLL time constant (0...6).



7.7. ntpq

Ce programme est chargé de contrôler ntpq et de déterminer les performances. J'insiste sur le mot contrôler, et non questionner, ce qui est différent et fait aussi l'objet d'un autre programme (ntpdc). C'est donc un outil fort utile, loin d'être convivial, qui ne fonctionne qu'en mode interactif, ou en ligne de commandes. Il n'est pas nécessaire d'être « root » pour l'utiliser. Au travers de ces diverses commandes, il peut interroger des serveurs distants. Il est nécessaire dans ce cas que celui-ci soit paramétré pour cela, sans restriction à ce niveau. Il utilise pour information le mode 6 de transmissions de paquets pour NTP.

7.7.1. Les différentes commandes.

Il est possible de lancer des commandes en mode interactif ou en ligne de commande. Voici les commandes en mode interactif, elles sont plus nombreuses :

ntpq commands:
 addvars        debug          lopeers        passociations  rl
 associations   delay          lpassociations passwd         rmvars
 authenticate   exit           lpeers         peers          rv
 cl             help           mreadlist      poll           showvars
 clearvars      host           mreadvar       pstatus        timeout
 clocklist      hostnames      mrl            quit           version
 clockvar       keyid          mrv            raw            writelist
 cooked         keytype        ntpversion     readlist       writevar
 cv             lassociations  opeers         readvar

7.7.2. Voici le détail des commandes dites « internes ».

7.7.3. Les demandes dites de « contrôles ».

7.7.4. Les codes de marquage.

Tableau 1.3. Explications des codes de marquage.

Symbole

Équivalence

Explication

(espace)

reject

Le serveur est non joignable, synchronisation impossible.

x

falsetick

Le serveur est non fiable, sa fréquence est mauvaise.

.

excess

Non pris en compte pour la synchronisation, ne fait pas partie des 6 premiers choisis, et des plus rapides à répondre.

-

outlyer

Non pris en compte, problème d'algorithme.

+

candidat

Pris en compte, et combine les algorithmes.

#

selected

Non pris en compte parmi les 6 premiers choisis et les plus rapides. C'est souvent une situation temporaire.

*

sys.peers

C'est l'association idéale, participe à la synchronisation, et également aux transmissions de variables (ntpq).

0

pps.pper

Comme pour « * » mais ces PPS (pulse per second) sont mauvaises.



Il faut retenir les signes + et * qui symbolisent des serveurs disponibles et stables.

7.7.5. Les commandes utiles pour « ntpq ».

J'avoue volontiers ne pas avoir compris toutes les commandes que propose ntpq, amplifier par des mots anglais par forcément dédiés à l'informatique comme « cooked, fuzzbals... »

7.7.5.1. Le statut de votre serveur.

C'est la commande ntpq -p. Vous allez pouvoir constater l'inscription des différents serveurs, les associations, les temps de réponse. On retrouve ici toutes les valeurs nécessaires à un contrôle du bon fonctionnement du protocole NTP.

7.7.5.2. Récupération des strate supérieurs.

Lors d'une activation du protocole NTP, souvent vous récupérez soit une liste de serveurs, soit uniquement le nom d'un serveur NTP en provenance d'internet (ou autre réseau), et vous ne connaissez pas l'architecture. La commande ntpq -C peers host va vous lister les serveurs associés à ce même serveur , que vous avez choisi par la valeur host. Ceci parait anodin, mais il est tout de même intéressant de connaître, que vous êtes éventuellement connectés à un serveur associé uniquement à autre serveur, et non à plusieurs comme fortement conseillé.

 ntpq -c peers 130.149.17.8
      remote           refid      st t when poll reach   delay   offset  jitter
 ==============================================================================
  LOCAL(0)        LOCAL(0)        12 l   57   64  377    0.000    0.000   0.000
 +GENERIC(0)      .GPS.            0 l   44   64  377    0.000   -0.018   0.001
 oPPS(0)          .PPS.            0 l    5   64  377    0.000   -0.018   0.000
  130.149.31.255  0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00
 -ntp1.belwue.de  .DCFp.           1 u   40   64  377   22.913   -0.071   0.094
 +ptbtime2.ptb.de .PTB.            1 u    3   64  377    7.097   -0.056   0.225
 -ntps1-0.cs.tu-b .PPS.            1 u   59   64  377    0.723    0.036   0.042

Sans la valeur host, ntpq prend votre serveur comme cible. Dans la colonne refid les valeurs 0.0.0.0 signifie l'impossibilité de trouver cette information, en clair ce serveur n'est pas fiable ou rencontre un problème. Ceci est visible également par sa position de strate 16, qui veut dire non synchronisé.

7.8. ntpdc

Ce programme est comparable au programme précédent puisqu'il intervient sur le serveur NTP au niveau de ntpd. Les commandes sont bien sûres différentes : elles apportent même des ajouts de serveurs...etc. Ce programme se présente aussi comme une télécommande pour ntpd à l'exception qu'il n'écrit rien dans le fichier configuration. Toutes les modifications restent en mémoire; pour information, ce programme utilise le mode 7 du protocole NTP pour la transmission des paquets.

7.8.1. Les différentes commandes.

Il est possible de lancer des commandes en mode interactif ou en ligne de commandes. Voici les commandes en mode interactif, elles sont plus nombreuses :

ntpdc> help
 ntpdc commands:
 addpeer      controlkey   fudge        keytype      quit         timeout
 addrefclock  ctlstats     help         listpeers    readkeys     timerstats
 addserver    debug        host         loopinfo     requestkey   traps
 addtrap      delay        hostnames    memstats     reset        trustedkey
 authinfo     delrestrict  ifreload     monlist      reslist      unconfig
 broadcast    disable      ifstats      passwd       restrict     unrestrict
 clkbug       dmpeers      iostats      peers        showpeer     untrustedkey
 clockstat    enable       kerninfo     preset       sysinfo      version
 clrtrap      exit         keyid        pstats       sysstats

7.8.2. Voici le détail des commandes les plus importantes et dites « interactives ».

Dans la documentation officielle, les créateurs ont même écrit que ce programme pouvait renvoyer des données mortellement ennuyantes, et qui peuvent être occasionnellement utiles. Pour ces raisons, j'explique certaines commandes et non toutes.

Vous pouvez trouver plus d'informations sur le mot FQDN ici.

7.9. ntp-wait

Ce programme est écrit en Perl, contrairement aux autres. Il peut-être utilisé pour donner plus de temps à ntpd lors de son lancement initial, pour lui donner plus de temps à sa synchronisation. Hélas il profite de peu de description technique sur son emploi et ses commandes. Il est lié aux serveurs de strate 4.

8. ntp-keygen

Important

Le système d'authentification « Autokey version 2 » ne supporte pas la translation d'adresse IP.

Ce programme est spécialisé pour la création et la maintenance des clés pour un réseau NTP. Ce programme va participer activement au renforcement de la sécurité, au niveau des dialogues entre les serveurs. C'est donc un maillon important, que seul l'utilisateur root peut activer et modifier (mise à jour...).

8.1. Quelques informations.

Ce programme génère des données chiffrées utilisées par NTP version 4 pour l'authentification, et l'identification. Il peut générer des clés MD5 qui seront utilisées pour les clés symétriques. En complément, si la librairie OpenSSL est installée, il peut générer des clés, des certificats et des fichiers d'identités cryptés.

La limitation est de 65534 clés, ce qui laisse une marge de manoeuvre. Ces données serviront pour les signatures, pour identifiés les dialogues. Ces échanges sont compatibles avec les standards présents sur internet.

L'option -p password spécifie l'écriture d'un mot de passe.

L'option -q password permet de lire le précédent mot de passe chiffré dans un fichier.

Le format d'écriture des fichiers suit cette formule : ntpkey_ suivi d'identifiant de cryptage, puis suivi de _hostname.filestamp.

La valeur « filestamp » correspond au temps unix. Il est obligatoire de créer des liens vers ces fichiers, lors de la création de nouvelles clés, il suffira de modifier les liens.

Chaque configuration implique une signature et une schéma d'authentification appelé « cryptotype ». Par défaut le système utilisé est le cryptage par RSA, MD5 et TC pour l'identification.

Des notions de confiance doivent être établies. Il est important lors de la construction du réseau NTP, de penser à ceci : des groupes doivent être établis. Dans la mesure du possible, les serveurs des strates 1 et 2 doivent être déclarés dans des groupes de confiance. Il est possible d'activer depuis la version 4 de NTP le système de gestion des clés appelée autokey.

C'est la version 2 de « autokey » qui doit être utilisée de nos jours. Ce système permet une gestion des clés plus facile, allant de la distribution à la conservation. C'est cette solution que je vais privilégier dans ce document. En effet, elle est compatible X509, avec un PKI... C'est une solution moderne éprouvée et fiable.

Le drapeau auth dans le fichier de configuration contrôle toutes les associations, ou les contrôles à distance qui demandent une authentification. Il y 3 techniques ou schémas différents d'authentifications qui sont : IFF, MV et GC.

Tableau 1.6. Explications des méthodes d'authentifications.

Type

Détail

Explication

PC

Private Certificate

Le schéma PC implique l'utilisation de certificats privés comme groupe de clés. Un certificat est désigné par le protocole X509 V3 champs étendus. Ce certificat est distribué de façon sécurisé à tous les membres du groupe, il ne doit jamais être révélé

IFF

Identify Friendy or Foe.

Le schéma IFF désigne un schéma qui utilise des certificats qui peuvent être générés autrement que par ntp-keygen. Les certificats peuvent être générés par OpenSSL... L'autorité de certification TA génère les paramètres IFF et les clés, et les distribue de façon sécurisée. Cette autorité génère des paramètres de structure DSA pour être utilisés dans les paramètres IFF. Chaque client possède sa propre clé privé et certificat.

GC

Guillou-Quisquater algorithm.

Contrairement à IFF, le système est très proche mais les certificats ne sont générés que par ntp-keygen. Cette autorité génère des paramètres de structure RSA (et NON DSA pour IFF) pour être utilisés dans les paramètres IFF. Les paramètres de structure RSA sont générées par une routine de la librairie OpenSSL.

MV

Mu-Varadharajan algorithm.

Ce schéma doit être utilisé pour le cryptage des données transmises par broadcast. Il y a une clé d'encodage et plusieurs de décodage pour les clients. Cette autorité génère des paramètres de structure DSA



8.2. Activation du mode « autokey ».

8.2.1. Les options de commandes de ntp-keygen

Usage:  ntp-keygen [options]
ou les options sont :
-c [ RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 | RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ]
                  Permet de sélectionner l'algorithme pour encryptés les clés de signature.
                  Ne pas mélanger RSA et DSA par la suite (!). Par défaut choisir RSA-MD5
-d                Monte d'un niveau en DEBUG.
-e                Écrit les clés d'identités.
-G                Génère les paramètres GQ et les clés.
-g                Mets à jour les clés GQ.
-H                Génère les clés par machine (hostname) en RSA.
-I                Génère les paramètres IFF.
-i name           Sélectionne un nom comme identifiant
                  Il ne doit pas être lié à une interface/strate/nom de machine/DNS...
-M                Génère les clés MD5.
-m modulus        256 - 2048, défaut est 512.
-P                Génère les certificats privés (PC), par défaut ils sont publiques.
-p password       Crypte les fichiers générés avec le mot de passe.
-q password       Demande le mot de passe pour la lecture des fichiers.
-S [RSA|DSA]      Génère les clés de signature (RSA ou DSA)
-s set-subj-name  (non expliqué...)
-T                Reconnu comme certificat de confiance (TC), non généré par défaut.
-V #keys          Génère les paramètres Mu-Varadharajan (MV)
-v #keys          Mets à jour les paramètres Mu-Varadharajan (MV)

9. Authentification via « autokey + IFF »

Si vous souhaitez vous investir techniquement beaucoup plus dans « autokey », vous pouvez vous référer à ce document en ligne qui devrait répondre à toutes vos questions : stime-0001.pdf

Pour la création des clés complètes, vous avez au moins 2 possibilités : l'une manuelle comme expliquée ci après, l'autre utilise plusieurs scripts pour vous aider. Cet ensemble de scripts est téléchargeable à cette adresse ak_tool.tgz

Voici à toutes fins utiles, le lien pour les questions/réponses relatives à autokey : http://ntp.isc.org/bin/view/Support/ConfiguringAutokey

En prenant comme exemple 2 serveurs NTP distants, l'un s'appelle serveur, et l'autre fw.

Les explications qui suivent sont applicables pour des groupes de confiance ou pour un client (serveur) unique. Donc les paramètres pour le client appelé fw pourraient être aussi valables pour un autre, ou plusieurs éléments de ce même groupe.

9.1. Coté serveur.

Création des clés « génériques » pour serveur et par lui-même, identifié en un élément de confiance (-T). Voici la commande complète :

 ntp-keygen -T -I -p 1234

Avec comme mot de passe « 1234 », à l'écran s'affiche les données suivantes :

 Using OpenSSL version 90804f
 Random seed file /root/.rnd 1024 bytes
 Generating RSA keys (512 bits)...
 RSA 0 0 9       1 11 24                         3 1 2
 Generating new host file and link
 ntpkey_host_serveur->ntpkey_RSAkey_serveur.3386757375
 Generating IFF parameters (512 bits)...
 IFF 0 24 100    1 49 138        2 1 2           3 1 4
 Generating IFF keys (512 bits)...
 Confirm g^(q - b) g^b = 1 mod p: yes
 Confirm g^k = g^(k + b r) g^(q - b) r: yes
 Generating new iff file and link
 ntpkey_iff_serveur->ntpkey_IFFpar_serveur.3386757375
 Using host key as sign key
 Generating certificate RSA-MD5
 X509v3 Basic Constraints: critical,CA:TRUE
 X509v3 Key Usage: digitalSignature,keyCertSign
 X509v3 Extended Key Usage: trustRoot
 Generating new cert file and link
 ntpkey_cert_serveur->ntpkey_RSA-MD5cert_serveur.3386757375

L'une des premières actions du programme est de chercher, puis regarder le contenu du fichier /root/.rnd. Ce petit fichier bien anodin, est très important. Il est créé par la librairie OpenSSL, un échec en lecture sur ce fichier renvoie une erreur, et ntp-keygen s'arrête brutalement.

Mais sinon, la commande génère automatiquement les fichiers suivants :

 -rw-r--r-- 1 root root   533 Apr 28 15:56 ntpkey_IFFpar_serveur.3386757375
 -rw-r--r-- 1 root root   576 Apr 28 15:56 ntpkey_RSA-MD5cert_serveur.3386757375
 -rw-r--r-- 1 root root   618 Apr 28 15:56 ntpkey_RSAkey_serveur.3386757375
 lrwxrwxrwx 1 root root    37 Apr 28 15:56 ntpkey_cert_serveur -> ntpkey_RSA-MD5cert_serveur.3386757375
 lrwxrwxrwx 1 root root    32 Apr 28 15:56 ntpkey_host_serveur -> ntpkey_RSAkey_serveur.3386757375
 lrwxrwxrwx 1 root root    32 Apr 28 15:56 ntpkey_iff_serveur -> ntpkey_IFFpar_serveur.3386757375

Il est à noter que les liens ont été effectués. Le cas échéant il est nécessaire de les créer; c'est important sinon tout est voué à l'échec... j'ai testé !

Maintenant l'élément de confiance (serveur) doit générer un mot de passe pour les groupes de clés qui seront utilisés. serveur va donc faire la commande suivante. Il est facile de reconnaître les 2 mots de passe saisis précédemment :

 ntp-keygen -e -q 1234 -p client > iff-fw.txt

A l'écran s'affiche les données suivantes :

 Using Configfile /etc/ntp/ntp.conf and keysdir /etc/ntp/keys
 Creating group key file ntp_groupkey_20070428160920:
 ========= Invoking ntp-keygen ============
 Using OpenSSL version 90804f
 Random seed file /root/.rnd 1024 bytes
 Using IFF parameters ntpkey_IFFpar_serveur.3386757375
 Writing new IFF key ntpkey_IFFkey_serveur.3386757375

Ce fichier doit être transmis à fw de façon sécurisée, lequel renommera ce fichier en ntpkey_iff_serveur.

Attention le mot serveur correspond à la valeur hostname (nom de machine) de cette même machine.

9.2. Coté client.

Création des clés pour fw, identifiée en un élément de NON confiance, via la commande :

 ntp-keygen -H -p client

Avec comme mot de passe « client » A l'écran s'affiche les données suivantes :

 Using OpenSSL version 90804f
 Random seed file /root/.rnd 1024 bytes
 Generating RSA keys (512 bits)...
 RSA 0 5 9       1 11 24                         3 1 2
 Generating new host file and link
 ntpkey_host_fw->ntpkey_RSAkey_fw.3386758623
 Using host key as sign key
 Generating certificate RSA-MD5
 X509v3 Basic Constraints: critical,CA:TRUE
 X509v3 Key Usage: digitalSignature,keyCertSign
 Generating new cert file and link
 ntpkey_cert_fw->ntpkey_RSA-MD5cert_fw.3386758623

La commande génère automatiquement les fichiers suivants :

 rw-r--r--  1 root root    527 Apr 28 16:17 ntpkey_RSA-MD5cert_fw.3386758623
 -rw-r--r--  1 root root    613 Apr 28 16:17 ntpkey_RSAkey_fw.3386758623
 lrwxrwxrwx  1 root root     32 Apr 28 16:17 ntpkey_cert_fw -> ntpkey_RSA-MD5cert_fw.3386758623
 lrwxrwxrwx  1 root root     27 Apr 28 16:17 ntpkey_host_fw -> ntpkey_RSAkey_fw.3386758623

Les extensions de fichiers avec uniquement des chiffres correspondent au temps unix.

Dernière étape :

Avec la clé créée par serveur précédemment, puis transmise à fw ou au groupe, il faut désormais faire un lien vers cette clé.

 ln -sf ntp_groupkey_20070428160920 ntpkey_iff_serveur

9.3. Contrôle de l'authentification.

Soyez patient : l'authentification complète des connexions n'est vraiment pas rapide...Comptez plusieurs minutes. Pour mieux comprendre, vous pouvez utiliser l'option debug de ntpd.

Avec cette commande :

 /usr/sbin/ntpd -d -D2 -c /etc/ntp/ntp.conf -p /var/run/ntpd.pid

, vous allez découvrir les méandres et les multiples dialogues de « autokey », au travers des données qui sont retournées, et elles ne manquent pas.

Vous pouvez également utiliser la commande suivante pour visualiser l'état de vos connexions (chiffrées ou pas), ntpq -c as. Cette même commande vous renvoie des identifiants au lieu des noms de serveurs. Pour connaître à qui appartiennent ces chiffres, il suffit de faire la commande suivante : ntpq puis pstatus assocID. « assocID » représente l'un des chiffres identifiants les différentes connexions.

Voici en exemples différents connexions possibles :

 fw ntp # ntpq -c as
 ind assID status  conf reach auth condition  last_event cnt
 ===========================================================
   1 19334  9414   yes   yes  none  candidat   reachable  1
   2 19335  f414   yes   yes   ok   candidat   reachable  1
   3 19336  f614   yes   yes   ok   sys.peer   reachable  1
   4 19337  9014   yes   yes  none    reject   reachable  1

C'est parfait, les connexions sont chiffrées entre fw et 19335 et 19336.

Voici maintenant comment identifier 19335...

 fw ntp # ntpq
 ntpq> pstatus 19335
 assID=19335 status=f414 reach, conf, auth, sel_candidat, 1 event, event_reach,
 srcadr=serveur.archi.org, srcport=123, dstadr=192.168.1.2, dstport=123,
 leap=00, stratum=3, precision=-20, rootdelay=39.001,
 rootdispersion=124.191, refid=138.195.130.71, reach=377, unreach=0,
 hmode=3, pmode=4, hpoll=10, ppoll=10, flash=00 ok, keyid=1114124733,
 ttl=0, offset=-11.068, delay=0.129, dispersion=14.043, jitter=2.864,
 reftime=c9deda98.867bd487  Sun, Apr 29 2007 10:49:28.525,
 org=c9dedac1.79c0170f  Sun, Apr 29 2007 10:50:09.475,
 rec=c9dedac1.7cfb4fb3  Sun, Apr 29 2007 10:50:09.488,
 xmt=c9dedac1.7cea3853  Sun, Apr 29 2007 10:50:09.487,
 filtdelay=     0.19    0.14    0.14    0.15    0.13    0.17    0.16    0.18,
 filtoffset=  -12.53   -5.29   -7.89  -10.49  -11.07  -10.54   -9.33   -7.09,
 filtdisp=      0.00    7.70   11.52   15.38   17.33   19.28   21.20   23.13,
 hostname="serveur", signature="md5WithRSAEncryption", flags=0x83f21,
 trust="serveur"

Maintenant, je peux connaître à qui appartient ce chiffre de 19335. Ceci est donné par la valeur srcadr=serveur.archi.org, et qui correspond à serveur.

Le mot sel_candidat dans les toutes premières lignes signifient que cette connexion est en mode client/serveur. C'est le mode classique même si les 2 machines sont des serveurs NTP.

Voici les données pour l'identifiant 19336 :

 ntpq> pstatus 19336
 assID=19336 status=f614 reach, conf, auth, sel_sys.peer, 1 event, event_reach,

En ne gardant que les données intéressantes, le reste est très comparable à la précédente commande pour 19935. Il en ressort que cette connexion est identifiée comme sel_sys.peer. C'est le mode symétrique actif et passif, qui est le résultat de l'option peer.

De l'autre coté, du coté du serveur de référence me concernant, voici les données retournées :

 serveur keys # ntpq -c as
 ind assID status  conf reach auth condition  last_event cnt
 ===========================================================
   1 32930  9654   yes   yes  none  sys.peer   reachable  5
   2 32931  9014   yes   yes  none    reject   reachable  1
   3 32932  9414   yes   yes  none  candidat   reachable  1
   4 32933  d014   yes   yes   bad    reject   reachable  1
   5 32999  7014    no   yes   ok     reject   reachable  1
                

C'est nettement moins bon à mes yeux, mais l'autre serveur est bien reconnu, et tout se passe bien (...)

9.4. Renouvellement des clés.

Les clés doivent être changées au bout de 365 jours au maximum. Pour cela vous pouvez vous aider des données d'enregistrement au niveau des fichiers, lesquelles fournissent la date de création des fichiers. Ensuite il faut mettre à jour les paires de clés entre serveur et client(s). Voici les différentes commandes, les mots de passe client et 1234 ont été gardés. Si vous changez de mot de passe d'un coté comme de l'autre, il faut mettre à jour également le fichier ntp.conf.

Pour contrôler vos clés, vous pouvez utiliser la commande ntpq -c rv fw. Cette commande permet de connaître des détails entre serveur et fw en particulier au niveau de l'expiration des clés (expire=200804290753).

serveur ~ # ntpq -c rv fw
assID=0 status=4644 leap_add_sec, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.2.4@1.1437-o Sun Apr  8 08:48:56 UTC 2007 (1)",
processor="i686", system="Linux/2.6.16.20", leap=01, stratum=4,
precision=-20, rootdelay=38.902, rootdispersion=554.279, peer=59633,
refid=192.168.1.10,
reftime=c9e02787.6ecfe406  Mon, Apr 30 2007 10:29:59.432, poll=6,
clock=c9e028c6.59c3b638  Mon, Apr 30 2007 10:35:18.350, state=4,
offset=4.511, frequency=79.234, jitter=0.215, noise=1.595,
stability=0.227, hostname="fw", signature="md5WithRSAEncryption",
flags=0x80021, update=200704300833, ident="ntpkey_iff_fw", tai=0,
cert="serveur serveur 0x7", expire=200804290749, cert="fw fw 0x7",
expire=200804290753

9.5. Le fichier « leap-second »

Ce fichier est impératif (à mes yeux) lors de l'activation du contrôle de clés par « autokey ». J'ai rencontré un problème de timestamp au niveau des clés, résolu grâce à ce fichier...

Depuis 1972, une base de temps a été créée et elle tient compte de ces petites variations de la rotation de la terre.

Voici un exemple : le 31 décembre 1998 à 23:59:59 secondes, et grâce à cette correction, le 1er janvier est arrivé après 23:59:60 secondes. Voila comment gagner 1 seconde et retrouver une bonne référence horaire impérative.

Ce fichier est téléchargeable sur ce serveur (FTP) : ftp://time.nist.gov/pub/leap-seconds.3331497600.

Une fois téléchargé, il suffit de faire un lien dans le répertoire /etc/ntp/keys, puis de relancer ntpd :

 ln -sf leap-seconds.3331497600 ntpkey_leap

9.6. Remarques et contrôles sur « autokey »

En se servant de ntpd et des produits fournis avec lui, il n'est pas simple de comprendre comment fonctionne le système d'authentification par « autokey ». Après de nombreux essais, je suis arrive, je pense, à trouver une bonne solution. La mise au point et le contrôle des paramètres ont été contrôlés par le lancement de ntpd en mode debug. Pour mémoire, il suffit de le lancer avec la commande supplémentaire -d -D1 ou pour encore plus de détails, avec la commande -d -D2. A ce niveau les traces sont énormes...c'est à vous de voir. Ensuite il est possible de constater que vos connexions sont chiffrées et authentifiées.

En prenant comme exemple les extraits ci-dessous, et des dialogues entre 2 machines.

L'adresse IP 192.168.1.10 correspond à serveur, et l'autre serveur en 192.168.1.2 est identifié en fw. Il en ressort beaucoup de lignes, qui arrivent rapidement mais elles sont sécurisées, car le mot auth possède la valeur 1. Les paramètres keyid montrent également les différents échanges chiffrés et ceci se déroule dans les deux sens.

titre d'exemple, la dernière ligne montre une connexion non chiffrée, ni authentifiée (auth 0).

receive: at 36 192.168.1.10<-192.168.1.2 mode 3 code 3 keyid 4be1a142 len 48 mac 20 auth 2
transmit: at 59 192.168.1.10->192.168.1.2 mode 4 keyid 4e752efc len 56 mac 20
auth_agekeys: at 60 keys 1 expired 0
receive: at 61 192.168.1.10<-192.168.1.2 mode 3 code 3 keyid 302879bc len 80 mac 20 auth 1
crypto_xmit: flags 0x80023 ext offset 48 len 8 code 0x8202 assocID 0
transmit: at 61 192.168.1.10->192.168.1.2 mode 4 keyid 302879bc len 56 mac 20
receive: at 63 192.168.1.10<-192.168.1.2 mode 3 code 3 keyid e665b416 len 80 mac 20 auth 1
crypto_xmit: flags 0x80023 ext offset 48 len 8 code 0x8202 assocID 0
transmit: at 63 192.168.1.10->192.168.1.2 mode 4 keyid e665b416 len 56 mac 20
transmit: at 65 192.168.1.10->138.195.130.71 mode 3
receive: at 65 192.168.1.10<-138.195.130.71 mode 4 code 1 auth 0

De l'autre cote (fw), les traces sont identiques mais inversées, et donc non reprises.

Il est important maintenant de contrôler nos connexions par un moyen autre que le mode debug de ntpd. Voici comment contrôler ceci, toujours dans le cadre de « autokey » :

Ceci fait partie également de mes observations après mes X essais de configurations. Les exemples suivants prennent en compte mes paramètres de configuration proposés dans la première annexe de ce document. En prenant comme exemple un serveur maître nomme serveur et un client fw mais serveur tout de même, il en ressort les faits suivants : il est important de prendre en compte que le serveur fw demande à serveur 2 connexions, l'une est classique, et l'autre est l'activation de l'option peer. Vous n'avez aucun contrôle de l'authentification par la commande ntpq -c as depuis la machine serveur. Ceci peu paraître bizarre, mais c'est comme çà... par contre de l'autre coté, après un certain temps pour les échanges de clés, vous pourrez contrôler l'état de vos connexions chiffrées ou pas. Il est bon de savoir que vos connexions bougent ou changent du fait du protocole NTP, et de la stabilité des autres serveurs, et donc si vous perdez une connexion symétrique active, ceci est peut-être logique. Comme vous pouvez le découvrir dans l'exemple ci-dessous, l'une des connexions est déclarée comme bad en permanence. Ceci est à mon avis normal, car je demande 2 connexions sur le même serveur (serveur). Par contre au niveau de l'authentification celle-ci ci ne prend en compte qu'une seule connexion, ce qui au fond n'est pas grave, car je maintiens ma connexion peer très souvent active. Pendant ce temps le protocole NTP récupère le temps correct via un autre serveur.

fw ~ # ntpq -c as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 59684  8000   yes   yes  none    reject
  2 59685  f614   yes   yes   ok   sys.peer   reachable  1
  3 59686  c000   yes   yes   bad    reject
  4 59687  9014   yes   yes  none    reject   reachable  1
fw ~ # ntpq -c as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 59684  8000   yes   yes  none    reject
  2 59685  f024   yes   yes   ok     reject   reachable  2
  3 59686  c000   yes   yes   bad    reject
  4 59687  9614   yes   yes  none  sys.peer   reachable  1
fw ~ # ntpq -c as

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 59684  8000   yes   yes  none    reject
  2 59685  f624   yes   yes   ok   sys.peer   reachable  2
  3 59686  c000   yes   yes   bad    reject
  4 59687  9014   yes   yes  none    reject   reachable  1
                

Du coté du serveur serveur, la connexion est déclarée comme symétrique passive, et c'est normal car la liaison ne se fait que dans un sens. Ceci est inversé, en faisant la commande ntpdc -c listpeers depuis la machine fw. Voici le résultat qui correspond aux paramètres de configuration (ntp.conf):

fw ~ # ntpdc -c listpeers
sym_active serveur.archi.org
client    serveur.archi.org
client    LOCAL(0)
client    krishna.via.ecp.fr

10. /etc/init.d/ntpd

Ce script sert uniquement à lancer le programme ntpd en mode résidant. Comme ntpd agit dans le noyau, il doit être lancé en tant que root. Par défaut ntpd utilise le répertoire /etc pour trouver son fichier de configuration (ntp.conf). Si vous utilisez comme moi un répertoire différent comme /etc/ntp lancez ntpd avec l'option -c /etc/ntp/ntp.conf. Il est utile de lancer également ntpd avec l'option -p /var/run/ntpd.pid. Cette option donne l'ordre d'écrire le PID (process identification) dans un répertoire précis.

J'ai essayé de lancer ntpd avec l'option -u ntp:ntp, ce qui veut dire : en tant qu'utilisateur et groupe « ntp ». Mais il ne peut mettre le kernel à jour, ce qui est tout de même dommage. Désormais, il est résidant en mémoire en tant que « root », et tout se déroule bien. Vous pouvez ajouter d'autres options, référez vous à la section ntpd pour plus de renseignements sur les options.

11. /etc/init.d/ntp-client

Ce script est typique à chaque distribution Gnu/Linux. Il est chargé de mettre à jour le kernel via la commande ntpdate -s -b -u "serveur-NTP". Comme déjà écrit, il est aussi possible de lancer cette commande via la crontabcrontab. Ceci reste valable aussi pour la commande ntpdate qui est comparable à /usr/sbin/ntpd -q. A noter que la commande ntpd -q nécessite un fichier de configuration, contrairement à ntpdate. Pour une station cliente, il est préférable d'utiliser ntpdate...

12. Configuration de votre réseau NTP

12.1. Les modes d'associations serveurs/clients.

Les modes signifient également associations. La puissance des associations est exploitée pleinement par le protocole NTP version 4. Toutefois il accepte néanmoins la version 3 en mode dégradé.

Il existe deux modes principaux : persistant et éphémère . En générale, une association non persistante est synonyme d'authentification au niveau du serveur. Ce mode devient éphémère vers un serveur injoignable, ou pour des problèmes de clés (authentifications).

12.2. Les modes opératoires.

12.3. Les relations spécifiques entres serveurs.

C'est aussi une étape indispensable avant d'attaquer la configuration du fichier ntp.conf. Il est important de savoir quoi, et comment configurer, ou relier différentes sources NTP. Ceci rentre dans le cadre du renforcement et du durcissement du réseau, aidé bien sûr par le protocole NTP. Pour mémoire, le protocole NTP sélectionne dans le cas de plusieurs sources (strate 2 et +), le meilleur réseau et les meilleurs données horaires. Il prend comme base (sans le savoir) la stabilité des sources comme les générateurs au Césium, les GPS référencés comme sources très fiables et stables. Pour mémoire également, les sondes radio peuvent être perturbées par des signaux parasites. Toutes ces relations possibles rentrent dans le domaine de la mitigation des références horaires. Pour prendre en compte ceci, et rendre le réseau plus fiable, il est possible de modifier le comportement de l'algorithme NTP, en fonction du réseau.

12.4. Schéma NTP

Comme vous pouvez le découvrir il est possible d'obtenir un réseau très varié et très fiable. Les diverses relations mélangent les relations classiques clients/serveurs, mais aussi le mode « symétrique actif ». Il faut penser pour faire un bon réseau NTP qu'un élément peut tomber, et que ceci ne doit pas perturber votre réseau tout de même.

Note

Comme le montre le schéma suivant, plus les niveaux de strates augmentent et plus les clients également augmentent.

Les traits de couleur noire représentent des relations virtuelles, mais simulent des sources diverses.

Les traits de couleur bleue représentent des relations classiques en mode client/serveur.

Les traits multi couleurs représentent des relations symétriques (peer).

13. Configuration de serveurs (ntp.conf).

Avertissement

Il est OBLIGATOIRE que le fichier /etc/localtime présent sur toutes les distributions Gnu/Linux, soit réglé sur la bonne plage. Ceci est simple à faire, beaucoup de distributions copient le fichier désigné pour la déclaration du fuseau horaire. Pour le modifier il suffit simplement de supprimer le fichier /etc/localtime.

La bonne et la plus souple des solutions, qui permet également un meilleur contrôle, est de faire un lien vers le fichier qui gère la zone horaire. Tous les fichiers de gestion des fuseaux horaires sont présents dans le répertoire /usr/share/zoneinfo/. Pour réaliser ce lien il suffit de faire la commande suivante :

ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime

Et voilà, ceci vous évitera un blocage de ntpd, et un décalage supérieur à 1000 secondes.

14. Configurer le fichier « ntp.conf »

Note

Ce chapitre va traiter des commandes classiques serveurs/clients sans sonde de référence. La seconde partie prend en compte uniquement la déclaration d'une source (GPS, DCF77...) pour un serveur en strate 1.

C'est le fichier le plus important pour votre serveur NTP; de lui dépend beaucoup de choses. Plusieurs parties sont identifiables dans ce fichier, dont la déclaration des serveurs, vos préférences, la déclaration de votre serveur, l'authentification, les restrictions d'accès, les différents fichiers de traces...

14.1. Déclaration de serveurs classiques (strate N+1).

C'est le mode de déclarations pour les strates 2 et plus. C'est très simple : il suffit de paramétrer dans la mesure du possible, plusieurs sources de niveaux inférieurs à vous (strate N-1 ou -2). Si celui-ci n'est pas protégé, vous pouvez « remonter » de plusieurs niveaux. Il est toutefois nécessaire de faire des essais, de vérifier vos fichiers de traces. Il est également important de surveiller votre serveur sur plusieurs jours, car le principe de NTP est la douceur.

Voici en exemple : Un extrait de mon fichier de configuration pour un serveur en strate 3, car je dépends de serveurs en strate 2. Ceci concerne la partie déclaration de serveurs :

# ////////////// SERVEURS \\\\\\\\\\\\\\
# Declaration des serveurs classiques
server krishna.via.ecp.fr prefer # fiable -> 138.195.130.71 - STRATE 2
server 195.83.66.158 iburst      # IP en peer (ntp.univ-poitiers.fr)
#
# Declaration de serveurs qui participent :
peer syrte8.obspm.fr            # 145.238.110.68
server 3.fr.pool.ntp.org        # XX IP...
#
#
# declaration/activation de mon serveur en STRATE 3
#  avec auth uniquement pour le peer.
server 127.127.1.0          # local horloge
fudge 127.127.1.0 stratum 3 refid AmT3 autokey
#

14.1.1. L'instruction : server 127.127.t.u [prefer] [mode int] [minpoll int] [maxpoll int]

Une fois configuré vos serveurs de façon classique, vous pouvez paramétrer les diverses options comme prefer et/ou peer. Et pour finir, vous devez déclarer votre propre machine comme serveur avec la commande server 127.127.... , et vous l'activez avec la commande fudge 127.127.... Il est important désormais de penser à la sécurité, et donc aux restrictions d'accès. Parmi les serveurs internet actifs en NTP, j'ai choisi par pur hasard une grappe de serveurs NTP, dans la mesure où le nom de 3.fr.pool.ntp.org, correspond à plusieurs adresses IP. Il est important de les prendre en compte toutes. Vous ne maîtrisez pas comment ntpd choisira laquelle dans la liste. Mon serveur utilise l'option refid pour identifier mon service sous 3 lettres et le numéro de strate. C'est une option bien pratique, qui personnalise votre serveur.

Pour l'instruction server référez vous à cette section.

Pour l'instruction fudge référez vous à cette section.

Voici des limitations possibles en exemple :

#///////////// RESTRICTIONS \\\\\\\\\\\
# Les restrictions d'acces :
# Ajouter vos reseau dans les restrictions ...
# La limitation globales :
restrict default limited noserve kod
#
# pour le serveur qui a X IP :
restrict 80.74.64.1
restrict 80.74.64.2
restrict 81.56.251.175
restrict 81.91.70.122
restrict 82.230.52.122
restrict 82.233.51.156
restrict 87.98.219.90
restrict 88.191.12.200
restrict 195.83.66.158  # univ-poitiers.fr
# pour le serveur :
restrict 138.195.130.71
# pour le serveur :
restrict 145.238.110.68   # syrte
restrict 213.41.185.119   # serveur nerim.net
#
# pour mon horloge locale et service locale
restrict 127.0.0.1 mask 255.0.0.0
# pour mon reseau locale
restrict 192.168.1.2 mask 255.255.255.0 notrust notrap
# pour le reste de mon reseau ... soit plus grand chose, mais bon...
restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer noquery kod version limited notrap
# pour manycast ... en test
restrict 239.1.1.1 nomodify nopeer kod
#

Une fois de plus les options sont modifiables comme vous le voulez. Je pense en particulier à l'option kod.

14.2. Déclaration de votre serveur en strate 1.

Note

Ce chapitre ne reprend pas les données de configuration présentées dans le chapitre précédent. Ce chapitre n'explique pas non plus comment raccorder des sources de temps matériels, qui possèdent déjà un serveur à l'intérieur. Dans cette situation, vous devez vous référez au chapitre précédent, et à la documentation précise du constructeur.

ntpd comporte de très nombreux pilotes pour les sources de temps dans ses fichiers sources. Par défaut, tous les pilotes dans ntpd sont inclus lors de la compilation par l'emploi du paramètre --enable-all-clocks. Il est possible de compiler ntpd pour un ou plusieurs pilotes particuliers. Voici la liste, elle vous permettra également de connaître si votre matériel est supporté et reconnu. Cette liste est extraite des options de compilation pour ntp en version 4.2.4

  --enable-BANCOMM        - Datum/Bancomm bc635/VME interface
  --enable-GPSVME         - TrueTime GPS receiver/VME interface
  --enable-all-clocks     + include all suitable non-PARSE clocks:
  --enable-ACTS           s ACTS modem service
  --enable-ARBITER        + Arbiter 1088A/B GPS receiver
  --enable-ARCRON-MSF     + Arcron MSF receiver
  --enable-AS2201         + Austron 2200A/2201A GPS receiver
  --enable-ATOM           s ATOM PPS interface
  --enable-CHRONOLOG      + Chrono-log K-series WWVB receiver
  --enable-CHU            + CHU modem/decoder
  --enable-AUDIO-CHU      s CHU audio/decoder
  --enable-DATUM          s Datum Programmable Time System
  --enable-DUMBCLOCK      + Dumb generic hh:mm:ss local clock
  --enable-FG             + Forum Graphic GPS
  --enable-HEATH          s Heath GC-1000 WWV/WWVH receiver
  --enable-HOPFSERIAL     + hopf serial clock device
  --enable-HOPFPCI        + hopf 6039 PCI board
  --enable-HPGPS          + HP 58503A GPS receiver
  --enable-IRIG           s IRIG audio decoder
  --enable-JJY            + JJY receiver
  --enable-JUPITER        s Rockwell Jupiter GPS receiver
  --enable-LEITCH         + Leitch CSD 5300 Master Clock System Driver
  --enable-LOCAL-CLOCK    + local clock reference
  --enable-MX4200         s Magnavox MX4200 GPS receiver
  --enable-NEOCLOCK4X     + NeoClock4X DCF77 / TDF receiver
  --enable-NMEA           + NMEA GPS receiver
  --enable-ONCORE         s Motorola VP/UT Oncore GPS receiver
  --enable-PALISADE       s Palisade clock
  --enable-PCF            + Conrad parallel port radio clock
  --enable-PST            + PST/Traconex 1020 WWV/WWVH receiver
  --enable-RIPENCC        - RIPENCC specific Trimble driver
  --enable-SHM            s SHM clock attached thru shared memory
  --enable-SPECTRACOM     + Spectracom 8170/Netclock/2 WWVB receiver
  --enable-TPRO           s KSI/Odetics TPRO/S GPS receiver/IRIG interface
  --enable-TRUETIME       s Kinemetrics/TrueTime receivers
  --enable-TT560          - TrueTime 560 IRIG-B decoder
  --enable-ULINK          + Ultralink WWVB receiver
  --enable-WWV            s WWV Audio receiver
  --enable-ZYFER          + Zyfer GPStarplus receiver
  --enable-parse-clocks   - include all suitable PARSE clocks:
  --enable-COMPUTIME      s Diem Computime Radio Clock
  --enable-DCF7000        s ELV/DCF7000 clock
  --enable-HOPF6021       s HOPF 6021 clock
  --enable-MEINBERG       s Meinberg clocks
  --enable-RAWDCF         s DCF77 raw time code
  --enable-RCC8000        s RCC 8000 clock
  --enable-SCHMID         s Schmid DCF77 clock
  --enable-TRIMTAIP       s Trimble GPS receiver/TAIP protocol
  --enable-TRIMTSIP       s Trimble GPS receiver/TSIP protocol
  --enable-WHARTON        s WHARTON 400A Series clock
  --enable-VARITEXT       s VARITEXT clock

Chaque source de temps est identifiée sous la forme 127.127.t.u. La lettre « t » est le modèle de votre horloge, et la valeur « u » représente une valeur de 0 à 3, pour distinguer les multiples horloges ou sources de strate 0 qui peuvent être présentes sur une même machine.

Voici la liste des modèles d'horloges possibles (valeur t = numéro dans la liste suivante ) :

  1. Non discipline horloge locale. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html.

  2. Trak 8820 GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver2.html.

  3. PSTI/Traconex 1020 WWV/WWVH Receive. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver3.html.

  4. Spectracom WWVB and GPS Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver4.html.

  5. TrueTime GPS/GOES/OMEGA Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver5.html.

  6. IRIG Audio Decoder. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html.

  7. Radio CHU Audio Demodulator/Decoder. Pour plus de renseignements : x http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver7.html.

  8. Generic Reference Driver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html.

  9. Magnavox MX4200 GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver9.html.

  10. Austron 2200A/2201A GPS Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver10.html.

  11. Arbiter 1088A/B GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver11.html.

  12. KSI/Odetics TPRO/S IRIG Interface. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver12.html.

  13. Leitch CSD 5300 MasterClock Controller

  14. EES M201 MSF Receiver

  15. reserved

  16. Bancomm GPS/IRIG Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver16.html.

  17. Datum Precision Time System

  18. Automated Computer Time Service. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver18.html.

  19. Heath WWV/WWVH Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver19.html.

  20. Type 20 Generic NMEA GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html.

  21. TrueTime GPS-VME Interface

  22. PPS Clock Discipline. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html.

  23. reserved

  24. reserved

  25. reserved

  26. Hewlett Packard 58503A GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver26.html.

  27. Arcron MSF Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver27.html.

  28. Shared Memory Driver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html.

  29. Trimble Navigation Palisade GPS. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html.

  30. Motorola UT Oncore GPS. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver30.html.

  31. Rockwell Jupiter GPS. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver31.html.

  32. Chrono-log K-series WWVB receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver32.html.

  33. Dumb Clock. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver33.html.

  34. Ultralink WWVB Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver34.html.

  35. Conrad Parallel Port Radio Clock. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver35.html.

  36. Radio WWV/H Audio Demodulator/Decoder. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver36.html.

  37. Forum Graphic GPS Dating station. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver37.html.

  38. hopf GPS/DCF77 6021/komp for Serial Line. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver38.html.

  39. hopf GPS/DCF77 6039 for PCI-Bus. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver39.html.

  40. JJY Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver40.html.

  41. TrueTime 560 IRIG-B Decoder

  42. Zyfer GPStarplus Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver42.html.

  43. RIPE NCC interface for Trimble Palisade. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver43.html.

  44. NeoClock4X - DCF77 / TDF serial line. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver44.html.

14.2.1. L'instruction : fudge 127.127.t.u [time1 sec] [time2 sec] [stratum int] [refid string] [mode int] [flag1 0|1] [flag2 0|1] [flag3 0|1] [flag4 0|1]

Il n'est pas nécessaire d'utiliser toutes les options pour activer un serveur de strate 1. Certaines restent tout de même un mystère pour moi, mais bon, il faut prendre en compte qu'il existait à une époque des sources de temps via des modem... Ceci peut, aider à mieux comprendre certaines valeurs.

14.2.2. Broadcast | Manycast | Multicast.

Comme déjà mentionné, ces activations nécessitent des plages d'adresses spécifiques sur votre réseau.

14.3. Les restrictions.

Les restrictions sont présentes pour sécuriser le réseau; elles interviennent sur plusieurs niveaux.

Les différentes possibilités possibles sont :

14.3.1. discard [average avg] [minimum min] [monitor prob]

Cette option est là pour protéger le serveur des clients qui abusent. La valeur average spécifie la moyenne minimum d'espace temps entre les paquets. La valeur minimum spécifie la valeur minimum entre chaque paquet. Si cette valeur est atteinte, le paquet est rejeté et un paquet kod est envoyé si cette option est activée. Les valeurs par défaut sont : average 5 et minimum 2, la valeur monitor spécifie la probabilité de rejeter les paquets qui dépassent les quotas.

14.3.2. restrict address [mask mask] [flag] [...]

Note

Il est possible de placer plusieurs lignes avec des restrictions différentes. Ces restrictions sont traitées comme pour les pare-feux, en commençant par la première ligne, puis la deuxième... Il est donc important d'être prudent dans ses limitations aux risques de tout autoriser, d'interdire trop.

La valeur restrict address désigne une adresse IP, une plage ou tous les réseaux (0.0.0.0). Elle se présente sous la forme d'une adresse définie comme ntp1.ntp.org ou par son adresse IP. Elle peut être complémentée par la valeur mask. Il existe une valeur default avec comme valeurs address l'adresse IP à 0.0.0.0, et pour mask la valeur de 0.0.0.0.

Les drapeaux (flag) possibles sont :

Note

Par défaut, ntpd configure la ou les adresses IP locales avec les drapeaux ignore, interface, ntpport pour éviter au serveur de se synchroniser sur lui-même au démarrage.

Tableau 1.7. Explications des options.

Option

Explication

ignore

Ignore tous les paquets, sont inclus les requêtes venant de ntpq/ntpdc..

kod

Le fameux baiser de la mort qui est émis lors d'une violation d'accès.(Kiss-of-death/KoD). Cette option est faite pour faire comprendre à l'émetteur (client/serveur NTP) par retour d'un paquet spécial qu'il est inutile de continuer.

limited

Interdit l'accès au service NTP, si le paquet atteint l'une des valeurs décrites dans l'option discard.

lowpriotrap

Déclare comme non prioritaire le serveur/réseau désigné. Cette limitation ne possède pas de limite pour les déclarations, la valeur est de 3. Ce drapeau modifie l'algorithme par l'attribution d'un niveau bas en priorité, qui peut être ensuite une requête normale.

nomodify

Interdit les programmes (ntpq/ntpdc)) de modifier les paramètres, ou les valeurs de ntpd en mémoire. Les interrogations sont possibles, le service de temps n'est pas affecté ou modifiable.

noquery

Contrairement au paramètre précédent, les interrogations sont interdites. Le service de temps n'est pas affecté.

nopeer

Interdit les requêtes qui demandent une nouvelle association. Applicable pour les broadcast, manycast et le mode symétrique actif également

noserve

Interdit tous les paquets à l'exception des requêtes en provenance des programmes ntpq/ntpdc. Cette option transforme ntpd en un serveur ntp local.

notrap

Refuse les paquets en mode de contrôle (6). Ce mode visualise principalement les clients sur votre serveur. C'est également un client qui cherche à connaître comment fonctionne votre serveur, au niveau des connexions/associations.

notrust

Refuse les paquets sans authentification (par clés).

ntpport

Restriction uniquement pour le port 123 en UDP. La valeur non-ntpport peut être aussi utilisée. A employer dans des situations spécifiques.

version

Rejette les paquets qui ne comprennent pas la version du protocole NTP à l'intérieur.



14.4. broadcast delay seconds

Ne sert que dans le cas d'une activation du mode broadcast et multicast. Cette valeur qui est calibrée automatiquement, mais peut être changée par des valeurs allant de 0,003 à 0,008. Par défaut, la valeur est 0,004 seconde.

14.5. driftfile driftfile

Cette commande spécifie l'emplacement et le nom du fichier drift utilisé par ntpd. Ce fichier sert à NTP pour stocker la fréquence de réglage pour l'horloge système, elle est mise à jour une fois par heure. Si ce fichier existe, il est lu au démarrage, permettant à NTP de gagner un peu de temps pour se synchroniser. Si ce fichier est absent, NTP utilise une fréquence égale à zéro, et mettra plusieurs heures pour se stabiliser. Ce fichier comporte une seule ligne à l'intérieur, ou une seule valeur exprimée en partie par million (PPM). Mon fichier comporte la valeur 500.000 à titre d'exemple.

Pour le nommage et l'emplacement du fichier, par défaut le fichier s'appelle ntp.drift, il est situé généralement dans le répertoire /var/lib/ntp. Personnellement je l'ai placé dans le répertoire /etc/ntp afin de réduire la dispersion des fichiers. Bien prendre en compte que ce fichier doit pouvoir être écrit par le super utilisateur ou l'utilisateur « ntp:ntp » selon votre configuration.

14.6. enable | disable [auth | bclient | calibrate | kernel | monitor | ntp | stats]

Les options enable ou disable permettent d'activer ou de rendre inactives certaines options.

Tableau 1.8. Explications des options.

Option

Explication

auth

Cette option active l'authentification.

bclient

Utilisé pour le mode « broadcastclient », elle active l'authentification obligatoire dans ce mode.

calibrate

Active la facilité de calibration pour le time1 pour chaque horloge (strate 0), et pour afficher la même fréquence que la source sélectionnée. Cette source pouvant être le noyau. Par défaut, cette option est désactivée.

kernel

Active une option de précision de l'horloge pour le noyau, lors d'un appel de la fonction adjtime. Ceci est théoriquement inclus dans le noyau, et détecté automatiquement par ntpd. Cette option est généralement non activée pour les noyaux en développement. Par défaut cette option est activée.

monitor

Active les paramètres de supervision ou de contrôle pour ntpd. Cette option est activée par défaut.

ntp

Cette valeur supprime la mise à jour de l'horloge locale par NTP. Cette valeur est utilisée lors d'une mise à jour de cette même horloge par un autre système ou source. Par défaut cette valeur est activée.

stats

Active la fonction de production de statistiques par NTP. Cette option sera expliquée plus en détail dans le chapitre statistique. Par défaut cette option est activée.



14.7. Paramètres pour les traces/l'historique.

Par défaut, NTP écrit les historiques de ces actions via syslog, mais ces données ne sont pas forcément toujours très explicites. Il est possible d'obtenir plus de renseignements en activant les options décrites maintenant .

14.7.1. logconfig configkeyword

Donne des instructions complémentaires pour les traces écrites par syslog, ou vers un fichier spécifique définie en utilisant l'option suivante logfile. Par défaut tous les préfixes sont activés, mais il est possible de les modifier.

Les préfixes sont :

Les classes d'événements sont :

14.7.2. logfile logfile

Solution que je ne peux que conseiller pour plus de clarté. Sa définition se présente sous la forme :

logfile /var/log/ntpd.log

14.7.3. setvar

Exemple :

setvar access_policy="open access" default

Cette option permet d'activer une variable dans ntpd pour information. Une variable ne possède aucune action possible.

14.7.4. tinker [step step | panic panic | dispersion dispersion | stepout stepout | minpoll minpoll | allan allan | huffpuff huffpuff]

Cette option est à utiliser pour modifier fortement le comportement de NTP. Les valeurs par défaut sont toutes optimisées, mais il est possible d'intervenir tout de même sur ces valeurs. La documentation officielle souligne tout de même, qu'il est très rare que soit modifiées ces valeurs.

14.7.4.1. step step

Cette option modifie dans le noyau, la fréquence de mise à jour. Par défaut cette valeur est calibrée à 0,128 seconde. Il est possible de la modifier, la valeur de 0 supprime la régulation horaire du noyau.

14.7.4.2. panic panic

C'est le fameux paramètre qui protège votre serveur, si un décalage horaire est supérieur à 1000 secondes. Cette option est modifiable, la valeur 0 supprime cette protection.

14.7.4.3. dispersion dispersion

Cet argument modifie le taux de « dispersion », réglé par défaut à 0,000015 s/s.

14.7.4.4. stepout stepout

Cette valeur représente la valeur maximale pour la fréquence de mise à jour. Cette valeur est par défaut calibrée à 900 secondes; la valeur de 0 supprime cette option ou ce contrôle.

14.7.4.5. minpoll minpoll

Les options minpoll/maxpoll représentent le minimum et le maximum de temps entre 2 messages pour une bonne référence de l'horloge. Cette valeur doit être exprimée en seconde. Par défaut les 2 valeurs sont à 6 ou 64 secondes. Ces options sont en parties utilisées avec des modems.

14.7.4.6. allan allan

Cette valeur modifie l'interception « Allan » pour les horloges PLL.FLL. Par défaut est réglé à 1500 secondes.

14.7.4.7. huffpuff huffpuff

C'est un système expérimental de filtre huff-n'-puff...

14.7.5. trap host address [port port_number] [interface interface_address]

Cette option installe un « piège » sur une adresse IP précise, et un port défini. Si le port n'est pas spécifié, la valeur par défaut de 18447 sera prise. Si l'adresse IP n'est pas spécifié, le message sera transmis sur l'interface classique.

14.8. Les fichiers de traces.

ntpd inclut des facilités de contrôles multiples. Il existe également des scripts pour contrôler NTP dans le répertoire .scripts, en se basant sur les sources (!).

Comme pour beaucoup de programmes, il est préférable de rassembler les fichiers ensemble. La variable statsdir reçoit comme argument l'emplacement de stockage des fichiers. Voici un exemple :

 # Répertoire contenant les statistiques d'utilisation
 statsdir /var/log/ntpstats/

14.8.1. statistique name [...]

Cette option doit être utilisée avec au moins un des paramètres suivants; chacune procure des données spécifiques. Pour vous aider, voici comment il est possible de configurer diverses options :

 # Statistiques désirées
 statistics loopstats peerstats clockstats sysstats

14.8.2. filegen name [file filename] [type typename] [link] [enable | disable]

Après les choix proposés par statistics, il est nécessaire de donner des informations précises pour l'enregistrement, et le suivi des différents fichiers.

Voici un exemple

 filegen loopstats file loopstats type week enable
 filegen peerstats file peerstats type week enable
 # Si vous avez une reference de temps, utiliser clockstats...
 #filegen clockstats file clockstats type week enable
 filegen sysstats file sysstats type week enable

15. Les fichiers de traces.

15.1. Les traces dans /var/log/messages

Le programme ntpd utilise les facilités de syslog pour écrire certaines données. Comme le montre l'exemple ci-dessous, ntpd à son lancement, indique sa précision horaire, puis indique les ports d'écoutes #123 Enabled. La valeur kernel time sync status 0040 indique une mauvaise synchronisation avec l'horloge locale. Ce qui est normal dès son lancement. Cette valeur changera dans un temps inférieur à 4 minutes, si tout va bien. Ensuite ntpd à utilisé le fichier /etc/ntp/ntp.drift pour se stabiliser plus rapidement. Et voila, après plus rien... les autres historiques sont inscrites dans les autres fichiers spécifiques.

Apr 16 06:19:10 serveur ntpd[21702]: ntpd 4.2.2p3@1.1577-o Sat Mar 24 05:48:24 UTC 2007 (1)
Apr 16 06:19:11 serveur ntpd[21703]: precision = 1.000 usec
Apr 16 06:19:11 serveur ntpd[21703]: ntp_io: estimated max descriptors: 1024, 
                                     initial socket boundary: 16
Apr 16 06:19:11 serveur ntpd[21703]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Apr 16 06:19:11 serveur ntpd[21703]: Listening on interface lo, 127.0.0.1#123 Enabled
Apr 16 06:19:11 serveur ntpd[21703]: Listening on interface eth0, 192.168.1.10#123 Enabled
Apr 16 06:19:11 serveur ntpd[21703]: kernel time sync status 0040
Apr 16 06:19:11 serveur ntpd[21703]: frequency initialized -33.555 PPM from /etc/ntp/ntp.drift

15.2. Le fichier /var/log/ntpd.log

C'est le fichier principal pour contrôler le bon fonctionnement et les déroulements pour votre serveur. Avec un peu d'habitude, les historiques sont assez simples à comprendre; voici les explications en fonction de l'exemple ci-dessous.

Pour frequency error 512 PPM exceeds tolerance 500 PPM, indique que mon horloge CMOS ou système demande pour pouvoir être stable des valeurs hors créneaux. C'est le cas d'horloge comme la mienne qui ne semble pas précise du tout. Ceci n'est pas un problème, NTP est présent et c'est lui qui compte..

ntpd exiting on signal 15, typique d'un arrêt violent de « ntpd », suite à action volontaire de l'administrateur. Ce n'est pas un plantage...

kernel time sync enabled 0001 veut dire que l'horloge locale est synchronisée; tout va bien désormais ... La même ligne mais avec une valeur de 0040 indique une synchronisation en cours, ou un problème de synchronisation...

Le message est composé de 2 valeurs : la première est le problème qui est exposé, et la seconde est la solution. time correction of -7200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. ntpd Comme j'ai subi cette indication, ntpd indique (sans l'écrire) qu'il vient d'arrêter le protocole NTP. Ce qui est loin d'être excellent ... et ceci est normal; il s'agit d'une protection du protocole NTP. Si celui-ci doit à un instant « t » faire une mise à jour supérieure à 1000 secondes, il s'arrête. Pour résoudre le problème « ntpd » vous explique la solution. Il faut que ma machine soit réglée sur une bonne zone horaire (Paris).

Voir cette section pour résoudre ce type de problème.

Ensuite les mots synchronized to 138.195.130.71, stratum 2 indiquent que ntpd change régulièrement de serveur pour se synchroniser, il mentionne en plus de l'adresse IP, le niveau de strate. Pour mémoire mon serveur est déclaré en strate 3, donc je me synchronise sur des strates de niveaux 2.

15 Apr 14:53:15 ntpd[8643]: frequency error 512 PPM exceeds tolerance 500 PPM
15 Apr 14:54:12 ntpd[8643]: synchronized to 195.83.66.158, stratum 3
15 Apr 14:54:12 ntpd[8643]: frequency error 512 PPM exceeds tolerance 500 PPM
15 Apr 15:28:06 ntpd[8643]: synchronized to 138.195.130.71, stratum 2
15 Apr 15:30:20 ntpd[8643]: synchronized to 195.83.66.158, stratum 3
15 Apr 17:42:52 ntpd[8643]: ntpd exiting on signal 15
15 Apr 20:17:13 ntpd[6354]: synchronized to LOCAL(0), stratum 3
15 Apr 20:17:13 ntpd[6354]: kernel time sync enabled 0001
15 Apr 20:17:14 ntpd[6354]: synchronized to 145.238.110.68, stratum 2
15 Apr 20:26:41 ntpd[6354]: ntpd exiting on signal 15
15 Apr 22:46:52 ntpd[6501]: synchronized to LOCAL(0), stratum 3
15 Apr 22:46:52 ntpd[6501]: kernel time sync enabled 0001
15 Apr 22:49:01 ntpd[6501]: synchronized to 138.195.130.71, stratum 2
15 Apr 22:49:01 ntpd[6501]: time correction of -7200 seconds exceeds sanity limit (1000); 
                            set clock manually to the correct UTC time.
16 Apr 06:22:29 ntpd[21703]: synchronized to LOCAL(0), stratum 3
16 Apr 06:22:29 ntpd[21703]: kernel time sync enabled 0001
16 Apr 06:23:34 ntpd[21703]: synchronized to 138.195.130.71, stratum 2
16 Apr 07:01:04 ntpd[21703]: synchronized to 145.238.110.68, stratum 2
16 Apr 07:08:31 ntpd[21703]: synchronized to 138.195.130.71, stratum 2
16 Apr 07:51:27 ntpd[21703]: synchronized to 145.238.110.68, stratum 2
16 Apr 10:29:50 ntpd[21703]: synchronized to 138.195.130.71, stratum 2
16 Apr 10:33:02 ntpd[21703]: synchronized to 145.238.110.68, stratum 2
16 Apr 11:10:43 ntpd[21703]: synchronized to 138.195.130.71, stratum 2

16. NTP et les pare-feux

Il suffit de laisser passer le protocole UDP et le port 23 vers au moins le pare-feu et ses clients potentiels. Comment déjà écrit, le protocole NTP en version 4 avec l'authentification « autokey » ne supporte pas la translation d'adresse.

17. Mémo de commandes utiles ou fréquentes.

Voici diverses commandes que j'utilise assez régulièrement; il en existe très probablement d'autres.

La commande ntptime pour contrôler rapidement si votre serveur est synchronisé (doit afficher « OK »).

La commande ntpdc -p pour afficher vos relations/synchronisations entres serveurs.

La commande tail -f /var/log/ntpd.log pour afficher si votre serveur fonctionne bien également.

Dès le lancement de ntpd en mode résidant, il faut regarder dans le fichier /var/log/messages, si aucune erreur n'est indiquée, et également si les ports 123 sont ouverts sur les interfaces réseaux.

La commande netstat -nap | grep ntpd vous permet de connaître les ports NTP ouverts pour votre machine.

Qui utilise votre serveur : ntpdc -c monlist.

Pour connaître vos relations entre serveurs, en particulier le fameux « peer » ntpdc -l.

La commande ntpdc -c listpeers indique les relations entre les serveurs.

18. Conclusion.

Pour des besoins professionnels je devais connaître NTP à tous niveaux. Au début je pensais que cet article serait terminé rapidement, je ne pensais pas du tout à cette époque, à la complexité du protocole NTP. Pour transmettre des données horaires, il était pour moi non nécessaire de déployer une usine à gaz. NTP n'est surtout pas cette description, mais c'est réellement à mes yeux un superbe protocole. Le déploiement et la configuration sont tout de même complexe. Après tout ceci, je m'étonne que soit utilisé le protocole SNTP de nos jours. Heureusement celui-ci n'arrive pas à s'imposer; je pense en particulier à Microsoft™ qui utilise se protocole dans Active Directory, et donc également pour ses serveurs.

Bien que très bien réalisée et actualisée régulièrement, la documentation technique sur le site de NTP utilise tout de même des expressions et des mots en anglais qui lors de mes traductions puis de mes compréhensions m'ont fortement fait ralentir. Les termes « cooked/digestion/fuzzball... » ne sont pas toujours simples à traduire dans le contexte. Ceci reste mon avis personnel. J'ai trouvé la documentation en ligne un peu éclatée, dans la mesure ou, vous devez assez régulièrement revenir vers un détail expliqué sur une page, pour finir sur d'autres... Mais bon, les rédacteurs sont pleins d'humour, et cette documentation est agréable à lire et instructive.

J'espère, en tout cas, et c'est un peu mon but, que cette documentation vous apportera de quoi comprendre, et déployer soit votre serveur, soit un réseau NTP, dans de bonnes conditions. Cette documentation est ouverte à toutes modifications et remarques. Mes coordonnées sont inscrites tout au début du document.

A signaler que Nagios possède un module spécial check_ntp pour superviser une ou plusieurs machines...

Glossaire

Accuracy
Compare le temps et la fréquence de l'horloge au format national standard. C'est un terme de précision.
Bind
BIND (Berkeley Internet Name Domain) est le serveur DNS le plus utilise sur Internet, spécialement sur les systèmes de type Unix.
Dispersion
C'est le nombre d'erreurs relatives de l'horloge interne du PC avec l'horloge de référence.
DRIFT
Temps réel exprimé en différences de variation de fréquence.
CMOS
L'horloge CMOS (complémentary metal-oxyde semiconductor) travaille en temps réel. C'est un circuit chargé de la synchronisation des signaux du système implanté sur la carte mère.
FQDN
Le Fully Qualified Domain Name est le nom du machine et son domaine, ce qui donne exemple :"alesia.domain.org" avec une adresse IP (exemple) 192.168.1.2.
JITTER
Jitter correspond à une moyenne. Il indique combien de pulsations (PPS) varient de seconde en seconde. Cette valeur peut variée selon la charge du PC. Les bonnes valeurs s'expriment en micro secondes (us), et non en milisecondes (ms), synonyme de manque de précision sinon.
NTP
NTP désigne le protocole Network Time Protocole. Protocole spécialisé dans la diffusion de données horaires pour la mise à l'heure de services intranet sur une réseau.
Offset
C'est la différence entre 2 temps horaires, comparé à l'horloge de référence. Cela représente l'ajustement de l'horloge local et la référence horaire.
Précision
Cela désigne précisément comment peuvent être maintenus la « stabilité » et la « précision » sans intervention du système. C'est aussi la plus petite valeur d'unité de temps que peut lire l'horloge. C'est donc souvent une valeur exprimée en millisecondes.
PPM
Les PPM sont des parties par millions. Cette valeur est également utilisée dans le fichier ntp.drift
PPS
Les PPS sont des pulsations par seconde. Ce système est utilisé par le noyau pour maintenir une référence horaire correcte ou stable.
RAW
C'est un format d'affichage de l'heure dans un format peu lisible. Pour le « Apr 15 2007 9:22:33.667 », le format RAW donne ceci « 1176621752.045844 »
RFC 1305
http://www.frameip.com/rfc/rfc1305.php
Stability
Comment l'horloge maintien une fréquence constante.
SKEW
C'est la différence en fréquence entre 2 horaires. Prend en référence la 1ère dérive au niveau de l'offset.
TA
Trusted Authority ou autorité de confiance, système utilisé pour l'authentification.
UDP
UDP pour « User Datagram Protocol ».Ce protocole permet la transmission de paquets entre deux entités. Contrairement au protocole TCP, il travaille en mode non-connecté : il n'y a pas de moyen de vérifier si tous les paquets envoyés sont bien arrivés à destination et ni dans quel ordre. Ce protocole est utilisé quand il est nécessaire de transmettre des données très rapidement, et où la perte d'une partie de ces données n'a pas grande importance.
UTC :
Extrait du texte concernant UTC disponible sur internet via : fr.wikipedia.org
UTC est une échelle de temps comprise entre le temps atomique international TAI, stable mais déconnecté de la rotation de la Terre et le temps universel TU, directement liée à la rotation de la Terre, et donc instable. Le « coordonné » indique que UTC est en fait identique au TAI (il en a la stabilité et l'exactitude) à un nombre entier de secondes près, ce qui lui permet de coller au TU à 0,9 s près. Coordinated universal time a été abrégé en UTC, au lieu de CUT correspondant à l'acronyme en anglais, ou de TUC correspondant a l'acronyme en français. En effet, si les experts de l'UIT étaient d'accord pour définir une abréviation commune à toutes les langues, ils étaient divisés sur le choix de la langue. Finalement, c'est le compromis UTC, nécessitant un effort des deux parties, qui fut choisi.

Annexe A. Informations disponibles sur Internet.

Annexe B. Exemple de configuration d'un serveur strate 3 sur internet :

C'est mon serveur principal, qui recoit comme client un autre serveur de strate 4, sur mon réseau. Les connexions entre ces 2 serveurs sont controlées par « autokey IFF ».

#
# Fichier de configuration pour ntpd
# Nom de ce fichier   = /etc/ntp/ntp.conf
# Repertoire des cles = /etc/ntp/keys (rep)
#
# ////////////// SERVEURS \\\\\\\\\\\\\\
# Declaration des serveurs classiques
server krishna.via.ecp.fr prefer    # fiable -> 138.195.130.71 - strate 2
server 195.83.66.158 iburst         # IP de ntp.univ-poitiers.fr
#
# Declaration de serveurs qui participent :
peer syrte8.obspm.fr    # 145.238.110.68 
server 3.fr.pool.ntp.org    # XX IP...
#
#
# declaration/activation de mon serveur en strate 3
#  avec auth uniquement pour le peer.
server 127.127.1.0    # local horloge
fudge 127.127.1.0 stratum 3 refid AmT3 autokey
#
# ////////////// DRIFT \\\\\\\\\\\\\\\
# Emplacement du fichier DRIFT
# par defaut :
# driftfile     /var/lib/ntp/ntp.drift
# desormais ici avec les siens :
driftfile /etc/ntp/ntp.drift
#
#///////////// BROADCAST/MANYCAST/MULTICAST \\\\\
# Pas de broadcast ni de crypto ...
#
# broadcast 192.168.1.255 autokey
# broadcastdelay 0.0008
# broadcastclient   # broadcast vis a vis d'un autre reseau(mode client!) 
#
# enable bclient    # Active le broadcast client (pour un serveur)
#
manycastserver 239.1.1.1 autokey maxpoll 12 ttl 1
# ttl 1 = pas de routeur chez moi ...
# manycastclient 239.1.1.1 maxpoll 12 ttl 1 autokey
#
# multicastclient     # Ecoute sur 224.0.1.1
#
#///////////// RESTRICTIONS \\\\\\\\\\\
# Les restrictions d'acces :
# Ajouter vos reseau dans les restrictions ...
# La limitation globales :
restrict default limited noserve kod
#
# pour le serveur qui a X IP :
restrict 80.74.64.1
restrict 80.74.64.2
restrict 81.56.251.175
restrict 81.91.70.122
restrict 82.230.52.122
restrict 82.233.51.156
restrict 87.98.219.90
restrict 88.191.12.200
restrict 195.83.66.158  # univ-poitiers.fr
# pour le serveur :
restrict 138.195.130.71
# pour le serveur :
restrict 145.238.110.68   # syrte
restrict 213.41.185.119   # serveur nerim.net
#
# pour mon horloge locale et service locale
restrict 127.0.0.1 mask 255.0.0.0
# pour mon reseau locale
restrict 192.168.1.2 mask 255.255.255.0 notrust notrap
# pour le reste de mon reseau ... soit plus grand chose, mais bon...
restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer noquery kod version limited notrap
# pour manycast ... en test
restrict 239.1.1.1 nomodify nopeer kod
#
# ////////// GESTION DES CLES \\\\\\\\\\\
#
crypto pw 1234
keysdir /etc/ntp/keys
#
#////////// DIVERS - STATISTIQUES - LOG \\\\\\\\\\
#Active les stats... stats/monitor/ntp = par defaut
# Active l'authentification.
enable auth
#
# Fichier des traces de ntpd
logfile /var/log/ntpd.log
#
# Repertoire contenant les fichiers de stats
statsdir /var/log/ntpstats/
#
# # Statistiques desirees
statistics loopstats peerstats sysstats cryptostats
#
filegen loopstats file loopstats type week enable
filegen peerstats file peerstats type week enable
filegen sysstats file sysstats type week enable
filegen cryptostats file cryptostats type week enable
#
# A activer/modifier si vous avez une source (strate 0) :
# statistics loopstats peerstats clockstats sysstats
# filegen clockstats file clockstats type week enable
# ------------------ FIN ------------------- 

Annexe C. Exemple de configuration pour un client (serveur) strate 4 et internet :

Ce client ou serveur est client de mon autre serveur en strate 3 (serveur). L'authentification par « autokey » est activée entre les 2 serveurs, le reste est classique.

# NOTES: fichier = /etc/ntp/ntp.conf
#
# utilise : autokey vers "serveur" a retirer si pas de crypto
#            + enable auth
# declare en stratum 4
# repertoire des cles = /et/ntp/keys
#
# plusieurs serveurs sont souhaitables et non 1 seul ...
# c'est un exemple ...
server 138.195.130.71 # (krishna.via.ecp.fr)
#
# mon autre serveur «serveur.archi.org (192.168.1.10)»
server serveur iburst autokey
peer serveur prefer autokey prefer
#
# mon horloge + son activation
server 127.127.1.0                      # local horloge
fudge 127.127.1.0 stratum 4 refid AmT4  # activation strate
##
# pour trouver l'IP la plus "proche :
# netselect -s 3 pool.ntp.org
##
#
#driftfile      /var/lib/ntp/ntp.drift
driftfile       /etc/ntp/ntp.drift

# pour le manycast client
#manycastclient 239.1.1.1 autokey version 4

enable auth
#enable bclient

crypto pw client
keysdir /etc/ntp/keys

# ////////// LES RESTRICTIONS \\\\\\\\\
# restrict default ignore
restrict default nomodify
restrict 127.0.0.1
#
# la machine (serveur)...
restrict 192.168.1.10 mask 255.255.255.0 
restrict 192.168.1.0 mask 255.255.255.0 nomodify noquery notrap kod limited
restrict 138.195.130.71   # (krishna.via.ecp.fr)

# emplacement de votre fichier de log
logfile /var/log/ntpd.log
# Repertoire contenant les statistiques d'utilisation
statsdir /var/log/ntpstats/
#
# # Statistiques desirees
statistics loopstats peerstats cryptostats
#
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
# filegen clockstats file clockstats type day enable
filegen cryptostats file cryptostats type day enable
#
# /////////// FIN \\\\\\\\\\