🥇Synchronisation de l'heure sous Linux : NTP, Chrony et systemd-timesyncd

La plupart des gens surveillent le temps. Nous nous levons à l'heure pour accomplir nos rituels matinaux, aller au travail, faire une pause déjeuner, respecter les délais de projet, célébrer les anniversaires et les fêtes, prendre un avion, etc.

De plus, certains d'entre nous sont obsédés par le temps. Mes montres sont alimentées par énergie solaire et reçoivent l'heure exacte de l'Institut national des standards et de la technologie (NIST) à Fort Collins, dans le Colorado, par l'intermédiaire d'une station de radio à ondes longues. WWVB. Les signaux temporels sont synchronisés avec des horloges atomiques également situées à Fort Collins. Mon Fitbit se synchronise avec mon téléphone, qui se synchronise avec le serveur NTP, qui, en fin de compte, se synchronise avec les horloges atomiques.

Les appareils surveillent aussi le temps.

Il existe de nombreuses raisons pour lesquelles nos appareils et ordinateurs ont besoin d'une heure précise. Par exemple, dans le secteur bancaire, sur les marchés boursiers et dans d'autres entreprises financières, les transactions doivent être effectuées dans un ordre approprié, et il est crucial d'avoir des séquences temporelles précises.

Nos téléphones, tablettes, voitures, systèmes GPS et ordinateurs nécessitent un réglage précis de l'heure et de la date. Je veux que l'horloge sur le bureau de mon ordinateur affiche l'heure correcte. Je veux que les rappels dans mon calendrier local apparaissent au bon moment. Une heure correcte garantit également que les tâches cron et systemd s'exécutent au bon moment.

La date et l'heure sont également importantes pour la tenue de journaux, ce qui simplifie la recherche de logs en se basant sur la date et l'heure. Par exemple, un jour, je travaillais en DevOps (à l'époque, ce terme n'était pas encore utilisé) et je mettais en place un système de messagerie en Caroline du Nord. Autrefois, nous traitions plus de 20 millions d'emails par jour. Suivre les emails à travers une série de serveurs ou déterminer la séquence exacte des événements en utilisant des fichiers journaux sur des hôtes géographiquement dispersés peut être beaucoup plus simple si les ordinateurs concernés sont synchronisés au niveau temporel.

Il y a une heure, mais beaucoup d'horloges.

Les hôtes Linux doivent prendre en compte qu'il existe un temps système et un temps RTC. RTC (Horloge Temps Réel) est un nom légèrement étrange et pas vraiment précis pour des horloges matérielles.

Les horloges matérielles fonctionnent en continu, même lorsque l'ordinateur est éteint, en utilisant une batterie sur la carte mère du système. La fonction principale du RTC est de conserver l'heure lorsque la connexion au serveur de temps est indisponible. À une époque où il n'était pas possible de se connecter à un serveur de temps via Internet, chaque ordinateur devait avoir des horloges internes précises. Les systèmes d'exploitation devaient interroger le RTC au démarrage, et l'utilisateur devait régler manuellement le temps système via l'interface matérielle de configuration du BIOS pour s'assurer qu'il était correct.

Les horloges matérielles ne comprennent pas le concept des fuseaux horaires; le RTC ne conserve que l'heure, pas le fuseau horaire ou le décalage par rapport à l'UTC (Temps Universel Coordonné, également connu sous le nom de GMT ou Temps Moyen de Greenwich). Vous pouvez régler le RTC à l'aide d'un outil dont je parlerai plus tard dans cet article.

Le temps système est l'heure que le système d'exploitation affiche sur l'horloge GUI de votre bureau, dans la sortie de la commande date, et dans les horodatages des journaux. Cela fait également référence à l'heure de création, de modification et d'ouverture des fichiers.

Sur la page man pour rtc il y a une description complète du RTC et des horloges système.

Que se passe-t-il avec NTP?

Les ordinateurs du monde entier utilisent NTP (Network Time Protocol) pour synchroniser leur heure avec des horloges étalon standard via Internet en utilisant une hiérarchie de serveurs NTP. Les serveurs de temps principaux se trouvent au niveau 1 et sont directement connectés à divers services nationaux de temps au niveau 0 via satellite, radio ou même modems sur des lignes téléphoniques. Les services de temps au niveau 0 peuvent être des horloges atomiques, un récepteur radio réglé sur les signaux transmis par les horloges atomiques, ou un récepteur GPS utilisant des signaux horaires très précis transmis par des satellites GPS.

