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
seconds
driftfile
[auth
| bclient | calibrate | kernel | monitor | ntp | stats]
/var/log/messages
/var/log/ntpd.log
Liste des tableaux
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
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.
Table des matières
seconds
driftfile
[auth
| bclient | calibrate | kernel | monitor | ntp | stats]
/var/log/messages
/var/log/ntpd.log
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.
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 :
le décalage de temps entre l'horloge interne et le temps de référence (clock Offset),
le temps de transmission des signaux aller/retour (roundtrip),
le nombre d'erreurs relatives de l'horloge interne de l'ordinateur avec l'horloge de référence (Dispersion).
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
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.
strate 0 :
Je ne devrais pas parler de ce niveau, mais il s'agit de la référence proprement dite. Cette référence est un élément GPS, DCF77... C'est cette référence qui donne les données/informations au niveau strate 1. C'est un niveau purement matériel contrairement aux autres.
strate 1 :
C'est le niveau principal et le plus sensible; c'est la référence au sein d'un réseau. Le but de ce niveau est de procurer une référence horaire pour être interrogé par le niveau strate 2. Ce niveau est utilisé également pour des équipements qui demandent une très forte précision, comme les transactions bancaires, contrôles aériens... Dans cette situation, le réseau s'arrête là. L'accès à ce niveau doit être réglementé, les clients doivent être déclarés et parfois authentifiés. Les restrictions s'appliquent généralement aux types de demandes possibles par le protocole NTP. Des serveurs peuvent avoir accès tout de même à beaucoup de paramètres, mais pas un client, théoriquement. Ceci reste valable pour les autres niveaux.
strate 2 :
A partir de ce niveau, les strates ne possèdent plus d'élément matériel de référence (GPS/Radio...). Elles sont tout de même très fiables, et permettent d'être questionnées par des clients; ceci dans le cadre de petits réseaux exclusivement. Par obligation les strates 2 sont plus nombreuses que les strates 1. Ce système ne va que s'amplifier pour une meilleure répartition des flux NTP. L'accès à ce niveau est réglementé et accessible uniquement pour les strates 3, avec ou sans authentification. Compte tenu de leur importance sur un réseau, ces niveaux ne peuvent pas accepter de serveur avec les états temporaire, en test, et pas fiable. Il est question de confiance ici; ceci reste valable également pour les strates 1. C'est aussi pourquoi le chiffrement des liaisons et l'authentification sont régulièrement activées.
strate 3,4 :
Ces niveaux sont présents dans le cadre de réseaux importants. Ils sont chargés de repartir les flux vers les clients, ou d'autres serveurs, ils sont dépendants des niveaux inférieurs. En fonction de l'architecture du réseau NTP, les accès peuvent être restreints aux niveaux inférieurs, authentifiés ou non.
strate 5 :
Toujours dans le cadre des grand réseaux avec encore plus de finesse pour les flux, ce niveau est très adapté pour des requêtes nombreuses de serveurs/clients. A ce niveau les accès sont publiques sans authentification.
...
strate 16 :
C'est un niveau référencé comme non synchronisé...ce n'est surtout pas une référence (!). Il est à signaler qu'un serveur renvoie cette valeur quand il se trouve dans une position désynchronisée. Tout serveur, dès son lancement, retourne cette valeur tant qu'il n'est pas synchronisé (inférieur à 4 minutes environ).
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 :
Disponibilité : plusieurs niveaux de strates permettent de garantir toujours un serveur synchronisé sur le réseau.
Précision : grâce aux algorithmes du protocole NTP.
Universalité : par la diffusion du temps universel, indépendant de la position géographique.
Accessibilité : le protocole est ouvert et accessible à tous, et par la mise en place de serveurs (strates) dédiés ou proches des clients.
Pérennité : la taille des paquets UDP pour NTP est limitée pour l'instant à l'année 2036. Ce qui laisse de la marge pour une évolution du protocole pour dépasser ce cap.
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.
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.
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
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.
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.
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
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 ».
--- 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.
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.
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...
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
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/
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.
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 |
-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 |
-v |
Affiche la version du logiciel. |
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.
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). |
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.
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
clearvars
Les données d'interrogations pour ntpq en mode 6 (NTP) consiste en une liste de termes de la forme variable_name = valeur. La valeur peut être ignorée; ntpq maintient cette liste en mémoire. Cette liste peut être lue (readlist) ou modifiée (writelist). La commande addvars permet d'ajouter une variable et sa valeur. La liste peut être effacée par la commande « clearlist ».
cooked
Utilisé pour le format d'affichage des données afin qu'il soit mieux compris par un humain. (...)
debug
Les paramètres sont « debug [more | less | off] ».
delay
La commande delay milisecondes Spécifie un intervalle de temps à ajouter pour les demandes d'authentifications. Cette commande est obsolète avec les versions récentes de NTP.
host
Sélection un hôte par son nom ou son adresse IP, pour son interrogation pour la prochaine demande.
hostname
Les valeurs yes
ou no
permettent d'afficher ou non les hôtes par leur nom. La valeur par
défaut est yes
.
keyid
Cette commande spécifie le numéro de clé à utiliser pour l'authentification.
ntpversion
Sélectionne ou affiche la version de NTP, les valeurs vont de 1 à 4. La version 2 est choisie par défaut.
passwd
Permet de saisir un mot de passe pour s'authentifier, pour la prochaine commande.
quit
Permet de quitter le programme.
raw
Améliore le format des données pour l'impression (...).
timeout
La commande timeout milisecondes permet de donner un temps d'attente spécifique pour les réponses. La valeur par défaut est de 5000 ms.
associations
Cette commande liste tous les identifiants d'associations, et les statuts. La 1ère colonne est un index interne; la 2ème colonne représente le mode d'association identifié et retourné par le serveur. La 3eme colonne est le statuts mondial au niveau NTP.
clockvars ou cl
Cette commande nécessite que le serveur puissent transmettre ou répondre. Elle s'utilise comme ceci cl assid ou « assid » est un identifiant d'association. Si omis, la valeur « assid » de l'horloge locale sera sélectionnée.
lassociations
Liste les identifiants d'associations et les statuts des serveurs. Cette commande est différente de associations, elle permet d'identifier les serveurs qui possèdent un état « out-of-spec ».
lpassociations
Liste toutes les associations, y compris pour les clients possédant un état « out-of-spec ».
opeers
Vieille commande comparable à peers, avec la référence ID remplacée par l'adresse IP.
Cette commande liste les serveurs de temps
pour chacun d'eux. En prenant l'exemple ci-dessous, il est possible
de lire le nom des 5 serveurs, et leurs adresses IP. Leurs niveaux
de strates (st), le type de relation pour (t) unicast, (b)
broadcast, (m) multicast et (l) local. Le paramètre when
indique depuis combien de secondes date la dernière réception de
paquets. L'intervalle de temps entre les demandes (poll 64s par
défaut). La valeur reach
est un registre en octal sur l'accessibilité des serveurs. La
valeur jitter ne doit pas être égale à
4000, sinon ce serveur est non synchronisé et pose problème. La
valeur delay
représente une estimation sur les délais de transmissions. La
valeur offset
et jitter
(dispersion) représentent les « offset » et la
dispersion en milisecondes.
Le signe + désigne un serveur actif qui participe à la synchronisation.
Le signe * désigne un serveur qui partage (peer), le partage consiste à des transferts possibles autres que de temps; ceci inclut des transferts de variables.
ntpq> peers remote refid st t when poll reach delay offset jitter ============================================================================== goelette.net .INIT. 16 u - 1024 0 0.000 0.000 0.000 +ntp.univ-poitie 213.246.63.72 3 u 42 128 377 37.601 -1.017 75.244 +krishna.via.ecp 157.99.64.66 2 u 89 128 177 35.020 -3.570 96.598 *syrte8.obspm.fr 195.220.94.163 2 u 97 128 377 33.106 -0.082 7.147 LOCAL(0) .AmT3. 3 l 46 64 377 0.000 0.000 0.001
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.
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... »
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.
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é.
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.
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
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.
help
Affiche les commandes selon le contexte, les commandes interactives ou en ligne de commande.
host
Permet de changer de cible en donnant juste après cette commande soit le nom complet (FQDN) ou l'adresse IP du serveur
hostname [yes | no]
Affiche le nom du serveur (FQDN) ou son adresse IP, cette valeur est activée par défaut (yes).
keyid
Cette commande permet de spécifier un numéro de clé précis pour interroger un serveur après, par une autre commande.
quit
Pour quitter le programme.
passwd
Cette commande permet de saisir un mot de passe associé à la clé activée.
timeout
A utiliser si les réponses/délais de transmissions des clients/associés/serveurs sont très longues. La valeur par défaut est à 8000 ms.
listpeers
Liste brièvement toutes les machines qui participent à la synchronisation.
peers
Cette commande est similaire à d'autres commandes. Cette liste reprend déjà des données expliquées par la commande ntpq -p, je ne reviens pas dessus, allez à cette section pour de plus amples explications.
La colonne delay est importante : elle permet de mieux sélectionner diverses sources. Voici les explications des 1er signes/symboles :
ntpdc> peers remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 5 64 377 0.00000 0.000000 0.03065 =krishna.via.ecp 192.168.1.10 2 64 377 0.03369 0.344086 0.03044 =dns.univ-lyon1. 192.168.1.10 2 64 377 0.04015 0.349511 0.03053 *syrte8.obspm.fr 192.168.1.10 2 64 377 0.03445 0.347455 0.03041 =sd1239.sivit.or 192.168.1.10 2 64 377 0.03651 0.349611 0.03043
Tableau 1.4. Explications des symboles pour les relations.
Valeur |
Explication |
---|---|
+ |
Indique une relation symétrique active. |
- |
Indique une relation symétrique passive. |
= |
Indique que le contrôle à distance du serveur ciblé semble être un client, et non un serveur de temps. |
^ |
Indique que le serveur transmet en mode broadcast avec son adresse IP. |
~ |
Indique que le serveur transmet en mode broadcast. |
* |
Indique que le serveur est synchronisé avec le votre... |
dmpeers
C'est une commande très similaire à la précédente à l'exception des premiers signes qui diffèrent. Ces signes apparaissent après la phase de sélection d'algorithme des horloges.
Tableau 1.5. Explications des symboles pour les relations.
Symbole |
Explication |
---|---|
. |
Indique que le serveur a arrêté sa phase de détection de stabilité NTP. |
+ |
Indique que le serveur est synchronisé et possède une association participative active (peer). |
* |
Indique que le serveur est synchronisé. |
Cette commande doit être suivie d'un serveur cible. Elle affiche des statistiques sur cette hôte, et permet de comparer différents serveurs au niveau de la transmission. La valeur bad reference time est rarement à zéro. La valeur bad authentification doit être par contre à zéro.
ntpdc> pstats syrte8.obspm.fr remote host: syrte8.obspm.fr local interface: 192.168.1.10 time last received: 2s time until next send: 62s reachability change: 197s packets sent: 637 packets received: 637 bad authentication: 0 bogus origin: 0 duplicate: 0 bad dispersion: 0 bad reference time: 11 candidate order: 0 flags: config, bclien
kerninfo
Affiche des informations sur la gestion NTP au niveau du noyau, donc uniquement valable pour votre serveur en local. Ces informations sous forme de statistiques sont intéressantes; l'exemple ci-dessous est suffisamment parlant.
ntpdc> kerninfo pll offset: 0 s pll frequency: -36.238 ppm maximum error: 0.289957 s estimated error: 0 s status: 0001 pll pll time constant: 6 precision: 1e-06 s frequency tolerance: 512 ppm
sysstats
Affiche des statistiques générales pour votre serveur NTP. Il est à noter qu'il est possible de lire combien d'accès ont été refusés, les mauvais paquets, et le nombre de mauvaises authentifications.
ntpdc> sysstats time since restart: 41282 time since reset: 41282 packets received: 2596 packets processed: 2571 current version: 2575 previous version: 0 bad version: 0 access denied: 0 bad length or format: 0 bad authentication: 0 rate exceeded: 0
Autres commandes...
Le programme ntpdc possède d'autres commandes plus ou moins utiles, dont une série de commandes pour ajouter, enlever et configurer des serveurs de temps, mais en mémoire uniquement. D'autres commandes très spécifiques, dont les données qui sont restituées qui n'apportent pas forcément une réponse claire, ont été tout simplement omises de mes descriptions Vous pouvez tout de même en avoir connaissance via ce lien http://www.eecis.udel.edu/~mills/ntp/html/ntpdc.html.
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.
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...).
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 |
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)
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.
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.
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
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 (...)
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
Pour le client
ntp-keygen -H -p client
Pour le serveur :
ntp-keygen -T -q 1234
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
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
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.
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 crontab
crontab.
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...
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).
Client / serveur.
C'est le mode le plus rencontré et le plus utilisé. Il utilise les RPC (Remote Procédure Call) pour dialoguer. Dans ce mode le client transmet au serveur une demande de synchronisation; celui ci lui répond. Le client peut mettre à jour son horloge.
Symétrique Actif / Mode passif.
Ce mode est à utiliser sur des bas niveaux de
strates 1,2 et éventuellement 3. Ce mode permet, entre 2 serveurs,
de permettre l'entraide vers un serveur exclusivement. Si le serveur
demandant le mode peer
venait à perdre sa référence, il peut faire appel au serveur
déclaré en « peer », celui ci participera à distance
à maintenir la synchronisation; comme il le fait pour lui-même. Le
mode dans ce cas devient actif automatiquement. Compte tenu des
modifications possibles sur votre système horaire, il est fortement
conseiller d'authentifier les connexions vers le serveur « peer ».
Ce mode est aussi utilisé pour faire un serveur NTP de sauvegarde.
Broadcast | Multicast | Manycast.
Tous ces modes nécessitent ce support sur
votre réseau ou sous réseau. Vous pouvez vous référer à la
section activation
Broadcast/Manycast/Multicast pour l'activation de ces
paramètres, dans le fichier ntp.conf
.
Broadcast : le mode broadcast permet de joindre d'autres serveurs et une multitude de clients d'un seul coup. A noter qu'un serveur ne peut répondre au client en broadcast que pour une raison évidente. Dans ce mode, le serveur envoie périodiquement des références de temps en broadcast : les clients peuvent se mettre à jour. Cette diffusion est fiable mais ne procure pas une très forte precision horaire. En effet, les temps de transmission sur le réseau ne sont pas pris en compte...
Manycast : c'est un mode de découverte du réseau dans la mesure ou le, ou les serveurs envoient périodiquement des messages multicast. Les clients récupèrent les temps de propagation des différents paquets, et choisissent le mode client/serveur pour leurs mises à jour vers le serveur le plus proche.
Multicast : les clients envoient périodiquement des paquets en multicast, les serveurs également en multicast. Les clients utilisent ensuite le mode client/serveur pour se synchroniser. La plage d’adresses à utiliser obligatoirement est comprise entre 224.0.0.0 et 239.255.255.255.
L'option « burst » est à activer lorsque le serveur est joignable. Elle active l'envoi de 8 paquets UDP (au lieu d'un seul comme activé par défaut) espacés de 16 secondes entre le 1er et le second, puis de 2 secondes pour le reste, et améliore la stabilité en encombrant un peu plus le réseau...
L'option « iburst » est faite pour
synchroniser plus rapidement la machine/serveur dès son lancement.
Pour se protéger des accès trop fréquents vers lui-même, et
envers les autres serveurs, ntpd
au lancement, initialise des requêtes aléatoires dans un temps
supérieur à 16 secondes. Pour réduire ces espaces temps (environ
4 minutes), et pour permettre la synchronisation de votre serveur ,
il faut ajouter l'option iburst
vers un serveur choisi. Les 2 options peuvent être utilisées
ensembles ou indépendamment. L'option iburst
ne peut être que conseillée : elle permet de redonner un service
NTP actif le plus rapidement possible...
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.
Ce paramètre est à inclure dans le fichier
ntp.conf
.
Il prend comme base de référence, des serveurs de strate N-1. Il
faut souligner également que cette valeur peut s'appliquer aux
sources de référence comme le GPS. Cette source est à préférer
effectivement à son homologue en DCF 77... Les commandes sont
server keyword prefer
avec le serveur passé en option (keyword).
Ceci donne en exemple : server ntplocal.example.com prefer. En clair, vous estimez que ce serveur est stable et proche, et qu'il sert de référence en priorité.
Dans un réseau NTP, ne pas choisir un serveur SNTP, incompatible en précision; c'est aussi valable dans le fichier de configuration. Il ne peut pas y avoir plusieurs sources en prefer pour ntpd. A noter tout de même, cette option doit être activée aussi, lors de la mise en place d'un serveur en secours.
C'est comparable à l'option suivante; elle
peut intervenir sur des strates de niveaux différents. Ceci rentre
dans le cadre du renforcement du réseau, en prenant également en
compte les éventuels problèmes de réseaux. En général, le peer
est activé sur des strates 2 ou 3, et souvent de même niveau.
Ceci donne en exemple : peer ntplocal.example.com prefer, avec en plus l'option prefer. Si la commande « peer » est activée entre 2 serveurs, la connexion devient persistante, active et symétrique.
Le mode peer intervient uniquement dans un sens, et dans le sens du serveur ciblé. C'est le mode symétrique actif. De l'autre coté, c'est le mode symétrique passif.
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.
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).
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.
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...
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 #
server 127.127.t.u [prefer]
[mode int] [minpoll int] [maxpoll int]
Voir cette Section 12.3, « Les relations spécifiques entres serveurs. » pour l'utilisation de l'option « prefer ».
mode int
Cette valeur doit être donnée par votre matériel (documentation).
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 est un
chiffre; la valeur 6 représente 64 secondes, 10 pour 17,1
minutes... Par défaut les 2 valeurs sont à 6
ou l'équivalent de 64 secondes.
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.
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 ) :
Non discipline horloge locale. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver1.html.
Trak 8820 GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver2.html.
PSTI/Traconex 1020 WWV/WWVH Receive. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver3.html.
Spectracom WWVB and GPS Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver4.html.
TrueTime GPS/GOES/OMEGA Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver5.html.
IRIG Audio Decoder. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html.
Radio CHU Audio Demodulator/Decoder. Pour plus de renseignements : x http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver7.html.
Generic Reference Driver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html.
Magnavox MX4200 GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver9.html.
Austron 2200A/2201A GPS Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver10.html.
Arbiter 1088A/B GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver11.html.
KSI/Odetics TPRO/S IRIG Interface. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver12.html.
Leitch CSD 5300 MasterClock Controller
EES M201 MSF Receiver
reserved
Bancomm GPS/IRIG Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver16.html.
Datum Precision Time System
Automated Computer Time Service. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver18.html.
Heath WWV/WWVH Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver19.html.
Type 20 Generic NMEA GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html.
TrueTime GPS-VME Interface
PPS Clock Discipline. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html.
reserved
reserved
reserved
Hewlett Packard 58503A GPS Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver26.html.
Arcron MSF Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver27.html.
Shared Memory Driver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html.
Trimble Navigation Palisade GPS. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html.
Motorola UT Oncore GPS. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver30.html.
Rockwell Jupiter GPS. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver31.html.
Chrono-log K-series WWVB receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver32.html.
Dumb Clock. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver33.html.
Ultralink WWVB Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver34.html.
Conrad Parallel Port Radio Clock. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver35.html.
Radio WWV/H Audio Demodulator/Decoder. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver36.html.
Forum Graphic GPS Dating station. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver37.html.
hopf GPS/DCF77 6021/komp for Serial Line. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver38.html.
hopf GPS/DCF77 6039 for PCI-Bus. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver39.html.
JJY Receivers. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver40.html.
TrueTime 560 IRIG-B Decoder
Zyfer GPStarplus Receiver. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver42.html.
RIPE NCC interface for Trimble Palisade. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver43.html.
NeoClock4X - DCF77 / TDF serial line. Pour plus de renseignements : http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver44.html.
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.
time1
,
et time2
Doivent être définies en connaissant bien le
module source. time1
spécifie une valeur à additionner pour la calibration et
l'ajustement. Les valeurs time1
et time2
doivent être
fournies avec votre matériel. Sinon la description de votre
matériel doit pouvoir vous aider à paramétrer ces 2 valeurs.
Par défaut, ntpd
prend la strate N+1 automatiquement pour votre serveur, cette valeur
est basée sur votre configuration (ntp.conf). Elle peut tout de
même être imposée par cette définition, où le chiffre qui suit,
représente le numéro de strate. Dans la situation ou vous avez
relié un récepteur à votre machine, la bonne valeur pour l'option
stratum
est donc 0. C'est votre horloge basée sur votre noyau qui va
diffuser le protocole NTP, et donc dépend de ce niveau 0, et du
savant calcul N+1 pour la déclaration de votre serveur après.
Beaucoup de matériels actives eux même cette valeur, mais il est possible de saisir 4 lettres/chiffres afin d'identifier son serveur. Si le matériel ou les paramètres ne fournissent pas cette donnée, l'adresse IP est prise.
mode int
Cette valeur définit le moyen de communication avec ce matériel. Ces paramètres doivent vous être fournies par votre matériel...
Ces paramètres doivent également être fournis par votre matériel (votre documentation). En générale, le flag 4 est utilisé pour les enregistrements des historiques de l'horloge.
Comme déjà mentionné, ces activations nécessitent des plages d'adresses spécifiques sur votre réseau.
Pour activer le broadcast
il suffit d'inscrire cette ligne dans le fichier ntp.conf
broadcast
suivie de l'adresse IP. Voici un exemple :
broadcast 160.120.12.255
Voici la solution du serveur qui diffuse en
broadcast, pour inverser les rôles, le serveur écoute les messages
broadcast des clients; il suffit d'activer le paramètre enable
bclient
sur le serveur. Pour
activer cette diffusion sur un client, il suffit d'activer cette
option : broadcastclient
.
Autre option pour le broadcast :
broadcastdelay 0.000x
.
La lettre « x » est une valeur en seconde, comprise en
0,0003 et 0,0008. La valeur par défaut est calibrée à 0,0004
seconde.
Pour activer l'authentification par autokey,
il suffit de rajouter le mot autokey
.
Voici un exemple :
broadcast 160.110.11.255 autokey
Il est possible d'intervenir sur la portée des
paquets en broadcast par l'activation de l'option ttl
.
Cette option, également à ajouter sur la ligne broadcast
,
doit prendre une valeur adaptée à sa portée sur le réseau
souhaité. Une valeur de 3 permet de traverser 2 routeurs... Vous
pouvez également activer la ou les options minpoll
et maxpoll
.
Référez vous à cette section pour de plus amples explications.
Pour activer le manycast :
Il suffit de rajouter une ou plusieurs lignes comme celles-ci :
manycastclient 239.1.1.1 autokey # Accepte les clients en manycast manycastserver 239.1.1.1 autokey maxpoll 12 ttl 7 # Le serveur diffuse en manycast
Les options minpoll|maxpoll
et ttl
peuvent aussi être utiles pour optimiser votre réseau.
Référez vous à cette section
pour de plus amples renseignements sur l'utilisation de
minpoll/maxpoll
.
Pour activer le multicast :
Il suffit d'ajouter cette ligne :
multicastclient # Ecoute sur 224.0.1.1
Les restrictions sont présentes pour sécuriser le réseau; elles interviennent sur plusieurs niveaux.
Les différentes possibilités possibles sont :
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.
address
[mask mask
]
[flag
]
[...]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 :
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.. |
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. |
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.
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.
[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 |
kernel |
Active une option de précision de l'horloge pour le noyau,
lors d'un appel de la fonction |
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. |
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 .
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 :
=
Donne le label ou le titre pour les traces dans syslog.
+
Ajoute une classe en historique.
-
Supprime/retire une classe en historique
Les classes d'événements sont :
clock
Concerne une source NTP (strate 0).
peer
Concerne les relations entre serveurs.
sys
Concerne le système lui-même.
sync
Concerne la synchronisation.
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
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.
[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.
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.
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.
dispersion
Cet argument modifie le taux de « dispersion »,
réglé par défaut à 0,000015
s/s.
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.
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.
allan
Cette valeur modifie l'interception « Allan » pour les horloges PLL.FLL. Par défaut est réglé à 1500 secondes.
huffpuff
C'est un système expérimental de filtre
huff-n'-puff
...
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.
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/
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
clockstats
Active les statistiques des pilotes d'horloge. Chaque mise à jour fait l'objet d'une ligne nouvelle. Les données sont présentées sous cette forme :
49213 525.624 127.127.4.1 93 226 00:08:29.606 D
A noter que cet exemple est extrait de la documentation, je ne possède pas de source...
La 1ère valeur désigne la date au format Julian, suivie des secondes écoulées depuis minuit. La valeur suivante indique l'adresse IP de l'horloge en question. Elle est suivie des données horaires reçues par l'horloge désignée.
cryptostats
Cette option n'est à activer que lors de l'utilisation de l'authentification. Les messages sont identiques à « clockstats », après l'adresse IP, le message lié à l'authentification est affiché.
loopstats
Active l'enregistrement de statistiques sur l'horloge locale. Chaque ligne fait l'objet d'une mise à jour de l'horloge. Les données sont sous la forme :
54203 41910.207 0.036698000 500.000 0.012974681 0.397489 6
Elles représentent les informations suivantes : Date au format Julian, les secondes après minuit, le temps en "offsets" (secondes), la fréquence en "offset" ou en PPM, le RMS jitter en secondes, et la dérive exprimée en "Allan" de l'horloge.
peerstats
Active les statistiques sur toutes les participations actives (peer) depuis votre serveur. Les données sont présentées sous cette forme :
54203 123.236 127.127.1.0 9024 0.000000000 0.000000000 0.000000000 0.000000954
La 1ère valeur exprime la date au format Julian, suivi des secondes écoulées depuis minuit. Ensuite l'adresse IP, suivie de champ « offset », « delay », « dispersion » et RMS jitter en secondes.
rawstats
Présente les données horaires au format RAW...
sysstats
Active l'enregistrement toutes les heures de statistiques pour ntpd. Ces informations sont présentées sous cette forme :
54204 11487.553 8 224 224 224 0 0 0 0 0 0
.
Tableau 1.9. Explications des valeurs.
Valeur |
Explication |
---|---|
54204 |
Date au format Julian. |
11487.553 |
Secondes depuis minuit. |
8 |
Nombre d'heures écoulées depuis le dernier reboot. |
224 |
Paquets reçus |
224 |
Nombre de paquets reçus en réponse à une précédente demande. |
224 |
Nombre de paquets en NTP V4 (selon votre serveur). |
0 |
Nombre de paquets en NTP V3. |
0 |
Nombre de paquets en mauvaise version. |
0 |
Nombre de paquets dont l'accès est refusé. |
0 |
Nombre de paquets mal formé. |
0 |
Nombre de paquets non authentifié. |
0 |
Nombre de paquets dont le taux est dépassé. |
Ces statistiques sont particulièrement intéressantes, elles
permettent de connaître comment travaille votre serveur vis à vis
des clients.
timingstats
Cette option est seulement activable si vous
avez compilé ntpd
avec l'option --enable-debug-time
.
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
name
Doit être une des options de « statistics » exposés dans cette section.
file filename
Concerne le nommage des fichiers qui seront crées.
type typename
Représente la fréquence de rotation du
fichier, les valeurs possibles sont : day
| week | month | year
.
Il existe aussi la valeur age
qui est semblable à day
mais comporte une lettre suivie de données horaires.
link | nolink
Par défaut, « ntpd » travaille sur les fichiers sans extension, ce qui permet de trouver facilement et rapidement les fichiers en cours. Mais il est possible de faire créer des liens vers ces fichiers.
enable | disable
Active ou arrête les statistiques données. Ceci peut paraître bizarre dans le fichier « ntp.conf », mais il est possible de modifier ces valeurs par commande depuis « ntpq ».
/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
/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
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.
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.
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...
ntp.drift
Le site NTP.ORG : http://www.ntp.org/.
Le site de NTP Université du Delaware concernant NTP : http://www.eecis.udel.edu/~mills/ntp/html/index.html.
Le site de l'institut national de technologie : http://tf.nist.gov/timefreq/index.html
Le site de FAQ pour NTP, bonnes sources d'informations : http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-a-faq.htm.
Le site de FAQ NTP : https://lists.ntp.isc.org/mailman/listinfo/questions
OpenNTP - C'est une autre version initialement pour FreeBSD, désormais pour d'autres systèmes comme Gnu/linux. Hélas, ce projet semble léger comparé au projet NTP. http://www.openntpd.org/
Le système Autokey : stime-0001.pdf
Temps universel coordonné : http://fr.wikipedia.org/wiki/Temps_universel_coordonn%C3%A9
Le protocole TP : http://fr.wikipedia.org/wiki/Time_protocol
Les sources pour NTP ( prendre la version stable ) : http://ntp.isc.org/rss/releases.xml
Le fichier leap-seconds
disponible sur ce site de référence :
ftp://time.nist.gov/pub/leap-seconds.3331497600
Tout sur le DCF 77 : http://www.eecis.udel.edu/%7emills/ntp/dcf77.html
Le HowTo NTP pour la distribution Gentoo™ :http://gentoo-wiki.com/HOWTO_NTP
Pour configurer un client windows (en SNTP apparemment) :http://support.microsoft.com/?kbid=224799
Pour configurer un serveur NTP (en fait un serveur SNTP !) :http://support.microsoft.com/kb/216734/EN-US/
Il s'agit bien du protocole SNTP, qui reste tout de même fiable à la seconde près (!)... voici le texte récupéré sur le site Microsoft :
Administrators can configure the Windows Time service on the PDC operations master at the root of the forest to recognize an external Simple Network Time Protocol (SNTP) time server as authoritative. For example, you can use the Microsoft time server (time.windows.com) as the external SNTP time server. To configure Windows Time service to use an external SNTP time server...
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 -------------------
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 \\\\\\\\\\