Installer et utiliser NTPGraffe v1.0.

Historique des versions
Version 1.005 juin 2010
Publication du document
Version 1.15 juillet 2010
Modification mineure.

Table des matières

Contexte
Sous licence GPL v3 :
1. Les prérequis et les versions à utiliser.
Pour NTP
Pour Perl et PHP
2. L'installation :
Les répertoires :
3. Compilation et installation de NTP.
Téléchargement et compilation.
Compilation.
4. Les descriptifs génériques ( 3 scripts) :
Points communs.
Paramétrage des répertoires.
Les réglages temporels.
Le réglage des couleurs :
Les dimensions des images.
Points communs pour les graphiques.
ntp-graphe.pl
ntp-udp.pl
Problème de versions.
ntp-peers.pl
Les accès aux serveurs.
Vision graphique sur les 3 scripts
Inscription dans la crontab
Politique d'adressage des serveurs
5. NTPGraffe
Identification des graphiques
Le fichier ntpgraffe.xml
Le fichier ntpgraffe-key.xml
6. L'interface graphique (NTPGraffe).
Les menus.
La page d'accueil.
Les autres menus.
7. Conclusion.
A. Annexe 1
Liens utiles :
Commandes utiles :
Glossaire

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]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é.

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.

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.

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 ».

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]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 :

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]Avertissement

Attention à la donnée de type 365d, qui peut s'écrire 1y, mais provoque une erreur RRDTool (?).

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 :

  1. Cette ligne indique la valeur actuelle et la valeur maximale positive, pour la période sélectionnée (24h, 7 jours...).

  2. Cette ligne est similaire : elle indique les valeurs pour la moyenne et le maximal négatif pour la période sélectionnée.

  3. 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.

  4. 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 ».

  5. 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.

  6. 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.

  7. 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]Avertissement

Ce script est programmé pour être déclenché automatiquement toutes les 5 minutes via la crontab. Il est important de respecter cette valeur, la modification entraine soit des données inexactes, soit une modification de code.

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]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]Avertissement

Ce script est programmé pour être déclenché automatiquement toutes les 10 minutes via la crontab.

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]Note

Je vais laisser dans le répertoire « doc », le fichier ntp-udp-old.pl, pour les anciennes versions. A vous de le remplacer par la nouvelle version dans le répertoire « scripts ».

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]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]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.

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]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>

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):

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.

Le menu noise (optionnel) :

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.

Le menu stability (optionnel)» :

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 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]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 :

  • 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).

  • offset et jitter

    Je pense que ces données ont été largement exploitées précédemment.

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

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 :

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

delay :

(roundtrip delay). Cette valeur correspond au temps de transmission pour une requête NTP.

flag[s] :

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 */
flash :

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 */
frequency :

Ce paramètre ne semble plus être utilisé dans les versions récentes de NTP.

jitter :

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.

offset :

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.

poll :

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.

noise :

Ce paramètre ne semble plus être utilisé dans les versions récentes de NTP.

notrust :

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.

NTP :

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

ntpd :

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 :

« 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« 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

remote :

Désigne un serveur distant ou en local qui participe au NTP.

refid :

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).

RRDTool :

(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 :

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.

stability :

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é.

snmp :

Terme anglais : Simple Network Management Protocol (abrégé SNMP). fr.wikipedia.org

st :

Désigne la « STRATE » du serveur distant, pour mémoire la valeur 16 désigne un serveur, ou une connexion non synchronisée.

t :

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

when :

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.