15.2. Comprendre Chrony et sa configuration

Les commentaires doivent être précédés de #, %, ; ou de !

Optionnellement, spécifiez un hôte, un sous-réseau, ou un réseau à partir duquel autoriser les connexions NTP à une machine qui puisse agir en tant que serveur NTP. Par défaut, les connexions ne sont pas autorisées.

Similaire à la directive allow (veuillez consulter la section allow), sauf que l'accès de contrôle est autorisé (plutôt que l'accès client NTP) sur un sous-réseau ou un hôte particulier. (« accès de contrôle » signifie que chronyc peut être exécuté sur ces hôtes et connecté avec succès à chronyd sur cet ordinateur.) La syntaxe est identique. Il existe également une directive cmddeny all avec un comportement similaire à la directive cmdallow all.

Chemin vers le répertoire pour enregistrer l'historique des mesures à travers les redémarrages de chronyd (en supposant qu'aucun changement n'ait été appliqué au comportement de l'horloge système pendant qu'elle n'était pas en cours d'exécution). Si cette capacité doit être utilisée (via la commande dumponexit dans le fichier de configuration, ou la commande dump dans chronyc), la commande dumpdir doit être utilisée pour définir le répertoire dans lequel les historiques des mesures sont enregistrés.

Si cette commande est présente, elle infique que chronyd devrait enregistrer l'historique des mesure de chacune de ses sources horaire lorsque le programme se ferme. (Veuillez consulter la commande dumpdir ci-dessus).

Le mot-clé local est utilisé pour que chronyd puisse apparaître synchronisé avec le temps réel du point de vue des interrogations des clients, même s'il ne possède pas de source de synchronisation actuellement. Cette option est normalement utilisée sur l'ordinateur « maître » dans un réseau isolé, où il est requis que plusieurs ordinateurs soient synchronisés les uns aux autres, et où le « maître » est aligné au temps réel par saisie manuelle.

Voici un exemple de la commande :

local stratum 10

Une valeur élevée de 10 indique que l'horloge se trouve si loin de l'horloge de référence que son heure n'est pas fiable. Si l'ordinateur a accès à un autre ordinateur qui lui est synchronisé à une horloge de référence, celui-ci se trouvera à un stratum de moins de 10. Ainsi, le choix d'une valeur élevée, comme 10 pour la commande local, empêche à l'heure de la machine d'être confondue avec le temps réel, si celle-ci devait un jour se propager aux clients qui peuvent voir des serveurs réels.

La commande log indique que certaines informations doivent être journalisées. La commande accepte les options suivantes : Les fichiers journaux sont écrits sur le répertoire spécifié par la commande logdir. Ci-dessous figure un exemple de la commande :

log measurements statistics tracking

Cette directive permet de spécifier le répertoire où les fichiers journaux sont écrits. Ci-dessous figure un exemple d'utilisation de cette directive :

logdir /var/log/chrony

Normalement, chronyd fera que le système corrigera peu à peu tout décalage horaire, en ralentissant ou en accélérant l'horloge selon les besoins. Dans certaines situations, l'horloge système peut avoir dérivé au point où le processus de correction risque de prendre un long moment avant de corriger l'horloge système. Cette directive force chronyd à modifier l'horloge système si cet ajustement est supérieur à la valeur maximale, mais seulement s'il n'y a pas eu de mise à jour de l'horloge depuis que chronyd a été lancé dans la limite spécifiée (une valeur négative peut être utilisée pour désactiver la limite). Ceci est particulièrement utile lors de l'utilisation d'horloges de référence, car la directive initstepslew fonctionne uniquement avec des sources NTP.

Ci-dessous figure un exemple d'utilisation de la directive :

makestep 1000 10

Cette directive modifierait l'horloge système si l'ajustement était plus important que 1000 secondes, mais seulement lors des dix premières mises à jour horaires.

Cette directive paramètre le décalage maximal autorisé corrigé sur une mise à jour de l'horloge. La vérification est effectuée uniquement après le nombre indiqué de mises à jour afin de permettre un ajustement initial important de l'horloge système. Lorsqu'un décalage supérieur au maximum spécifié se produit, il sera ignoré pour le nombre de fois indiqué, puis chronyd abandonnera et quittera (une valeur négative peut être utilisée afin de ne jamais quitter). Dans les deux cas, un message sera envoyé à syslog.