Sur la plupart des serveurs de référence, plusieurs milliers de serveurs NTP stratum 2 sont ouverts et accessibles à tous. De nombreuses organisations et utilisateurs (y compris moi-même) avec un grand nombre d'hôtes nécessitant un serveur NTP préfèrent installer leurs propres serveurs de temps, afin qu'un seul hôte local se connecte aux stratum 2 ou 3. Ils configurent ensuite les nœuds restants du réseau pour utiliser le serveur de temps local. Dans le cas de mon réseau domestique, cela concerne un serveur de niveau 3.

Différentes implémentations de NTP

La première implémentation de NTP est ntpd. Deux autres plus récentes, chronyd et systemd-timesyncd, s'y sont ajoutées. Les trois synchronisent l'heure de l'hôte local avec un serveur de temps NTP. Le service systemd-timesyncd n'est pas aussi fiable que chronyd, mais il suffit pour la plupart des besoins. Si le RTC n'est pas synchronisé, il peut progressivement ajuster l'heure système pour se synchroniser avec le serveur NTP lorsque l'heure système locale est légèrement décalée. Le service systemd-timesync ne peut pas être utilisé comme serveur de temps.

Chrony est une implémentation de NTP, comprenant deux programmes : le démon chronyd et une interface en ligne de commande appelée chronyc. Chrony dispose de certaines fonctionnalités qui sont indispensables dans de nombreux cas :

Chrony peut se synchroniser avec un serveur de temps beaucoup plus rapidement que le vieux service ntpd. Cela est idéal pour les ordinateurs portables ou de bureau qui ne fonctionnent pas en permanence.
Il peut compenser les fluctuations de fréquence, par exemple, lorsque l'hôte passe en mode veille ou lorsqu'il entre en sommeil, ou lorsque la fréquence change en raison d'un ajustement brusque de la fréquence, ce qui ralentit les fréquences à faible charge.
Il résout les problèmes de temps liés à une connexion réseau instable ou à un engorgement du réseau.
Il ajuste les délais dans le réseau.
Après la synchronisation temporelle initiale, Chrony ne stoppe jamais les horloges. Cela garantit des intervalles de temps stables et cohérents pour de nombreux services systèmes et applications.
Chrony peut fonctionner même sans connexion réseau. Dans ce cas, l'hôte local ou le serveur peut être mis à jour manuellement.
Chrony peut agir en tant que serveur NTP.

Encore une fois : NTP est un protocole qui peut être implémenté sur un hôte Linux en utilisant Chrony ou systemd-timesyncd.

Les paquets RPM NTP, Chrony et systemd-timesyncd sont disponibles dans les dépôts standards de Fedora. Le paquet RPM systemd-udev est le gestionnaire d'événements du noyau, qui est installé par défaut dans Fedora, mais il n'est pas obligatoire.

Vous pouvez installer les trois et basculer entre eux, mais cela créera des tracas inutiles. Mieux vaut éviter. Les versions modernes de Fedora, CentOS et RHEL ont adopté Chrony comme implémentation standard, et en plus, ils disposent de systemd-timesyncd. Je trouve que Chrony fonctionne bien, offre une interface meilleure que le service NTP, fournit beaucoup plus d'informations et augmente le contrôle, ce qui plaira sans aucun doute aux administrateurs systèmes.

Désactivation des services NTP

Il est possible qu'un service NTP fonctionne déjà sur votre hôte. Si tel est le cas, vous devez le désactiver avant de passer à autre chose. J'avais chronyd en cours d'exécution, donc j'ai utilisé les commandes suivantes pour l'arrêter et le désactiver. Exécutez les commandes appropriées pour tout démon NTP que vous utilisez sur votre hôte :

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

Vérifiez que le service est arrêté et désactivé :

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - Client/serveur NTP
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

Vérification de l'état avant le démarrage

L'état de la synchronisation du système des horloges permet de déterminer si le service NTP est en cours d'exécution. Comme vous n'avez pas encore lancé NTP, la commande timesync-status le sous-entend :

