Copyright © 2009 Laurent Archambault. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 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". http://www.gnu.org/licenses/fdl.html
Historique des versions | |
---|---|
Version 1.0 | 05 juin 2010 |
Publication du document | |
Version 1.1 | 5 juillet 2010 |
Modification mineure. |
Table des matières
Table des matières
La supervision, et le contrôle d'un ou plusieurs serveurs NTP n'est pas une tâche facile. En effet, le serveur NTP peut être interrogé à distance, et les données qui sont retournées sont très nombreuses. Elles sont souvent peu compréhensibles facilement et rapidement. Le but de cette application est de présenter de façon la plus claire possible les données les plus pertinentes pour le NTP.
Il est important à mes yeux, de bien différencier les termes de superviser
et contrôler (monitorer)
.
Au niveau NTP, la supervision intervient pour connaître si le serveur fonctionne, oui ou non.
En revanche, pour le contrôle d'un serveur, cette action demande beaucoup plus de données à analyser, sans parler des compétences.
Exemple les valeurs pour les offset, le jitter, la frequency, sont-elles correctes ? Il en va de même avec les
statuts de connexion, l'authentification...
Cette application cible le contrôle rapide et facile, avec néanmoins une possibilité de supervision de serveurs, mais réduite dans sa fonctionnalité. Le but de cette application n'est pas là, il existe des logiciels excellents pour çà comme Nagios...etc.
Comme vous pourrez le constater par la suite, il est souvent question d'authentification, d'Autokey, de clé... Cette application n'est pas forcément dédiée à la gestion d'un gros parc NTP, comme on peut en trouver sur internet. Elle est dédiée à un réseau plus ou moins important, lequel se protège des attaques éventuelles avec une authentification des connexions par sécurité.
Son principe est assez simple: trois scripts en langage Perl se lancent à intervalles réguliers. Ils génèrent des séries d'images et/ou des fichiers. Ensuite l'interface graphique en langage PHP5 récupère ses « fichiers » pour les présenter. Cette interface propose d'autres fonctionnalités, elles sont toutes détaillées dans ce document.
Toutes les données, les exemples, sont basés sur le système d'exploitation Gnu/Linux (Gentoo en particulier).
Ce document s'adresse à des administrateurs possédant déjà de bonnes notions sur les serveurs de temps, en particulier avec le serveur NTP.
Avertissement | |
---|---|
NTP peut être compilé avec le support SNMP spécifique pour une supervision. Je n'ai pas essayé cette solution, et je ne pense pas qu'elle soit souvent utilisée, néanmoins c'est possible. A noter que la version logiciel de NTP est basée sur des versions en développement. Pour information, voici ma version de NTP : 4.2.7p33. |
Cette licence s'applique aux scripts, mais aussi aux pages PHP (NTPGraffe), bref à tout le projet en réalité sans limite. Seul le lien en anglais est valide au niveau juridique, le voici : GPL3. Il existe aussi ce guide condensé (GB) : quick-guide-gplv3
(extrait de Wikipedia FR). L'objectif de la licence GNU GPL, selon ses créateurs, est de garantir à l'utilisateur les droits suivants (appelés libertés) sur un programme informatique :
1. La liberté d'exécuter le logiciel, pour n'importe quel usage ;
2. La liberté d'étudier le fonctionnement d'un programme et de l'adapter à ses besoins, ce qui passe par l'accès aux codes sources ;
3. La liberté de redistribuer des copies ;
4. La liberté de rendre publiques des versions modifiées pour en faire bénéficier la communauté.
Table des matières
Les nouvelles versions de NTP ne fournissent plus les paramètres noise et stability. Le script en Perl chargé de récupérer ces données est adapté, l'interface web également s'adapte à la présence ou non de ces valeurs. En clair, cette application est compatible avec les anciennes ou les nouvelles versions de NTP.
Si vous devez utiliser une authentification pour NTP, il faut impérativement installer Openssl, et ce, avant la compilation de NTP.
Les scripts en Perl utilisent seulement des dépendances liées à RRDTool. Ces dépendances s'installent très facilement.
Une version « à jour (récente) » de Perl doit suffire. Voici le nom de la librairie Perl-rrdtool à utiliser : librrds-perl
.
Il faut également installer le logiciel hautement connu RRDTool.
En ce qui concerne PHP, il s'agit de la version 5 ou ultérieure. A ce titre, cette application signe « mon retour » vers ce magnifique langage. Les puristes repéreront probablement des erreurs d'encodage. Ne pas hésiter à m'envoyer vos remarques, vos corrections.
Table des matières
Compte tenu des multiples distributions Gnu/Linux actuelles, il est difficile pour moi de proposer un « package » pour chaque. Le fichier à décompresser doit suffire amplement, et reste compatible avec toutes les distributions.
En prenant le fichier compressé (tgz), il suffit de le décompresser vers un répertoire accessible par votre serveur WEB. Voici la commande à faire, donnée à titre d'exemple :
tar -xvzpf ntpgraffe-2010061500.tgz -C /var/www/
Ce fichier compressé, comprend la totalité des fichiers nécessaires au bon fonctionnement de NTPGraffe, et plusieurs répertoires sont créés à ce titre.
Les répertoires énumérés ci-dessous restent explicites.
(votre répertoire accessible par le serveur HTTP)
/ntpgraffe/
/scripts
/includes
/images
/doc
ntpgraffe
Ce répertoire contient divers fichiers en PHP, en particulier des fichiers de configurations à paramétrer : (ntpgraffe.xml et ntpgraffe-key.xml).
Est aussi présent, le fichier de redirection du HTML vers le PHP, ce fichier s'appelle index.html
. Il suffit de remplacer localhost
par la valeur (URL) de votre site. Ce fichier est optionnel, et peut être effacé sans problème.
scripts
Ce répertoire contient les 3 scripts en Perl, et selon votre configuration les images générées, et divers fichiers d'extraction de données en XML. Lors de l'installation, il ne contient que 3 fichiers (scripts).
includes
Ce répertoire contient des fichiers de type include
. Ces fichiers servent à l'application
WEB.
images
Ce répertoire contient les images utilisées par l'application WEB.
doc
C'est le répertoire qui contient toute la documentation, images y comprises. Ce répertoire peut-être supprimé à tout moment.
Table des matières
Les diverses versions de « ntp » sont disponibles ici : NTP Download. Il est conseillé pour un serveur de production, de se baser sur la version « RELEASE CONDIDATE ».
Le script qui suit est donné à titre d'exemple, vous pouvez largement l'adapter à vos besoins.
#! /bin/sh
make clean dep ;
./configure \
--prefix=/usr \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--datadir=/usr/share \
--sysconfdir=/etc/ \
--localstatedir=/var \
--with-libtool \
--disable-linux-caps \
--enable-debugging ;
make && make install
A signaler, l'activation de l'option de débogage, également le programme ntpd est installé dans le répertoire
/usr/bin
. Ce n'est pas forcément le meilleur choix, j'aurais préféré le répertoire /usr/sbin
.
Table des matières
Ce chapitre ne parle que des paramètres génériques pour les 3 scripts; un détail plus complet est fait dans la suite du document.
Note | |
---|---|
Lors du 1er lancement des scripts ntp-graphe.pl et ntp-udp.pl, leurs premières actions est de créer la « base de données » RRDtool, et c'est tout. C'est ce type de fichier qui garde en mémoire les données sur une grande période, son effacement peut avoir des conséquences irréversibles. La taille de ce fichier est fixe. |
Les 2 scripts ntp-graphe.pl et ntp-udp.pl, sont basés sur le même moteur. Seules les extractions et les créations graphiques sont différentes. Le paramétrage initial est identique et à faire pour les 2 scripts (!), voici comment faire :
La présence et le choix de ces deux paramètres sont à mes yeux discutables. Néanmoins, ceci permet d'installer les scripts dans un répertoire différent, de l'endroit où seront stockées les images ou autres fichiers. Éditez chaque fichier, puis paramétrez les 2 lignes suivantes :
# Le répertoire ou vont se trouver le fichier RRD(RRDtool) et les fichier générés (erreurs ou statuts) my $reptravail = "/var/www/localhost/htdocs/ntpgraffe/scripts/" ; # Le répertoire ou seront placées les images générées... my $repdiff = "/var/www/localhost/htdocs/ntpgraffe/scripts/" ;
Le script ntp-peers.pl
est donc le seul à ne posséder que le répertoire $reptravail
, celui-ci
est chargé de stocker le fichier des relations NTP.
Avertissement | |
---|---|
Ceci est valable pour tous les scripts : si celui-ci est installé dans le répertoire où sont exploités les images, ou les fichiers, les 2 variables (ou 1) peuvent rester vides. Par contre, cette manière de procéder ne fonctionne pas lors du déclenchement via la « crontab ». En clair, il est préférable de renseigner ses variables correctement. |
Une fois de plus, ils ne concernent que les scripts suivants : ntp-graphe.pl et ntp-udp.pl. Il est possible de régler quatre données temporelles différentes ; voici les paramètres donnés « par défaut » ou conseillés. Ce tableau comprend 2 valeurs par ligne, la 1ere concerne le titre des graphiques; la 2ème valeur concerne la durée pour RRDTool. Cette dernière valeur est plus délicate, et testée par RRDTool, contrairement à la 1ere.
my @typegraph = ( { titre => '24H', decal => '24h',}, { titre => 'Semaine', decal => '7d' ,}, { titre => 'Mois', decal => '30d' ,}, { titre => '6mois', decal => '180d' ,}, );
Avertissement | |
---|---|
Attention à la donnée de type |
Ne concerne que les fichiers ntp-graphe.pl et ntp-udp.pl. Chaque script possède un tableau similaire à l'exemple ci-dessous; il est composé de plusieurs valeurs. Ce tableau ne mérite pas d'explications détaillées, le voici :
my %color = ( a => "3CE63C", #vert b => "FFCC00", #orange c => "FFFED7", #bleu clair d => "A800FF", #bleu fonce e => "0008FF", #bleu f => "038E00", #vert fonce g => "FF0000", #rouge h => "FFC4C4", #rouge clair i => "010101", #noir j => "8E8E8E", #Fond gris k => "000000", #Trais noirs l => "E5F6FF", #contour bleue offset => "feffe4", # fond jaune C jitter => "e8e4ff", # fond bleu/violet C noise => "D4FFE5", # fond vert C stabilite => "FFEFC5", # fond orange C freq => "C6C6C6" # fonc gris C );
Ses dimensions sont définies avec les valeurs suivantes. Néanmoins RRDTool adapte de lui-même ces valeurs ou au moins une valeur afin de créer une belle image proportionnée.
my $xpts = "420"; # larg 420 my $ypts = "151"; # hauteur 151
Comme déjà écrit, tous ces graphiques profitent du même moteur, en conséquence il existe des points communs. Il s'agit de la partie basse qui ne contient que des données. Ce chapitre va tenter de vous expliquer ces diverses informations, qui méritent presque toutes une attention particulière.
Cette partie vous est présentée en image, chaque numéro correspond à une ligne :
Cette ligne indique la valeur actuelle et la valeur maximale positive, pour la période sélectionnée (24h, 7 jours...).
Cette ligne est similaire : elle indique les valeurs pour la moyenne et le maximal négatif pour la période sélectionnée.
Sur cette ligne est présentée la version du logiciel NTP utilisée. Ceci peut-être une option intéressante lors de supervision de réseau, à propos des mises à jour. Ensuite la version du processeur est affichée, suivie du système d'exploitation avec ou sans son numéro de version, en ce qui concerne le noyau.
Cette ligne affiche deux paramètres identiques, le premier indique quand votre serveur a fait sa mise à jour. Pour éviter une ligne encore plus longue, le mois n'est pas inscrit volontairement. Le deuxième paramètre indique les paramètres temporels à l'instant « T ».
Cette ligne donne des informations uniquement sur autokey
, si cette option est activée.
La 1ere valeur donne le nom du groupe et des paramètres
d'identification autokey
et le drapeau : 0x5
. Le décodage de ce drapeau est possible par ce tableau (en bas) : flash.
Le 2eme paramètre (plutôt le 3ème) correspond au drapeau qui identifie le type d'autokey
utilisé.
Dans l'exemple donné, il faut retirer la valeur 0x41
, qui correspond au type d'encodage (RSA-SHA1). Les valeurs suivantes doivent être
interprétées grâce à ce lien : flash. Ce drapeau ne reflète pas complètement l'usage de l'authentification pour une
connexion. Voici comment obtenir plus finement ce drapeau envers une connexion très précise. Cette possibilité sera peut-être accessible
dans NTPGraffe V2...à suivre.
ntpq> as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 49537 8011 yes no none reject mobilize 1
2 49538 966a yes yes none sys.peer sys_peer 6
3 49539 9044 yes yes none reject reachable 4
4 49540 9044 yes yes none reject reachable 4
5 49541 e015 yes no ok reject restart 1
6 49542 e015 yes no ok reject restart 1
7 49543 906a yes yes none reject sys_peer 6
ntpq> pstatus 49541
associd=49541 status=e015 conf, authenb, auth, sel_reject, 1 event, restart,
srcadr=serveur.archi.amt, srcport=123, dstadr=192.168.1.90, dstport=123,
leap=00, stratum=2, precision=-21, rootdelay=0.000, rootdisp=11.703,
refid=LOCAL(0), reftime=cfb301c6.44a4a789 Fri, Jun 4 2010 6:38:30.268,
rec=cfb301fd.6e673a21 Fri, Jun 4 2010 6:39:25.431, reach=000,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=508,
flash=1480 pkt_autokey, peer_dist, peer_unreach, keyid=700893383,
offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000,
xleave=0.037,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0,
host="GR1", flags=0x415121, signature="sha1WithRSAEncryption"
Pour terminer cette ligne, les paramètres temporels d'expiration du certificat sont présentés.
Cette ligne présente, presque une fois de plus le groupe (GR1), puis par quel moyen est synchronisé ce serveur. Dans la majorité des situations,
c'est par le protocole NTP
, mais une STRATE peut afficher PPS ou GPS...
et pour finir cette ligne, la présentation du dernier
évènement pour ce serveur.
Cette ligne comporte les données temporelles lors du lancement du script. Une surcharge ou un dysfonctionnement serait visible à ce niveau par un décalage de temps (minutes).
Le premier des trois scripts est à mon avis le plus important. Il extrait via la commande ntpq -c rv,
au maximum 19 informations différentes. Après une mise en forme en interne, celui-ci utilise RRDTool pour créer au moins une image.
Comme déjà mentionné, avec les nouvelles versions de NTP, les paramètres noise et stability
ne sont plus
présents. Pour éviter des données vides ou nulles, une option est disponible lors du lancement. A noter que cette option n'est pas testée
au niveau du mot ou même des caractères, mais uniquement sur la présence ou non d'une 2ème option ou valeur. Voici comment utiliser manuellement ce script :
Pour les versions récentes de ntpd : ./ntp-graphe.pl localhost new, similaire : ./ntp-graphe.pl localhost old
Pour les versions anciennes de ntpd : ./ntp-graphe.pl localhost
Avertissement | |
---|---|
Ce script est programmé pour être déclenché automatiquement toutes les 5 minutes via la |
Ce script met à jour, toutes les 5 minutes, un seul type de graphique, à multiplier par les offset, le jitter, puis pour finir avec la frequency. Selon la version, il faut même ajouter les images pour les valeurs noise et stability. A chaque heure pleine (entre 0 et 4 minutes précisement), le script met à jour la totalité des images. Cette action est volontaire, et permet de ne pas surcharger la machine hôte. On a donc à utiliser 4 graphiques à multiplier par les données de type « offset, jitter ... »
Rien de bien spécial à surveiller à ce niveau, au bout de plusieurs heures votre serveur doit se stabiliser. Les courbes doivent être
plus ou moins ondulées, avec des valeurs minimales et maximales non excessives. La stabilité d'un serveur doit se voir avec une courbe pour les offset
qui évolue proche du zéro. Les autres graphiques restent néanmoins importants.
Note | |
---|---|
Bien remarquer que les courbes présentées reflètent surtout au début un serveur relativement instable; c'est le résultats d'essais multiples. |
Ce script en Perl extrait les données au travers de la commande ntpq -c sysstats. Cette commande renvoie de nombreux paramètres sur le trafic en UDP. Tous les paramètres ne sont pas exploités, afin de ne pas surcharger le graphique. Voici la liste des paramètres reportés, l'unité de comptage est le paquet UDP : reçu, traité, non traité, rejeté, problème de format(NTP), problème d'authentification et hors délais. Uniquement les 5 premières valeurs sont représentées dans le graphique, toujours pour éviter les surcharges. Il faut surveiller au lancement du serveur NTP que les paquets rejetés, refusés...ne progressent pas rapidement. ./ntp-udp.pl localhost
Avertissement | |
---|---|
Ce script est programmé pour être déclenché automatiquement toutes les 10 minutes via la |
Hélas, mon seul regret pour le projet NTP, c'est le changement d'un paramètre ou plus, sans trop l'annoncer, et encore moins expliquer le pourquoi. Donc les nouvelles versions de ntpq diffusent des données différentes. Voici un exemple concret avec la avec la commande ntpq -c sysstats :
Ancienne version :
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
La nouvelle version.
ntpq ntpq> sysstats uptime: 12973 sysstats reset: 2173 packets received: 136 current version: 92 older version: 0 bad length or format: 0 authentication failed: 0 declined: 0 restricted: 0 rate limited: 0 KoD responses: 0 processed for time: 57
Je vous laisse comparer... et hélas mon script ne prend pas en charge l'ancienne, mais la nouvelle version. Ceci est tout de même techniquement possible, mais je préfère miser sur l'avenir. En conclusion : le script ne prend en compte que la nouvelle version, en espérant que les développeurs ne changent pas régulièrement.
Note | |
---|---|
Je vais laisser dans le répertoire « doc », le fichier |
Ce script utilise lui aussi Perl pour extraire des données au travers de la commande ntpq -c peers
.
Il existe une autre commande très similaire et possible ntpq -c lpeers
. Personnellement, je préfère la 1ere commande.
Les paramètres peuvent être nombreux et variés, ils servent à connaître et contrôler comment le serveur « ciblé » récupère ces
informations pour sa stabilité. Pour information, NTP limite cette sortie à 600 lignes, çà devrait suffire. Cette commande demande parfois
plusieurs secondes pour la restitution complète.
Ce script demande à être déclenché à un intervalle régulier, comme les deux autres. Cette valeur est libre ou non imposée, à vous de choisir cette période. Évitez des valeurs très courtes inférieures à 5 minutes qui surchargent le serveur probablement inutilement.
Par défaut, ce script renvoie au travers de la commande ntpq une résolution des adresses IP pour les serveurs. C'est pratique; néanmoins il est possible de supprimer cette action en ajoutant l'option -n dans le script.
Ce script est le seul à ne générer aucune image, mais un fichier XML, exemple : peers-localhost.xml, dont une copie est listée après. Ce fichier est effacé (si existant) si la connexion au réseau est impossible. Voilà la solution retenue pour connaitre si un serveur est présent sur le réseau. Cette action a été rendue nécessaire pour NTPGraffe, afin qu'il n'affiche pas un tableau sans donnée.
Note | |
---|---|
Le 1er bloc semble répéter les balises, c'est effectivement le cas pour cet exemple. En réalité le script récupère les titres qui proviennent de « ntpq ». Si jamais les titres devaient être modifiés un jour, le script devrait être en mesure de les prendre en compte. |
<?xml version="1.0" encoding="UTF-8"?> <peers> <server> <remote>remote</remote> <refid>refid</refid> <st>st</st> <t>t</t> <when>when</when> <poll>poll</poll> <reach>reach</reach> <delay>delay</delay> <offset>offset</offset> <jitter>jitter</jitter> </server> <server> <remote>138.195.130.151</remote> <refid>.INIT.</refid> <st>16</st> <t>u</t> <when>-</when> <poll>1024</poll> <reach>0</reach> <delay>0.000</delay> <offset>0.000</offset> <jitter>0.000</jitter> </server> <server> <remote>195.83.66.158</remote> <refid>.INIT.</refid> <st>16</st> <t>u</t> <when>-</when> <poll>1024</poll> <reach>0</reach> <delay>0.000</delay> <offset>0.000</offset> <jitter>0.000</jitter> </server> <server> <remote>193.55.167.1</remote> <refid>.INIT.</refid> <st>16</st> <t>u</t> <when>-</when> <poll>1024</poll> <reach>0</reach> <delay>0.000</delay> <offset>0.000</offset> <jitter>0.000</jitter> </server> <server> <remote>80.74.64.1</remote> <refid>.INIT.</refid> <st>16</st> <t>u</t> <when>-</when> <poll>1024</poll> <reach>0</reach> <delay>0.000</delay> <offset>0.000</offset> <jitter>0.000</jitter> </server> <server> <remote>[PEER] LOCAL(0)</remote> <refid>.Port.</refid> <st>3</st> <t>l</t> <when>14</when> <poll>64</poll> <reach>377</reach> <delay>0.000</delay> <offset>0.000</offset> <jitter>0.001</jitter> </server> </peers>
Note | |
---|---|
Merci de ne pas prendre en compte les valeurs NTP, mon serveur à cet instant était déconnecté d'internet... |
Les 3 scripts utilisent la commande ntpq pour requêter à distance des serveurs NTP.
Il est obligatoire que l'adresse IP de la machine où est installé NTPGraffe, soit autorisée à faire ces actions.
Voici un exemple d'instruction à inscrire dans le fichier ntp.conf
(/etc/ntp ou /etc), en prenant
comme IP source 192.10.10.20
. restrict 192.10.10.20 notrust. Il existe plusieurs options de limitation,
il ne faut surtout pas activer l'option suivante : noquery
.
Pour l'utilisation de « notrust », je ne peux que vous conseiller de bien lire le glossaire à ce propos : notrust.
L'image suivante prend comme exemple un seul serveur, sous le nom de « localhost ». Vous avez les priorités d'indiquées puis les diverses créations des fichiers.
Cette étape doit intervenir une fois que tous les scripts ont été testés manuellement(!), en conséquence les 2 fichiers .rrd
doivent être présents.
Voici comment réaliser ces inscriptions, en prenant en exemple 2 serveurs, l'un s'appelle localhost
, et l'autre est identifié par son
adresse IP 192.168.1.11
0,5,10,15,20,25,30,35,40,45,50,55 * * * * root /var/www/ntpgraffe/scripts/ntp-graphe.pl localhost new 2&>1 > /dev/null 0,10,20,30,40,50 * * * * root /var/www/ntpgraffe/scripts/ntp-udp.pl localhost 2&>1 > /dev/null # 0,5,10,15,20,25,30,35,40,45,50,55 * * * * root /var/www/ntpgraffe/scripts/ntp-graphe.pl 192.168.1.11 new 2&>1 > /dev/null 0,10,20,30,40,50 * * * * root /var/www/ntpgraffe/scripts/ntp-udp.pl 192.168.1.11 2&>1 > /dev/null # */15 * * * * root /var/www/ntpgraffe/scripts/ntp-peers.pl 192.168.1.11 2&>1 > /dev/null */15 * * * * root /var/www/ntpgraffe/scripts/ntp-peers.pl localhost 2&>1 > /dev/null
Note | |
---|---|
Attention aux différences entre les valeurs « 0,5,10... », qui déclenchent une action à des minutes précises.
Donc prenez garde à l'écriture sous cette forme Attention également aux droits d'accès pour ces fichiers, sinon c'est la catastrophe. |
Pour utiliser NTPGraffe, je ne peux que conseiller d'utiliser une politique d'adressage par l'IP pour joindre les serveurs. J'insiste sur le mot politique, car cette façon de faire doit être faite du début jusqu'à la fin. Ceci reste valable à tout niveau, sont inclus le fichier de configuration de NTP (ntp.conf), et les appels aux scripts. Cette façon de faire est possible aisément en IPv4, je le reconnais. Sinon, il reste la solution de l'adressage complet (FQDN), mais dont la dépendance avec le DNS influe sur les temps de connexion. L'avantage d'utiliser les adresses IP (surtout IPv4) est de créer des fichiers dont le nom est relativement court, contrairement au nommage complet DNS. Mais comme souvent, il existe un cas, le "localhost" plus facile à utiliser que son adressage IP.
NTPGraffe n'invente rien; il est essentiel qu'il soit en mesure de récupérer des informations pour pouvoir les afficher, les traiter. Ces informations doivent provenir des 3 scripts, complétés par des fichiers de configuration.
Cette opération peut sembler longue, mais celle ci n'est pas réalisée régulièrement.
En théorie un réseau NTP est relativement stable dans le temps, en parlant de l'identification des serveurs.
Ce chapitre va comporter le mot thème, qui, à mes yeux, mérite une explication. Le mot « thème » est utilisé
afin de sélectionner des données précises comme les offset, le jitter...etc.
Les graphiques sont générés par thème à raison de 4 images temporellement différentes. Ceux-ci se retrouvent au travers du fichier ntpgraffe.xml,
qui comporte par thème des balises identiques, numérotées de 1 à 4. Le principe reste identique pour chaque thème (!).
En prenant comme exemple le thème offset, voici ce que doit donner le paramétrage pour le serveur 192.168.1.11
<offset1>scripts/192.168.1.11-offset-J.png</offset1> <offset2>scripts/192.168.1.11-offset-S.png</offset2> <offset3>scripts/192.168.1.11-offset-M.png</offset3> <offset4>scripts/192.168.1.11-offset-A.png</offset4>
Je pense que la procédure est simple; elle reflète aussi la réalité car le script concerné (ntp-graphe.pl) a généré ces 4 fichiers, donc rien à inventer, juste reprendre de l'existant.
Cette procédure est applicable pour les autres thèmes « freq/jitter/udp/noise et stability »
Note | |
---|---|
Pour ne pas prendre en compte une image, un thème...il suffit de ne pas donner d'information à la balise concernée. |
Ce fichier est en sorte une interface entre les 2 scripts et les images les plus importantes. Le paramétrage de ce fichier est simple, il est basé sur du XML, à ce titre sa structure ne peut pas être modifiée. Voici les explications de chaque ligne XML, NTPGraffe ne fait que lire ces informations, il n'y a aucun test de cohérence. Chaque déclaration d'un serveur NTP doit être encadrée par la balise <server>.
name
, correspond au nom FQDN (nom complet internet/DNS) du serveur.
type
, désigne le type de STRATE pour ce serveur.
adress
, doit correspondre à l'adresse IP du serveur.
label
, correspond à un nommage modifié, plus clair, personnel, géographique...du serveur.
comment
, champ libre pour laisser des commentaires, sans limitation en longueur.
Néanmoins, NTPGraffe n'est pas prévue pour afficher un roman...
<?xml version="1.0" encoding="UTF-8"?> <!-- Ce fichier contient l'ensemble des paramètres pour l'interface. Attention : un changement d'@IP et toute l'historique d'un serveur est à refaire. Attention : attention aussi à "localhost", c'est soit çà, soit "127.0.0.1" mais pas les deux. C'est un cas, il faut rester cohérent avec les données des scripts en particulier --> <parametres> <!-- declaration d'un serveur --> <server> <name>localhost</name> <type>NTP1</type> <adress>localhost</adress> <!-- attention le script genere pour "localhost", le cas ! --> <label>localhost</label> <comment>Serveur local</comment> <!-- Facultatif(infos) directory : --> <directory>/var/www/localhost/htdocs/ntpgraffe/scripts/</directory> <!-- Identification des graphes FREQUENCES --> <freq1>scripts/localhost-freq-J.png</freq1> <!-- 24 heures --> <freq2>scripts/localhost-freq-S.png</freq2> <!-- 7 jours --> <freq3>scripts/localhost-freq-M.png</freq3> <!-- 1 mois --> <freq4>scripts/localhost-freq-A.png</freq4> <!-- 365 jours --> <!-- Identification des graphes JITTER --> <jitter1>scripts/localhost-jitter-J.png</jitter1> <!-- 24 heures --> <jitter2>scripts/localhost-jitter-S.png</jitter2> <!-- 7 jours --> <jitter3>scripts/localhost-jitter-M.png</jitter3> <!-- 1 mois --> <jitter4>scripts/localhost-jitter-A.png</jitter4> <!-- 365 jours --> <!-- Identification des graphes OFFSET --> <offset1>scripts/localhost-offset-J.png</offset1> <!-- 24 heures --> <offset2>scripts/localhost-offset-S.png</offset2> <!-- 7 jours --> <offset3>scripts/localhost-offset-M.png</offset3> <!-- 1 mois --> <offset4>scripts/localhost-offset-A.png</offset4> <!-- 365 jours --> <!-- Identification des graphes UDP(TRAFIC) --> <udp1>scripts/rzo-localhost-J.png</udp1> <!-- 24 heures --> <udp2>scripts/rzo-localhost-S.png</udp2> <!-- 7 jours --> <udp3>scripts/rzo-localhost-M.png</udp3> <!-- 1 mois --> <udp4>scripts/rzo-localhost-A.png</udp4> <!-- 365 jours --> <!-- N'est plus activées avec les versions récentes de NTPD --> <!-- A laisser "vide" sinon --> <!-- Identification des graphes NOISE --> <noise1></noise1> <!-- 24 heures --> <noise2></noise2> <!-- 7 jours --> <noise3></noise3> <!-- 1 mois --> <noise4></noise4> <!-- 365 jours --> <!-- Identification des graphes STABILITY --> <stability1></stability1> <!-- 24 heures --> <stability2></stability2> <!-- 7 jours --> <stability3></stability3> <!-- 1 mois --> <stability4></stability4> <!-- 365 jours --> </server> <!-- declaration d'un autre serveur --> <server> <name>serveur.archi.amt</name> <type>NTP1</type> <adress>192.168.1.11</adress> <label>Serveur</label> <comment>Serveur</comment> <directory>/var/www/localhost/htdocs/ntpgraph/scripts/</directory> <!-- Identification des graphes FREQUENCES --> <freq1>scripts/192.168.1.11-freq-J.png</freq1> <!-- 24 heures --> <freq2>scripts/192.168.1.11-freq-S.png</freq2> <!-- 7 jours --> <freq3>scripts/192.168.1.11-freq-M.png</freq3> <!-- 1 mois --> <freq4>scripts/192.168.1.11-freq-A.png</freq4> <!-- 365 jours --> <!-- Identification des graphes JITTER --> <jitter1>scripts/192.168.1.11-jitter-J.png</jitter1> <!-- 24 heures --> <jitter2>scripts/192.168.1.11-jitter-S.png</jitter2> <!-- 7 jours --> <jitter3>scripts/192.168.1.11-jitter-M.png</jitter3> <!-- 1 mois --> <jitter4>scripts/192.168.1.11-jitter-A.png</jitter4> <!-- 365 jours --> <!-- Identification des graphes OFFSET --> <offset1>scripts/192.168.1.11-offset-J.png</offset1> <!-- 24 heures --> <offset2>scripts/192.168.1.11-offset-S.png</offset2> <!-- 7 jours --> <offset3>scripts/192.168.1.11-offset-M.png</offset3> <!-- 1 mois --> <offset4>scripts/192.168.1.11-offset-A.png</offset4> <!-- 365 jours --> <!-- Identification des graphes OFFSET --> <udp1>scripts/rzo-192.168.1.11-J.png</udp1> <!-- 24 heures --> <udp2>scripts/rzo-192.168.1.11-S.png</udp2> <!-- 7 jours --> <udp3>scripts/rzo-192.168.1.11-M.png</udp3> <!-- 1 mois --> <udp4>scripts/rzo-192.168.1.11-A.png</udp4> <!-- 365 jours --> <!-- Ne sont plus activées avec les dernières versions de NTPD --> <!-- A laisser "vide" sinon --> <!-- Identification des graphes NOISE --> <noise1></noise1> <!-- 24 heures --> <noise2></noise2> <!-- 7 jours --> <noise3></noise3> <!-- 1 mois --> <noise4></noise4> <!-- 365 jours --> <!-- Identification des graphes STABILITY --> <stability1></stability1> <!-- 24 heures --> <stability2></stability2> <!-- 7 jours --> <stability3></stability3> <!-- 1 mois --> <stability4></stability4> <!-- 365 jours --> </server> <!-- FIN --> </parametres>
Ce fichier comporte 2 blocs cle
et procedure
.
Le 1er doit renvoyer des informations sur le groupe Autokey utilisé pour les serveurs. Il est suivi par la clé du serveur dit « principal ».
Ce bloc contient une balise directory
;
elle peut être utilisée lors du téléchargement de la clé vers un emplacement autre que la racine de NPTGraffe. Sinon, il faut laisser vide cette balise.
En ce qui concerne le bloc procedure
, vous êtes libre de placer autant de balises action
que vous le souhaitez.
NTPGraffe n'est tout de même pas prévu pour afficher un roman.
<?xml version="1.0" encoding="UTF-8"?> <!-- Ce fichier FACULTATIF contient l'ensemble des paramètres pour la gestion des clés NTP. Attention : Dans un contexte de gestion, IFF + Groupe, et non sous la forme : 1 serveur = sa propre clé pour chaque client. - 1 seule clé ne peut être présente Le fichier de clé (IFF+groupe+CA) doit être placé dans le répertoire "ntpgraph", ou similaire pour une question d'accès au fichier. Ne pas placer d'autres balises style "<br>" ...etc --> <parametre> <!-- declaration de la 1ere clé (active) --> <cle> <groupe>GR1</groupe> <!-- Nom du groupe de cle --> <file>ntpkey_cert_portable.archi.amt</file> <!-- doit contenir le nom du fichier de cle (public)--> <directory></directory> <!-- doit contenir que le rép --> </cle> <!-- PROCEDURE --> <!-- Chaque action est reprise sous forme d'un article ensuite vous pouvez faire des "actionsX" sans limite 1 action vide = 1 saut de ligne !!! --> <procedure> <action>Sur le serveur en STRATE 1 si possible : Attention : Dans un contexte de gestion de clé IFF + Groupe, et non sous la forme : 1 serveur = sa propre clé pour chaque client. Le fichier de clé (IFF+groupe+CA) doit être placé dans le répertoire (racine) "ntpgraph", ou similaire pour une question d'accès au fichier (téléchargement).</action> <action>Il existe de nombreuses solutions pour sécuriser un réseau NTP, en voici une qui mérite d'être rapide et simple.</action> <action>Placez vous dans le répertoire de configuration de NTP (/etc/ntp/).</action> <action>Le fameux fichier "leap-seconds.3427142400" doit être présent avant toute intervention.</action> <action>ntp-keygen -T -H -c RSA-SHA1 -m 2048 -p private -i GR1</action> <action>A noter : 2048 bits d'encodage, le mot de passe est "private" (ne pas diffuser en clair).</action> <action>Insérer cette ligne dans "ntp.conf" : "crypto pw private ident GR1" (exemple et sans les "").</action> <action>Transmettez cette clé à tous vos abonnés, de façon sécurisée (mot de passe). Ensuite chaque abonné|serveur doit procéder de la même façon, sans rien transmettre aux autres serveurs/abonnés.</action> <action>Relancer votre serveur, et surveillez l'état de vos connexions. Le fichier "cryptostats" peut vous aider.</action> </procedure> <!-- FIN --> </parametre>
Table des matières
Cette application WEB comporte 4 régions bien différentes (dont 1 logo qui se discute...) :
(1) Un bloc de présentation et de sélection des serveurs. Cette partie est dynamique, elle est liées aux données du fichier ntpgraffe.xml. Il permet de signaler la présence sur le réseau de l'accessibilité des différents serveurs. La présence d'une pastille de couleur rouge devant l'identification est synonyme de problème (exemple 10.0.2.15).
(2) Un bloc « menu » pour sélectionner diverses actions. Cette partie est dynamique, elle est liées aux données du fichier ntpgraffe.xml.
En fonction du fichier de configuration ntpgraffe.xml, les menus noise
et stability
peuvent apparaître.
(3) Un bloc central permet l'affichage des données, des images...
4) Le pied de page, comprend juste le copyright (sans grand intérêt).
Depuis la page d'accueil, il est possible de sélectionner 10 menus différents, dont 2 sont dédiés aux anciennes versions de NTP.
Ces menus incluent les données pour les paramètres noise
et stability
. Ces changements interviennent lors de la sélection du serveur (bloc 1).
Les différents menus accessibles (bloc 2):
A part la partie graphique, chaque image présentée peut-être agrandie en cliquant une fois dessus. Il faut sélectionner un serveur (bloc 1) avant de pouvoir consulter les différents menus, à l'exception de « infos + clé + Mémo ». Le cas échéant, le 1er serveur inscrit dans le bloc 1 est sélectionné. NTPGraffe comme déjà écrit, dépend, pour exploiter la totalité de ces données, du réseau, des serveurs distants et des 3 scripts. Les descriptifs qui suivent se ressemblent, et leurs actions aussi...
C'est le menu activé lors de l'activation de NTPGraffe; celui-ci affiche pour la partie la plus intéressante 4 images, ou graphiques. Ce menu permet de prendre connaissance des 3 paramètres essentiels (Offset / Jitter / Fréquence), puis le débit. La période est fixée à défaut à 24 heures.
Ce menu active dans la partie centrale, 4 graphiques différents concernant exclusivement les données du type offset.
Ce menu active dans la partie centrale, 4 graphiques différents concernant exclusivement les données du type jitter.
Ce menu active dans la partie centrale, 4 graphiques différents concernant exclusivement les données du type frequency.
Ce menu apparaît uniquement pour les anciennes valeurs de NTP. Ce menu active dans la partie centrale, 4 graphiques différents concernant exclusivement les données du type noise.
Ce menu apparaît uniquement pour les anciennes valeurs de NTP. Ce menu active dans la partie centrale, 4 graphiques différents concernant exclusivement les données du type stability.
Ce menu active, dans la partie centrale, 4 graphiques différents concernant exclusivement les données sur les paquets UDP reçus. Le graphique permet de connaître rapidement comment se comportent les connexions, en particulier avec l'authentification.
Ce menu active 1 tableau comportant des données pertinentes pour les relations entre un serveur (la cible) et d'autres connexions. Les différents statuts, ou du moins les plus importants, sont pris en compte. Les lignes du tableau sont colorisées en fonction de ces statuts.
Note | |
---|---|
A noter que le champ remote est volontairement limité en longueur par « ntpq ». Ceci se retrouve sur NTPGraffe également, en particulier dans ce menu. |
En se basant sur l'image ci-dessous, il est possible de découvrir rapidement le statut des connexions vis-à-vis d'un serveur sélectionné
préalablement.
En commençant de haut en bas, la 1ere connexion est marquée d'une couleur rouge, caractéristique d'un problème, parfois temporaire.
Ceci est dû à un changement d'adressage IP au niveau de la carte réseau (statut XFAC). Ce statut est relativement rare,
le cas échéant il faut utiliser l'option -U0
pour ntpd.
La 2eme ligne de couleur verte intense, correspond au mode « peer ». Dans cet exemple, le serveur
ntp.univ-poitier
possède une connexion active vers le serveur sélectionné (localhost dans l'exemple).
Il ne peut y avoir qu'une seule connexion active de ce type par serveur. Ne pas confondre avec les paramètres de configuration,
qui en autorise plusieurs.
Les 3 et 4eme lignes sont identiques. Il s'agit de serveurs sélectionnés par NTP, déclarés comme fiables, mais qui ne peuvent passer en mode « peer ». C'est une sorte de position « en attente de... » ou « en secours » du serveur qui en est position« peer ». Il est bon sur un serveur de posséder au moins une connexion en mode « CANDIDATE ».
Les 5 et 6emes lignes sont liées: le serveur distant est déclaré 2 fois pour NTP, mais celui ci ne peut authentifier et même réaliser les 2 connexions simultanément. En conséquence, NTP fait son choix et rejette l'une d'elle. Cette situation n'est pas alarmante, à condition de lire 2 lignes similaires pour un même serveur. Voilà les 2 lignes « fautives » :
server 192.168.1.11 burst iburst prefer autokey
peer 192.168.1.11 autokey
La dernière ligne représente le serveur « local », ceci est indispensable pour un bon serveur NTP. Ce type de « connexion » ne doit pas être en erreur.
Voici quelques informations suplémentaires sur les données affichées dans les différentes colonnes :
st
Cette valeur est expliquée ici : st
t
Cette valeur est expliquée ici : t
when
Cette valeur est expliquée ici : when
poll
Elle correspond à un cycle ou une valeur en seconde, que le serveur (NTP) a estimé nécessaire. En clair, sur un serveur stable, cette valeur doit être grande, sauf au démarrage bien évidemment. Cette valeur est réglable, mais NTP sait très bien la gérer. Les valeurs s'échelonnent par pas de 64 secondes, jusqu'à 1024.
reach
Cette valeur correspond à un compteur binaire. Il est basé sur 8 essais, la valeur maximale ou la meilleure est 377
.
C'est donc une donnée à surveiller; je dirai après les « offset ».
delay
Cette valeur correspond aux délais de transmissions (ms).
Ce menu affiche des informations liées à la clé d'un groupe défini (« x »), lequel comporte plusieurs serveurs, et une seule clé certifiée. Cette clé est téléchargeable, et son nom est également indiqué afin d'éviter les risques d'erreurs. Le tableau comporte les données qui sont extraites du fichier ntpgraffe-key.xml. Ce menu ne permet pas le contrôle, la gestion et le renouvellement de cette clé.
Ce menu permet de lire les informations contenues dans le fichier ntpgraffe.xml.
Il est aussi présent en dernier tableau; les données complètes de la commande sont : ntpq -c rv
, pour le serveur sélectionné.
Les scripts et l'interface NTPGraffe ont été crées de toutes pièces à partir de rien. Par nécessité, car je n'ai pas croisé d'application qui me permette de contrôler mes serveurs, même s'ils ne sont pas nombreux. Il est important de prendre en compte toutes les données que présentent cette interface. Donc une fois de plus, je suis encore mieux servi par moi-même. C'est la première version avec probablement des bogues, des problèmes d'encodages. Ce projet sera soutenu par moi-meme et en fonction de son intérêt sur internet, d'autres solutions pourront être envisagées. Je n'exclus pas une version ultérieure avec bien sûr des possibilités nouvelles.
A ce titre, la résolution des divers status (GB)
rencontrés me posent un réel problème. Avec les données présentes,
peut-être amplifiées aussi avec mes versions de NTP trop récentes, je n'ai rien lu pour expliquer les différentes valeurs. C'est bien dommage car c'est une donnée
intéressante, donc à suivre...(exemple : e015 = « e0 »(?) et pour 15 peut-être x0a (va devenir sys-peer, x05 pour« association redémarrer. »
J'espère que cette application et ses scripts permettront de mieux comprendre ce vaste domaine qui est le NTP.
Seule la feuille de style est basée mais largement modifiée d'un « template » Joomla 1.5, celui-ci
s'appelle Candle(free GPL)
. Je remercie « tstemplates@gmail.com » pour avoir autoriser ceci. Je ne peux que conseiller son site disponible ici :
www.tstemplates.tk
Table des matières
Divers programmes de « monitoring » dans tous les genres : www.satsignal.eu
NTPQ aide : http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
Meinberg propose aussi un outil, hélas sous mon SE détesté : http://www.meinberg.de/english/sw/time-server-monitor.htm
Mon site avec en particulier 2 liens pour le NTP :
Permet de connaître des valeurs NTP « internes »pour un serveur. Cette commande est peut utilisée.
ntpq -c clockvar 192.168.1.11 associd=0 status=0000 , no events, clk_unspec, device="Undisciplined local clock", timecode=, poll=11, noreply=0, badformat=0, baddata=0, fudgetime1=0.000, stratum=1, refid=SERV, flags=0
Cette option est apparue avec les versions récentes de NTP. Elle permet de mieux maitriser les flux NTP; des réglages sont possibles. Voir cet article pour de plus amples renseignements : http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#mru
ntpq -c mrulist lstint avgint rstr r m v count rport remote address ============================================================================== 37 29 0 . 3 4 828 123 serveur.archi.amt 71 275 c0 . 4 4 87 123 diane.ensma.fr 237 264 c0 . 4 4 90 123 ntp.univ-poitiers.fr 800 269 c0 . 4 4 86 123 ns1.pulsation.fr
Pour la commande qui liste toutes les connexions en détails, il faut au préalable faire la commande ntpq -c as
,
et récupérer les ASSOCID
. Ce qui suit est un extrait des données.
ntpq> mrv 23869 23875 associd=23869 status=8011 conf, sel_reject, 1 event, mobilize, srcadr=krishna.via.ecp.fr, srcport=123, dstadr=192.168.1.90, dstport=123, leap=11, stratum=16, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=INIT, reftime=00000000.00000000 Mon, Jan 1 1900 0:09:21.000, rec=00000000.00000000 Mon, Jan 1 1900 0:09:21.000, reach=000, unreach=34, hmode=3, pmode=0, hpoll=10, ppoll=10, headway=0, flash=1600 peer_stratum, peer_dist, peer_unreach, keyid=0, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, xleave=0.046, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 associd=23870 status=963a conf, reach, sel_sys.peer, 3 events, sys_peer, srcadr=ntp.univ-poitiers.fr, srcport=123, dstadr=192.168.1.90, dstport=123, leap=00, stratum=3, precision=-20, rootdelay=11.719, rootdisp=73.074, refid=145.238.203.10, reftime=cfb6349a.98078961 Sun, Jun 6 2010 16:52:10.593, rec=cfb637a7.a4b1f01a Sun, Jun 6 2010 17:05:11.643, reach=377, unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok, keyid=0, offset=-5.076, delay=70.181, dispersion=18.886, jitter=5.153, xleave=0.053, filtdelay= 70.63 70.18 70.11 73.66 69.78 70.70 82.86 69.39, filtoffset= -7.20 -5.08 -4.00 -1.55 -2.37 -1.09 5.92 -0.21, filtdisp= 0.00 15.89 31.56 46.92 62.99 70.94 79.05 86.75 associd=23873 status=e015 conf, authenb, auth, sel_reject, 1 event, restart, srcadr=serveur.archi.amt, srcport=123, dstadr=192.168.1.90, dstport=123, leap=00, stratum=3, precision=-21, rootdelay=62.103, rootdisp=67.032, refid=94.23.196.225, reftime=cfb63773.a4edad5e Sun, Jun 6 2010 17:04:19.644, rec=cfb63a52.931d18b0 Sun, Jun 6 2010 17:16:34.574, reach=000, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=508, flash=1480 pkt_autokey, peer_dist, peer_unreach, keyid=2764016984, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, xleave=0.044, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0, host="GR1", flags=0x415121, signature="sha1WithRSAEncryption" associd=23875 status=8043 conf, sel_reject, 4 events, unreachable, srcadr=LOCAL(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00, stratum=3, precision=-20, rootdelay=0.000, rootdisp=10.000, refid=Port, reftime=00000000.00000000 Mon, Jan 1 1900 0:09:21.000, rec=cfb5dc36.929e9fdb Sun, Jun 6 2010 10:35:02.572, reach=000, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=0, flash=1000 peer_unreach, keyid=0, offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00, filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Autokey désigne tous les systèmes pouvant être mis en œuvre pour authentifier les connexions NTP. http://www.eecis.udel.edu/~mills/keygen.html
(roundtrip delay). Cette valeur correspond au temps de transmission pour une requête NTP.
Le tableau qui suit permet de décoder la valeur « flag[s] » avec l'authentification(!) :
#define CRYPTO_FLAG_PRIV 0x0010 /* PC identity scheme */ #define CRYPTO_FLAG_IFF 0x0020 /* IFF identity scheme */ #define CRYPTO_FLAG_GQ 0x0040 /* GQ identity scheme */ #define CRYPTO_FLAG_MV 0x0080 /* MV identity scheme */ #define CRYPTO_FLAG_VALID 0x0100 /* public key verified */ #define CRYPTO_FLAG_VRFY 0x0200 /* identity verified */ #define CRYPTO_FLAG_PROV 0x0400 /* signature verified */ #define CRYPTO_FLAG_AGREE 0x0800 /* cookie verifed */ #define CRYPTO_FLAG_AUTO 0x1000 /* autokey verified */ #define CRYPTO_FLAG_SIGN 0x2000 /* certificate signed */ #define CRYPTO_FLAG_LEAP 0x4000 /* leapseconds table verified */ #define CRYPTO_FLAG_ALL 0x7f00 /* all mask */ #define CRYPTO_FLAG_ENAB 0x0001 /* crypto enable */ #define CRYPTO_FLAG_TAI 0x0002 /* leapseconds table */ #define CRYPTO_FLAG_PRIV 0x0010 /* PC identity scheme */ #define CRYPTO_FLAG_IFF 0x0020 /* IFF identity scheme */ #define CRYPTO_FLAG_GQ 0x0040 /* GQ identity scheme */ #define CRYPTO_FLAG_MV 0x0080 /* MV identity scheme */ #define CRYPTO_FLAG_MASK 0x00f0 /* identity scheme mask */ /* * Drapeaux utilisés pour les certificats uniquement : */ #define CERT_TRUST 0x01 /* certificate is trusted */ #define CERT_SIGN 0x02 /* certificate is signed */ #define CERT_VALID 0x04 /* certificate is valid */ #define CERT_PRIV 0x08 /* certificate is private */ #define CERT_ERROR 0x80 /* certificate has errors */
Cette valeur est également importante; elle est retrouvée dans diverses commandes. La meilleure valeur est « O », qui affiche le mot « ok » en plus. Voici les valeurs possibles sous forme de drapeaux.
/* * Values for peer.flags (utilisable via "nptq -c as" ou avec "mrv") */ #define FLAG_CONFIG 0x0001 /* association was configured */ #define FLAG_PREEMPT 0x0002 /* preemptable association */ #define FLAG_AUTHENTIC 0x0004 /* last message was authentic */ #define FLAG_REFCLOCK 0x0008 /* this is actually a reference clock */ #define FLAG_SYSPEER 0x0010 /* system peer */ #define FLAG_PREFER 0x0020 /* prefer peer */ #define FLAG_BURST 0x0040 /* burst mode */ #define FLAG_PPS 0x0080 /* steered by PPS */ #define FLAG_IBURST 0x0100 /* initial burst mode */ #define FLAG_NOSELECT 0x0200 /* never select */ #define FLAG_TRUE 0x0400 /* force truechimer */ #define FLAG_SKEY 0x0800 /* autokey authentication */ #define FLAG_XLEAVE 0x1000 /* interleaved protocol */ #define FLAG_XB 0x2000 /* interleaved broadcast */ #define FLAG_XBOGUS 0x4000 /* interleaved bogus packet */ #ifdef OPENSSL #define FLAG_ASSOC 0x8000 /* autokey request */ #endif /* OPENSSL */
/* * Flags for interfaces */ #define INT_UP 0x001 /* Interface is up */ #define INT_PPP 0x002 /* Point-to-point interface */ #define INT_LOOPBACK 0x004 /* the loopback interface */ #define INT_BROADCAST 0x008 /* can broadcast out this interface */ #define INT_MULTICAST 0x010 /* can multicast out this interface */ #define INT_BCASTOPEN 0x020 /* broadcast socket is open */ #define INT_MCASTOPEN 0x040 /* multicasting enabled */ #define INT_WILDCARD 0x080 /* wildcard interface - usually skipped */ #define INT_MCASTIF 0x100 /* bound directly to MCAST address */ /* * Define flasher bits (tests 1 through 11 in packet procedure) * These reveal the state at the last grumble from the peer and are * most handy for diagnosing problems, even if not strictly a state * variable in the spec. These are recorded in the peer structure. * * Packet errors */ #define TEST1 0X0001 /* duplicate packet */ #define TEST2 0x0002 /* bogus packet */ #define TEST3 0x0004 /* protocol unsynchronized */ #define TEST4 0x0008 /* access denied */ #define TEST5 0x0010 /* bad authentication */ #define TEST6 0x0020 /* bad synch or stratum */ #define TEST7 0x0040 /* bad header */ #define TEST8 0x0080 /* bad autokey */ #define TEST9 0x0100 /* bad crypto */ /* * Peer errors */ #define TEST10 0x0200 /* peer bad synch or stratum */ #define TEST11 0x0400 /* peer distance exceeded */ #define TEST12 0x0800 /* peer synchronization loop */ #define TEST13 0x1000 /* peer unreacable */
Ce paramètre ne semble plus être utilisé dans les versions récentes de NTP.
Jitter correspond aussi à la « dispersion » exprimée en millisecondes. Il s'agit d'une mesure de la stabilité (en temps) vers le serveur distant, et est également un facteur important utilisé par NTP à choisir le « meilleur » serveur. Les bonnes valeurs s'expriment en micro secondes (µs), et non en millisecondes (ms), synonyme de manque de précision. Sinon ces valeurs doivent être petites pour être synonyme de stabilité, performance.
C'est la différence entre 2 temps horaires, comparés à l'horloge de référence. Cela représente l'ajustement de l'horloge locale et la référence horaire.
Il correspond à intervalle de temps entre 2 requêtes; cette valeur est exprimée en secondes. Cette valeur est grande (exemple : 1024 sec) pour une connexion stable et fiable.
Ce paramètre ne semble plus être utilisé dans les versions récentes de NTP.
Cette restriction permet de refuser les paquets qui ne sont pas cryptographiquement authentifiés.
Cette restriction s'applique pour une adresse IP, ou une plage. Si vous souhaitez que votre serveur authentifie toutes les connexions,
il faut activer dans le fichier de configuration de NTP la valeur auth
. L'utilisation des deux paramètres sont compatibles.
Le site « ntp.org » représente l'ensemble du projet NTP, dont l'Université du Delaware est partie prenante. NTP représente aussi bien une suite logiciel, mais c'est aussi un protocole . http://www.ntp.org/index.html
Il représente le fichier exécutable et fait serveur NTP.
(Téléchargement) : http://www.ntp.org/downloads.html. Voici le lien vers sa documentation offcielle : http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html
« ntpdc », ce programme permet de questionner un serveur à distance ou pas. Ce programme semble vouloir etre remplacé par ntpq.
Le type de mode de paquet NTP utilisé est le 7
. La documentation de référence : http://www.eecis.udel.edu/~mills/ntp/html/ntpdc.html
ntpq« ntpq », ce programme permet de questionner un serveur NTP, à distance ou pas.
Le type de mode de paquet NTP utilisé est le 6
. La documentation de référence : http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
Désigne un serveur distant ou en local qui participe au NTP.
Tout serveur NTP se doit de prendre une référence de temps. Ce choix qui est réalisé par ntpd, ceci peut-être du GPS, du PPS, une horloge atomique mais
également un autre serveur de temps. La lecture de ce paramètre permet de prendre connaissance de ceci. Cette valeur est modifiable sur le serveur dans le fichier
ntp.conf
par ce type d'instruction fudge 127.127.1.0 stratum 1 refid Port2
(pour portable nr 2).
(données extraites depuis fr.wikipedia.org) : RRDtool est un outil de gestion de base de données RRD (round-Robin database) créé par Tobi Oetiker. Il est utilisé par de nombreux outils open source, tels que Cacti, collectd, Lighttpd, et Nagios, pour la sauvegarde de données cycliques et le tracé de graphiques, de données chronologiques. Cet outil a été créé pour superviser des données serveur, telles la bande passante et la température d'un processeur. Le principal avantage d'une base RRD est sa taille fixe. RRDTool inclut également un outil permettant de représenter graphiquement les données contenues dans la base. RRDTool est un logiciel libre distribué selon les termes de la GNU GPL.
Reach est le résultat des huit derniers tests pour un serveur distant, c'est un compteur su 8 bits. Une valeur de 377 représente le maximum et aucun échec; une valeur de 0 signifie que les huit dernières tentatives sont négatives, ou en échéc.
Ce paramètre ne semble plus être utilisé dans les versions récentes de NTP. Il représente comment l'horloge maintient une fréquence constante pour la stabilité.
Terme anglais : Simple Network Management Protocol (abrégé SNMP). fr.wikipedia.org
Désigne la « STRATE » du serveur distant, pour mémoire la valeur 16
désigne un serveur, ou une connexion non synchronisée.
Cette lettre permet l'identification du mode diffusion pour le serveur concerné.
u: unicast or manycast client,
b: broadcast or multicast client,
l: local (reference clock),
s: symmetric (peer),
A: manycast server,
B: broadcast server,
M: multicast server
Représente une durée exprimée en « sec/min/hr », depuis le dernier paquet reçu. Si la valeur ne comporte pas de mention « m,h », il s'agit de secondes.