Ci-dessous figure un exemple d'utilisation de la directive :

maxchange 1000 1 2

Après la première mise à jour de l'horloge, chronyd vérifiera le décalage sur chaque mise à jour de l'horloge, ignorera deux ajustements de plus de 1000 secondes et quittera lors d'un ajustement ultérieur.

L'une des tâches de chronyd consiste à trouver à quelle vitesse l'horloge de l'ordinateur fonctionne comparé à ses sources de référence. En outre, une estimation des limites de l'erreur est calculée autour de l'estimation. Si la marge d'erreurs est trop importante, cela indique que les mesures n'ont pas encore été paramétrées et que la vitesse estimée de gain ou de perte n'est pas très fiable. Le paramètre maxupdateskew correspond à la limite pour déterminer si une estimation n'est pas assez fiable pour être utilisée. Par défaut, la limite est de 1000 ppm. Le format de la syntaxe est comme suit :

maxupdateskew skew-in-ppm

Des valeurs typiques de skew-in-ppm peuvent s'élever à 100 pour une connexion téléphonique de serveurs à travers une ligne téléphonique, et à 5 ou 10 pour un ordinateur sur un réseau LAN. Remarquez qu'il ne s'agit pas de l'unique moyen de protection contre l'utilisation d'estimations non fiables. À tout moment, chronyd conserve la trace des vitesses estimées de gain ou de perte, et de la limite d'erreur de l'estimation. Lorsqu'une nouvelle estimation est générée suivant une autre mesure de l'une des sources, un algorithme de combinaison pondéré est utilisé pour mettre à jour l'estimation maître. Ainsi. si chronyd possède une estimation maître très fiable et qu'une nouvelle estimation est générée avec une marge d'erreurs supérieure, l'esimation maître existante prévaudra sur la nouvelle estimation maître.

Cette directive, qui ne reçoit aucun argument, indique que les accès client ne doivent pas être journalisés. Ceux-ci sont normalement journalisés, permettant ainsi aux statistiques d'être rapportées en utilisant la commande client dans chronyc.

Lorsque chronyd sélectionne une source de synchronisation parmi les sources disponibles, une source avec une distance de synchronisation minimale est préférable. Cependant, pour éviter une resélection fréquente lorsqu'il se trouve plusieurs sources à une distance similaire, une distance fixe est ajoutée à la distance des sources qui ne sont pas sélectionnées. Cette distance peut être définie avec l'option reselectdist. Par défaut, la distance s'élève à 100 microsecondes.

Le format de la syntaxe est comme suit :

reselectdist dist-in-seconds

La directive stratumweight définit la distance devant être ajoutée par stratum à la distance de synchronisation lorsque chronyd sélectionne la source de synchronisation parmi les sources disponibles.

Le format de la syntaxe est comme suit :

stratumweight dist-in-seconds

Par défaut, la valeur de dist-in-seconds s'élève à 1 seconde. Cela signifie que les sources possédant un stratum plus bas sont normalement préférées aux sources avec un stratum plus élevé, même lorsque leur distance est significativement plus élevée. Définir stratumweight sur 0 cause à chronyd d'ignorer le stratum lors de la sélection de la source.

La directive rtcfile définit le nom du fichier dans lequel chronyd peut enregistrer les paramètres associés au suivi de la précision de l'horloge temps réel (RTC) du système. Le format de la syntaxe est comme suit :

rtcfile /var/lib/chrony/rtc

chronyd enregistre les informations dans ce fichier lorsqu'il se ferme et quand la commande writertc est exécutée dans chronyc. Les informations enregistrées contiennent l'erreur de l'horloge RTC à une certaine époque, cette époque (en secondes depuis le 1er janvier 1970), et la vitesse à laquelle l'horloge RTC gagne ou perd du temps. Toutes les horloges RTC ne sont pas prises en charge car leur code est spécifique au système. Remarquez que si cette directive est utilisée, alors l'horloge RTC ne devrait pas être ajustée manuellement car cela interfère avec le besoin de chrony de mesurer la vitesse à laquelle l'horloge dérive si elle est ajustée à des intervalles aléatoires.

La directive rtcsync est présente dans le fichier /etc/chrony.conf par défaut. Cela informera le noyau que l'horloge système est synchronisée et que le noyau mettra à jour l'horloge RTC toutes les 11 minutes.