Différences entre versions de « Chrony »
| Ligne 35 : | Ligne 35 : | ||
# firewall-cmd --reload | # firewall-cmd --reload | ||
</pre> | </pre> | ||
| + | |||
| + | = Cas des machines virtuelles = | ||
| + | Sur une machine virtuelle qui peut être mise en pause, le décalage va être supérieur à la valeur fixée dans la configuration précédente par ''makestep'' très rapidement. | ||
| + | |||
| + | Dans l'exemple précédent la mise à jour se fait uniquement les trois première fois quand le décalage est supérieurs à 1 seconde: | ||
| + | <pre> | ||
| + | makestep 1.0 3 | ||
| + | </pre> | ||
| + | |||
| + | Si vous voulez que chrony fasse la mise à jour tout le temps, il suffit de modifier la directive ''makestep'' avec la valeur ''-1'': | ||
| + | <pre> | ||
| + | makestep 1.0 -1 | ||
| + | </pre> | ||
| + | |||
| + | Le comportement de base de chrony est de retarder ou avancer progressivement l'horloge système pour ajuster le retard ou l'avance. Seulement quand la différence est trop importante, cela peut prendre longtemps... | ||
| + | |||
= Démarrage et automatisation = | = Démarrage et automatisation = | ||
<pre> | <pre> | ||
Version actuelle datée du 1 janvier 2022 à 07:09
Introduction
Nous avions l'habitude de NTP, il laisse maintenant la place à un nouveau service : Chrony !
Chrony se décompose en deux entités, une cliente chronyc, et une serveur chronyd. La partie serveur est démarrée sur la machine et la partie cliente va régulièrement interroger (toutes les 11 minute sur un Linux) la partie serveur pour ajuster l'horloge.
Installation
# yum -y install chrony
Configuration
Le fichier "/etc/chrony.conf" est le fichier de configuration qui sera utilisé par le client Chrony pour mettre à jour l'heure du système. Dans ce fichier, il faut plusieurs chose:
- driftfile → permet de définir le fichier dans lequel sera stocké le glissement (dirft) du quartz interne de la machine par rapport au temps de l'horloge atomique (sur Internet);
- server → permet de définir le ou les serveurs NTP à utiliser.
- rtcsync → permet de synchroniser l'heure de la carte mère avec Chrony.
- makestep → la correction se fait soit en ralentissant ou en accélérant l'horloge. Si le décalage est trop important, il vaut mieux faire un saut.
Voici un exemple de fichier de configuration minimal
server foo.example.net iburst server bar.example.net iburst server baz.example.net iburst driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync allow 127.0.0.1/32
N'oubliez pas la dernière ligne sous peine de ne pas autoriser le client de la même machine à parler au serveur Chrony. Vous pouvez remplacer 127.0.0.1/32 par un autre réseau et ouvrir un port du pare-feu pour autoriser d'autre machine à se synchroniser :
- iptables
# iptables -I INPUT 2 -p udp --dport 123 -j ACCEPT
- firewalld
# firewall-cmd --add-service=ntp --permanent # firewall-cmd --reload
Cas des machines virtuelles
Sur une machine virtuelle qui peut être mise en pause, le décalage va être supérieur à la valeur fixée dans la configuration précédente par makestep très rapidement.
Dans l'exemple précédent la mise à jour se fait uniquement les trois première fois quand le décalage est supérieurs à 1 seconde:
makestep 1.0 3
Si vous voulez que chrony fasse la mise à jour tout le temps, il suffit de modifier la directive makestep avec la valeur -1:
makestep 1.0 -1
Le comportement de base de chrony est de retarder ou avancer progressivement l'horloge système pour ajuster le retard ou l'avance. Seulement quand la différence est trop importante, cela peut prendre longtemps...
Démarrage et automatisation
# systemctl start chronyd # systemctl enable chronyd
Vérification de fonctionnement
On va vérifier la connectivité avec les serveur NTP:
# chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^+ ntp.marwan.ma 2 7 377 59 -45ms[ -45ms] +/- 232ms ^? 2003:a:47f:abe4:48ba:cd4> 0 6 0 - +0ns[ +0ns] +/- 0ns ^* bandersnatch.rondie.cyso> 3 8 377 119 -157ms[ -160ms] +/- 269ms