[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

Une requête d'état directe fournit des informations importantes. Par exemple, la commande timedatectl sans argument ou paramètre exécute la sous-commande status par défaut :

[root@testvm1 ~]# timedatectl status
           Heure locale : ven. 15 mai 2020 08:43:10 EDT  
           Heure universelle : ven. 15 mai 2020 12:43:10 UTC  
                 Heure RTC : ven. 15 mai 2020 08:43:08      
                Fuseau horaire : America/New_York (EDT, -0400)
Horloge système synchronisée : non                          
              Service NTP : inactif                    
          RTC dans le fuseau horaire local : oui                    

Avertissement : Le système est configuré pour lire l'heure RTC dans le fuseau horaire local.
         Ce mode ne peut pas être entièrement pris en charge. Il créera divers problèmes
         avec les changements de fuseau horaire et les ajustements d'heure d'été. L'heure RTC
         n'est jamais mise à jour, elle dépend des installations externes pour la maintenir.
         Si possible, utilisez RTC en UTC en appelant
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

Ainsi, vous obtiendrez l'heure locale de votre hôte, l'heure UTC et l'heure RTC. Dans ce cas, l'heure système est définie sur le fuseau horaire America/New_York (TZ), l'heure RTC est réglée sur l'heure du fuseau horaire local, et le service NTP n'est pas actif. L'heure RTC a commencé à dériver légèrement de l'heure système. C'est normal pour les systèmes dont l'horloge n'a pas été synchronisée. L'ampleur du décalage sur l'hôte dépend du temps écoulé depuis la dernière synchronisation du système.

Nous avons également reçu un avertissement concernant l'utilisation de l'heure locale pour le RTC — cela concerne les changements de fuseau horaire et les réglages d'heure d'été. Si l'ordinateur est éteint au moment où des modifications doivent être apportées, l'heure RTC ne changera pas. Mais pour les serveurs ou d'autres hôtes qui fonctionnent 24/7, ce n'est pas un problème. De plus, tout service assurant la synchronisation du temps NTP corrigera l'heure de l'hôte encore au début du démarrage, donc après le démarrage, l'heure sera à nouveau correcte.

Configuration du fuseau horaire

En général, vous indiquez le fuseau horaire lors de la procédure d'installation, et vous n'avez pas à le changer par la suite. Cependant, il existe des cas où il est nécessaire de changer le fuseau horaire. Plusieurs outils peuvent vous aider. Pour déterminer le fuseau horaire local, Linux utilise des fichiers de fuseau horaire. Ces fichiers se trouvent dans le répertoire /usr/share/zoneinfo. Par défaut, pour mon fuseau horaire, le système définit ceci : /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Mais vous n'avez pas besoin de connaître ces détails pour changer le fuseau horaire.

L'essentiel est de connaître le nom officiel du fuseau horaire de votre emplacement et la commande correspondante. Disons que vous souhaitez changer le fuseau horaire sur Los Angeles :


[root@testvm2 ~]# timedatectl list-timezones | column

America/La_Paz                  Europe/Budapest
America/Lima                    Europe/Chisinau
America/Los_Angeles             Europe/Copenhagen
America/Maceio                  Europe/Dublin
America/Managua                 Europe/Gibraltar
America/Manaus                  Europe/Helsinki

Vous pouvez maintenant définir le fuseau horaire. J'ai utilisé la commande date pour vérifier les changements, mais vous pouvez également utiliser timedatectl :

[root@testvm2 ~]# date
Mar 19 Mai 2020 16:47:49 EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Mar 19 Mai 2020 13:48:23 PDT
[root@testvm2 ~]#

Vous pouvez désormais changer le fuseau horaire de votre hôte en heure locale.

systemd-timesyncd

Le démon systemd timesync fournit une implémentation NTP facilement gérable dans le contexte de systemd. Il est installé par défaut dans Fedora et Ubuntu. Cependant, il n'est lancé par défaut que dans Ubuntu. Je ne suis pas sûr pour les autres distributions. Vous pouvez vérifier vous-même :

[root@testvm1 ~]# systemctl status systemd-timesyncd

Configuration de systemd-timesyncd

Le fichier de configuration pour systemd-timesyncd est /etc/systemd/timesyncd.conf. C'est un fichier simple avec moins d'options activées que les anciens services NTP et chronyd. Voici le contenu de ce fichier (sans modifications supplémentaires) sur ma machine virtuelle Fedora :

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

La seule section qu'il contient, en plus des commentaires, est [Time]. Toutes les autres lignes sont commentées. Ce sont les valeurs par défaut, elles n'ont pas besoin d'être modifiées (s'il n'y a pas de raison de le faire). Si vous n'avez pas de serveur NTP spécifié dans la ligne NTP =, un serveur NTP de secours de Fedora est utilisé par défaut. J'ajoute généralement mon serveur NTP :

NTP=myntpserver

Lancement de timesync

Vous pouvez démarrer et activer systemd-timesyncd de cette manière :

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#

Configuration des horloges matérielles

Voici à quoi ressemble la situation après le lancement de timesyncd :

[root@testvm2 systemd]# timedatectl
               Heure locale : Sam 2020-05-16 14:34:54 EDT  
           Heure universelle : Sam 2020-05-16 18:34:54 UTC  
                 Heure RTC : Sam 2020-05-16 14:34:53      
                Fuseau horaire : America/New_York (EDT, -0400)
Horloge système synchronisée : oui                          
              Service NTP : actif                      
          RTC dans le fuseau horaire local : non

Au départ, la différence entre l'heure RTC et l'heure locale (EDT) ne dépasse pas une seconde, et l'écart augmente encore de quelques secondes au cours des jours suivants. Comme les RTC n'ont pas de notion de fuseaux horaires, l'équipe de timedatectl doit effectuer une comparaison pour déterminer le fuseau horaire approprié. Si l'heure RTC ne correspond pas exactement à l'heure locale, alors cela signifie qu'elle ne correspond pas non plus au fuseau horaire local.

À la recherche d'informations supplémentaires, j'ai vérifié l'état de systemd-timesync et j'ai trouvé ce qui suit :

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Synchronisation de l'heure réseau
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 822 (systemd-timesyn)
     Status: "Synchronisation initiale avec le serveur de temps 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tasks: 2 (limit: 10365)
     Memory: 2.8M
        CPU: 476ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

May 16 09:57:24 testvm2.both.org systemd[1]: Démarrage de la synchronisation de l'heure réseau...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: L'heure de l'horloge système n'est pas réglée ou a été réinitialisée, restauration à partir du timestamp enregistré: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Synchronisation de l'heure réseau démarrée.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Synchronisation initiale avec le serveur de temps 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

Notez le message du journal, qui indique que l'heure système n'est pas réglée ou a été réinitialisée. Le service Timesync règle l'heure système en fonction de l'horodatage. Les horodatages sont maintenus par le démon timesync et sont créés à chaque synchronisation réussie.

La commande timedatectl n'a pas la capacité de prendre la valeur de l'horloge matérielle depuis l'horloge système. Elle peut uniquement régler l'heure et la date selon la valeur entrée dans la ligne de commande. Vous pouvez régler le RTC sur la même valeur que l'heure système en utilisant la commande hwclock :

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Heure locale : Mon 2020-05-18 13:56:46 EDT  
           Heure universelle : Mon 2020-05-18 17:56:46 UTC  
                 Heure RTC : Mon 2020-05-18 13:56:46      
                Fuseau horaire : America/New_York (EDT, -0400)
Horloge système synchronisée : oui                          
              Service NTP : actif                      
          RTC dans le TZ local : oui

L'option —localtime indique que l'horloge matérielle affiche l'heure locale, et non l'UTC.

Pourquoi avez-vous besoin d'un RTC ?

Toute implémentation de NTP définira l'heure système au démarrage. Alors, à quoi sert RTC ? Ce n'est pas tout à fait vrai : cela se produira seulement si vous avez une connexion réseau avec un serveur horaire. Cependant, de nombreux systèmes n'ont pas un accès constant à une connexion réseau, donc les horloges matérielles sont utiles pour que Linux puisse définir l'heure système en fonction d'elles. C'est mieux que de régler l'heure manuellement, même si cela peut différer du temps réel.

Conclusion

Cet article examine quelques outils pour gérer la date, l'heure et les fuseaux horaires. L'outil systemd-timesyncd fournit un client NTP qui peut synchroniser l'heure sur l'hôte local avec un serveur NTP. Cependant, systemd-timesyncd ne fournit pas de service serveur, donc si vous avez besoin d'un serveur NTP dans votre réseau, vous devez utiliser autre chose — par exemple, Chrony, pour fonctionner comme serveur.

Je préfère avoir une seule implémentation pour tous les services de mon réseau, c'est pourquoi j'utilise Chrony. Si vous n'avez pas besoin d'un serveur NTP local ou si vous êtes d'accord pour utiliser Chrony comme serveur et systemd-timesyncd comme client SNTP. Il n'est pas nécessaire d'utiliser les fonctionnalités supplémentaires de Chrony en tant que client si vous êtes satisfait des fonctionnalités de systemd-timesyncd.

Une autre remarque : vous n'êtes pas obligé d'utiliser les outils systemd pour implémenter NTP. Vous pouvez utiliser une ancienne version de ntpd, Chrony ou une autre implémentation de NTP. En effet, systemd se compose de nombreux services ; beaucoup d'entre eux ne sont pas indispensables, vous pouvez donc les désactiver et utiliser autre chose à la place. Ce n'est pas un monstre monolithique énorme. Vous n'avez pas à aimer systemd ou ses parties, mais vous devez prendre une décision éclairée.

J'aime l'implémentation de NTP dans systemd, mais je préfère Chrony, car il répond mieux à mes besoins. C'est Linux, bébé -)

En tant que publicité

VDSina propose serveurs pour tous les besoins, un vaste choix de systèmes d'exploitation à installer automatiquement, il est possible d'installer n'importe quel OS à partir de votre propre ISO, pratique le panneau de contrôle développement interne et un paiement quotidien. Rappelons que nous avons des serveurs éternels, qui sont véritablement intemporels 😉

Source : habr.com