La plupart des gens gardent une trace du temps. Nous nous levons à l'heure pour terminer nos rituels du matin et aller au travail, prendre une pause déjeuner, respecter les délais du projet, célébrer les anniversaires et les vacances, monter à bord d'un avion, etc.
De plus : certains d'entre nous sont obsédés par le temps. Ma montre est alimentée par l'énergie solaire et obtient l'heure exacte du National Institute of Standards and Technology () à Fort Collins, Colorado par radio à ondes longues . Les signaux horaires sont synchronisés avec l'horloge atomique, également située à Fort Collins. Mon Fitbit se synchronise avec mon téléphone qui se synchronise avec le serveur , qui finit par se synchroniser avec l'horloge atomique.
Les appareils gardent également une trace du temps
Il existe de nombreuses raisons pour lesquelles nos appareils et ordinateurs ont besoin d'une heure précise. Par exemple, dans les banques, les marchés boursiers et d'autres activités financières, les transactions doivent être effectuées dans le bon ordre, et des séquences temporelles précises sont essentielles à cet égard.
Nos téléphones, tablettes, voitures, systèmes GPS et ordinateurs nécessitent tous des réglages précis de l'heure et de la date. Je veux que l'horloge sur le bureau de mon ordinateur affiche l'heure exacte. Je veux que les rappels apparaissent sur mon calendrier local au bon moment. L'heure correcte garantit également que les tâches cron et systemd s'exécutent à l'heure correcte.
La date et l'heure sont également importantes pour la journalisation, il est donc un peu plus facile de trouver certains journaux en fonction de la date et de l'heure. Par exemple, j'ai déjà travaillé dans DevOps (on ne l'appelait pas ainsi à l'époque) et je mettais en place un système de messagerie dans l'État de Caroline du Nord. Nous traitions plus de 20 millions d'e-mails par jour. Le suivi des e-mails via une série de serveurs ou la détermination de la séquence exacte des événements à l'aide de fichiers journaux sur des hôtes géographiquement dispersés peut être beaucoup plus facile si les ordinateurs respectifs sont synchronisés dans le temps.
Une fois - plusieurs heures
Les hôtes Linux doivent tenir compte du fait qu'il existe une heure système et une heure RTC. RTC (Real Time Clock) est un nom un peu étrange et pas très précis pour une horloge matérielle.
L'horloge matérielle fonctionne en continu même lorsque l'ordinateur est éteint, en utilisant la batterie de la carte mère du système. La fonction principale du RTC est de stocker l'heure lorsqu'une connexion à un serveur de temps n'est pas disponible. À l'époque où il était impossible de se connecter à un serveur de temps via Internet, chaque ordinateur devait disposer d'une horloge interne précise. Les systèmes d'exploitation devaient accéder au RTC au moment du démarrage et l'utilisateur devait régler manuellement l'heure du système à l'aide de l'interface de configuration matérielle du BIOS pour s'assurer qu'elle était correcte.
Les horloges matérielles ne comprennent pas le concept de fuseaux horaires ; RTC ne stocke que l'heure, pas le fuseau horaire ou le décalage par rapport à UTC (Coordinated Universal Time, également connu sous le nom de GMT ou Greenwich Mean Time). Vous pouvez installer RTC à l'aide d'un outil dont je parlerai plus loin dans cet article.
L'heure système est l'heure que le système d'exploitation affiche sur l'horloge de l'interface graphique de votre bureau, dans la sortie de la commande date, dans les horodatages des journaux. Cela s'applique également au moment où les fichiers sont créés, modifiés et ouverts.
Sur la page il y a une description complète du RTC et de l'horloge système.
C'est quoi le NTP ?
Les ordinateurs du monde entier utilisent NTP (Network Time Protocol) pour synchroniser leur heure avec des horloges de référence standard sur Internet à l'aide d'une hiérarchie de serveurs NTP. Les principaux serveurs de temps sont au niveau 1 et ils sont directement connectés aux différents services horaires nationaux au niveau 0 via satellite, radio ou même modems sur lignes téléphoniques. Les services de temps de couche 0 peuvent être une horloge atomique, un récepteur radio qui est réglé sur les signaux transmis par des horloges atomiques ou un récepteur GPS qui utilise des signaux d'horloge très précis transmis par des satellites GPS.
La grande majorité des serveurs de référence disposent de plusieurs milliers de serveurs publics NTP stratum 2 ouverts au public. De nombreuses organisations et utilisateurs (moi y compris) avec de nombreux hôtes qui ont besoin d'un serveur NTP choisissent de configurer leurs propres serveurs de temps afin qu'un seul hôte local accède à la strate 2 ou 3. Ils configurent ensuite les nœuds restants sur le réseau pour utiliser le local serveur de temps. Dans le cas de mon réseau domestique, il s'agit d'un serveur de couche 3.
Diverses implémentations de NTP
L'implémentation originale de NTP est ntpd. Il a ensuite été rejoint par deux nouveaux, chronyd et systemd-timesyncd. Tous 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 est suffisant dans la plupart des cas. Si le RTC n'est pas synchronisé, il peut ajuster progressivement l'heure du système pour se synchroniser avec le serveur NTP lorsque l'heure du système local dérive légèrement. Le service systemd-timesync ne peut pas être utilisé comme serveur de temps.
est une implémentation de NTP qui contient deux programmes : le démon chronyd et une interface de ligne de commande appelée chronyc. Chrony possède certaines fonctionnalités indispensables dans de nombreux cas :
- Chrony peut se synchroniser avec un serveur de temps beaucoup plus rapidement que l'ancien service ntpd. C'est bon pour les ordinateurs portables ou les ordinateurs de bureau qui ne fonctionnent pas tout le temps.
- Il peut compenser les fluctuations d'horloge, par exemple lorsque l'hôte se met en veille ou entre en mode veille, ou lorsque l'horloge change en raison d'un saut de fréquence, ce qui ralentit les horloges à faible charge.
- Il résout les problèmes de temps liés à une connexion réseau instable ou à la congestion du réseau.
- Il régule les retards du réseau.
- Après la synchronisation initiale de l'heure, Chrony n'arrête jamais l'horloge. Cela fournit des plages horaires stables et cohérentes pour de nombreux services et applications système.
- Chrony peut fonctionner même sans connexion réseau. Dans ce cas, l'hôte ou le serveur local peut être mis à jour manuellement.
- Chrony peut agir comme un 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 RPM NTP, Chrony et systemd-timesyncd sont disponibles dans les référentiels Fedora standard. Le RPM systemd-udev est un gestionnaire d'événements du noyau qui est installé par défaut sur Fedora, mais qui est facultatif.
Vous pouvez installer les trois et basculer entre eux, mais cela créera un mal de tête supplémentaire. Il vaut donc mieux ne pas le faire. Les versions modernes de Fedora, CentOS et RHEL sont passées à Chrony comme implémentation par défaut, et elles ont également systemd-timesyncd. Je trouve que Chrony fonctionne bien, fournit une meilleure interface que le service NTP, fournit beaucoup plus d'informations et de contrôle, ce que les administrateurs système apprécieront certainement.
Désactivation des services NTP
Le service NTP est peut-être déjà en cours d'exécution sur votre hôte. Si c'est le cas, vous devez le désactiver avant de passer à autre chose. J'avais chronyd en cours d'exécution, j'ai donc 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 exécutez 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 - NTP client/server
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 du statut avant le lancement
L'état de synchronisation de l'horloge système vous permet de déterminer si le service NTP est en cours d'exécution. Puisque vous n'avez pas encore démarré NTP, la commande timesync-status indiquera ceci :
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Une demande de statut directe fournit des informations importantes. Par exemple, la commande timedatectl sans argument ni option exécute la sous-commande status par défaut :
[root@testvm1 ~]# timedatectl status
Local time: Fri 2020-05-15 08:43:10 EDT
Universal time: Fri 2020-05-15 12:43:10 UTC
RTC time: Fri 2020-05-15 08:43:08
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#Cela vous donnera l'heure locale de votre hôte, l'heure UTC et l'heure RTC. Dans ce cas, l'heure du système est définie sur le fuseau horaire America / New_York (TZ), le RTC est défini sur l'heure du fuseau horaire local et le service NTP n'est pas actif. L'heure RTC a commencé à s'écarter légèrement de l'heure système. Ceci est normal pour les systèmes dont les horloges n'ont pas été synchronisées. La quantité de décalage sur l'hôte dépend du temps qui s'est é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 s'applique aux changements de fuseau horaire et aux paramètres DST. Si l'ordinateur est éteint lorsque des modifications doivent être apportées, le RTC ne changera pas. Mais pour les serveurs ou autres hôtes qui fonctionnent XNUMX heures sur XNUMX, ce n'est pas du tout un problème. De plus, tout service qui fournit la synchronisation de l'heure NTP ajustera l'heure de l'hôte pendant la phase de démarrage initiale, de sorte que l'heure sera à nouveau correcte une fois le démarrage terminé.
Réglage du fuseau horaire
Habituellement, vous spécifiez le fuseau horaire lors de la procédure d'installation et vous n'avez pas la tâche de le modifier ultérieurement. Cependant, il y a des moments où vous devez changer le fuseau horaire. Il existe plusieurs outils qui peuvent vous aider. Linux utilise des fichiers de fuseau horaire pour déterminer le fuseau horaire local d'un hôte. Ces fichiers se trouvent dans le répertoire /usr/share/zoneinfo. Par défaut, pour mon fuseau horaire, le système prescrit ceci : /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Mais vous n'avez pas besoin de connaître de telles subtilités pour changer le fuseau horaire.
L'essentiel est de connaître le nom officiel du fuseau horaire de votre emplacement et la commande correspondante. Supposons que vous souhaitiez changer le fuseau horaire pour Los Angeles :
[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
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
<SNIP>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
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#Vous pouvez maintenant modifier le fuseau horaire de votre hôte pour revenir à l'heure locale.
systemd-timesyncd
Le démon systemd timesync fournit une implémentation NTP facile à gérer dans le contexte systemd. Il est installé par défaut sur Fedora et Ubuntu. Cependant, il ne démarre que par défaut sur Ubuntu. Je ne suis pas sûr des autres distributions. Vous pouvez vérifier par vous-même :
[root@testvm1 ~]# systemctl status systemd-timesyncdConfiguration de systemd-timesyncd
Le fichier de configuration de systemd-timesyncd est /etc/systemd/timesyncd.conf. Il s'agit d'un fichier simple avec moins d'options activées que les anciens services NTP et chronyd. Voici le contenu de ce fichier (sans autres modifications) sur ma VM 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=2048La 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 et ne doivent pas être modifiées (sauf si vous avez une raison de le faire). Si vous n'avez pas de serveur de temps NTP défini dans la ligne NTP=, Fedora utilise par défaut un serveur de temps Fedora de secours. J'ajoute généralement mon serveur de temps :
NTP=myntpserverSynchronisation de l'heure en cours d'exécution
Vous pouvez démarrer et activer systemd-timesyncd comme ceci :
[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 ~]#Réglage de l'horloge matérielle
Voici à quoi ressemble la situation après l'exécution de timesyncd :
[root@testvm2 systemd]# timedatectl
Local time: Sat 2020-05-16 14:34:54 EDT
Universal time: Sat 2020-05-16 18:34:54 UTC
RTC time: Sat 2020-05-16 14:34:53
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no Initialement, la différence entre le RTC et l'heure locale (EDT) est inférieure à une seconde, et l'écart augmente de quelques secondes supplémentaires au cours des prochains jours. Puisqu'il n'y a pas de concept de fuseaux horaires dans RTC, la commande timedatectl doit effectuer une comparaison pour déterminer le fuseau horaire correct. Si l'heure RTC ne correspond pas exactement à l'heure locale, elle ne correspond pas non plus au fuseau horaire local.
À la recherche de plus d'informations, j'ai vérifié l'état de systemd-timesync et j'ai trouvé ceci :
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
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: "Initial synchronization to time server 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]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Notez le message du journal indiquant que l'heure du système n'a pas été définie ou a été réinitialisée. Le service Timesync définit l'heure système en fonction de l'horodatage. Les horodatages sont conservés par le démon timesync et sont créés à chaque synchronisation réussie.
La commande timedatectl n'a aucun moyen de prendre la valeur de l'horloge matérielle à partir de l'horloge système. Il ne peut régler l'heure et la date qu'à partir de la valeur entrée sur la ligne de commande. Vous pouvez définir le RTC sur la même valeur que l'heure système à l'aide de la commande hwclock :
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Local time: Mon 2020-05-18 13:56:46 EDT
Universal time: Mon 2020-05-18 17:56:46 UTC
RTC time: Mon 2020-05-18 13:56:46
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yesL'option --localtime indique à l'horloge matérielle d'afficher l'heure locale, et non UTC.
Pourquoi avez-vous besoin de RTC ?
Toute implémentation de NTP règlera l'horloge système au moment du démarrage. Et pourquoi alors RTC ? Ce n'est pas tout à fait vrai : cela ne se produira que si vous disposez d'une connexion réseau au serveur de temps. Cependant, de nombreux systèmes n'ont pas toujours accès à une connexion réseau, donc une horloge matérielle est utile pour que Linux l'utilise pour régler l'heure du système. C'est mieux que de régler manuellement l'heure, même si elle peut s'écarter de l'heure réelle.
Conclusion
Cet article a passé en revue certains outils permettant de manipuler 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 de serveur, donc si vous avez besoin d'un serveur NTP sur votre réseau, vous devez utiliser autre chose, comme Chrony, pour agir en tant que serveur.
Je préfère avoir une seule implémentation pour n'importe quel service sur mon réseau, j'utilise donc Chrony. Si vous n'avez pas besoin d'un serveur NTP local, ou si cela ne vous dérange pas d'utiliser Chrony comme serveur et systemd-timesyncd comme client SNTP. Après tout, il n'est pas nécessaire d'utiliser les fonctionnalités supplémentaires de Chrony en tant que client si vous êtes satisfait de la fonctionnalité de systemd-timesyncd.
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 NTP. Après tout, systemd est composé d'un grand nombre de services ; beaucoup d'entre eux sont facultatifs, vous pouvez donc les désactiver et utiliser autre chose à la place. Ce n'est pas un énorme monstre monolithique. Vous n'aimez peut-être pas systemd ou certaines parties de celui-ci, mais vous devez prendre une décision éclairée.
J'aime l'implémentation de NTP par systemd, mais je préfère Chrony car il répond mieux à mes besoins. C'est Linux, bébé -)
Comme la publicité
Les offres VDSina , une vaste sélection de systèmes d'exploitation pour une installation automatique, il est possible d'installer n'importe quel système d'exploitation à partir du vôtre , confortable propre développement et paiement quotidien. Rappelons que nous avons des serveurs éternels qui sont décidément intemporels 😉
Source: habr.com