Linux-Zeitsynchronisierung: NTP, Chrony und systemd-timesyncd

Die meisten Menschen behalten die Zeit im Auge. Wir stehen pünktlich auf, um unsere Morgenrituale zu erfüllen und zur Arbeit zu gehen, machen eine Mittagspause, halten Projekttermine ein, feiern Geburtstage und Feiertage, steigen in ein Flugzeug und so weiter.

Außerdem: Manche von uns sind von der Zeit besessen. Meine Uhr wird mit Solarenergie betrieben und erhält die genaue Zeit vom National Institute of Standards and Technology (NIST) per Langwellenfunk nach Fort Collins, Colorado WWVB. Die Zeitsignale werden mit der Atomuhr synchronisiert, die sich ebenfalls in Fort Collins befindet. Mein Fitbit synchronisiert sich mit meinem Telefon, das wiederum mit dem Server synchronisiert wird NTP, die sich schließlich mit der Atomuhr synchronisiert.

Geräte verfolgen auch die Zeit

Es gibt viele Gründe, warum unsere Geräte und Computer eine genaue Zeit benötigen. Beispielsweise müssen im Bankwesen, an der Börse und in anderen Finanzgeschäften Transaktionen in der richtigen Reihenfolge ausgeführt werden, und genaue Zeitabläufe sind hierfür von entscheidender Bedeutung.

Unsere Telefone, Tablets, Autos, GPS-Systeme und Computer erfordern alle genaue Zeit- und Datumseinstellungen. Ich möchte, dass die Uhr auf dem Desktop meines Computers die richtige Zeit anzeigt. Ich möchte, dass Erinnerungen zur richtigen Zeit in meinem lokalen Kalender erscheinen. Die richtige Zeit stellt außerdem sicher, dass die Cron- und Systemd-Jobs zur richtigen Zeit ausgeführt werden.

Auch Datum und Uhrzeit sind für die Protokollierung wichtig, sodass es etwas einfacher ist, bestimmte Protokolle anhand von Datum und Uhrzeit zu finden. Ich habe zum Beispiel einmal im Bereich DevOps gearbeitet (das hieß damals noch nicht) und ein E-Mail-System im Bundesstaat North Carolina aufgebaut. Früher haben wir über 20 Millionen E-Mails pro Tag bearbeitet. Das Verfolgen von E-Mails über eine Reihe von Servern oder das Ermitteln der genauen Abfolge von Ereignissen mithilfe von Protokolldateien auf geografisch verteilten Hosts kann viel einfacher sein, wenn die jeweiligen Computer zeitlich synchronisiert sind.

Einmal – viele Stunden

Linux-Hosts müssen berücksichtigen, dass es eine Systemzeit und eine RTC-Zeit gibt. RTC (Real Time Clock) ist ein etwas seltsamer und nicht sehr genauer Name für eine Hardware-Uhr.

Die Hardware-Uhr läuft kontinuierlich, auch wenn der Computer ausgeschaltet ist, und nutzt dabei die Batterie auf der Hauptplatine des Systems. Die Hauptfunktion des RTC besteht darin, die Zeit zu speichern, wenn keine Verbindung zu einem Zeitserver verfügbar ist. In den Tagen, als es noch unmöglich war, über das Internet eine Verbindung zu einem Zeitserver herzustellen, musste jeder Computer über eine genaue interne Uhr verfügen. Betriebssysteme mussten beim Booten auf die RTC zugreifen und der Benutzer musste die Systemzeit manuell über die BIOS-Hardwarekonfigurationsschnittstelle einstellen, um sicherzustellen, dass sie korrekt war.

Hardware-Uhren verstehen das Konzept der Zeitzonen nicht; RTC speichert nur die Zeit, nicht die Zeitzone oder den Offset zur UTC (koordinierte Weltzeit, auch bekannt als GMT oder Greenwich Mean Time). Sie können RTC mit einem Tool installieren, das ich später in diesem Artikel behandeln werde.

Die Systemzeit ist die Zeit, die das Betriebssystem auf der GUI-Uhr auf Ihrem Desktop, in der Ausgabe des Datumsbefehls und in den Zeitstempeln der Protokolle anzeigt. Dies gilt auch für das Erstellen, Ändern und Öffnen von Dateien.

Auf Seite Mann für RTC Es gibt eine vollständige Beschreibung der RTC und der Systemuhr.

Was ist mit NTP?

Computer auf der ganzen Welt verwenden NTP (Network Time Protocol), um ihre Zeit über eine Hierarchie von NTP-Servern mit Standard-Referenzuhren über das Internet zu synchronisieren. Die wichtigsten Zeitserver befinden sich auf Schicht 1 und sind über Satellit, Funk oder sogar Modems über Telefonleitungen direkt mit verschiedenen nationalen Zeitdiensten auf Schicht 0 verbunden. Zeitdienste der Schicht 0 können eine Atomuhr, ein Funkempfänger, der auf die von Atomuhren übertragenen Signale abgestimmt ist, oder ein GPS-Empfänger sein, der hochpräzise Uhrsignale verwendet, die von GPS-Satelliten übertragen werden.

Die überwiegende Mehrheit der Referenzserver verfügt über mehrere tausend öffentliche NTP-Stratum-2-Server, die der Öffentlichkeit zugänglich sind. Viele Organisationen und Benutzer (ich eingeschlossen) mit vielen Hosts, die einen NTP-Server benötigen, entscheiden sich dafür, ihre eigenen Zeitserver einzurichten, sodass nur ein lokaler Host auf Stratum 2 oder 3 zugreift. Anschließend konfigurieren sie die verbleibenden Knoten im Netzwerk für die Verwendung des lokalen Zeitserver. Im Fall meines Heimnetzwerks handelt es sich um einen Layer-3-Server.

Verschiedene Implementierungen von NTP

Die ursprüngliche Implementierung von NTP ist ntpd. Dann kamen zwei neuere hinzu, chronyd und systemd-timesyncd. Alle drei synchronisieren die lokale Hostzeit mit einem NTP-Zeitserver. Der Dienst systemd-timesyncd ist nicht so zuverlässig wie chronyd, aber für die meisten Zwecke gut genug. Wenn die RTC nicht synchron ist, kann sie die Systemzeit schrittweise anpassen, um sie mit dem NTP-Server zu synchronisieren, wenn die lokale Systemzeit leicht abweicht. Der Dienst systemd-timesync kann nicht als Zeitserver verwendet werden.

Chronisch ist eine Implementierung von NTP, die zwei Programme enthält: den Chronyd-Daemon und eine Befehlszeilenschnittstelle namens Chronyc. Chrony verfügt über einige Funktionen, die in vielen Fällen unverzichtbar sind:

• Chrony kann sich viel schneller mit einem Zeitserver synchronisieren als der alte ntpd-Dienst. Dies ist gut für Laptops oder Desktops, die nicht ständig funktionieren.
• Es kann Taktschwankungen ausgleichen, beispielsweise wenn der Host in den Ruhezustand wechselt oder in den Schlafmodus wechselt, oder wenn sich die Uhr aufgrund von Frequenzsprüngen ändert, wodurch die Takte bei geringer Last verlangsamt werden.
• Es löst Zeitprobleme im Zusammenhang mit instabiler Netzwerkverbindung oder Netzwerküberlastung.
• Es reguliert Netzwerkverzögerungen.
• Nach der ersten Zeitsynchronisierung stoppt Chrony die Uhr nie mehr. Dies sorgt für stabile und konsistente Zeitfenster für viele Systemdienste und Anwendungen.
• Chrony kann auch ohne Netzwerkverbindung funktionieren. In diesem Fall kann der lokale Host oder Server manuell aktualisiert werden.
• Chrony kann als NTP-Server fungieren.

Auch hier handelt es sich bei NTP um ein Protokoll, das mit Chrony oder systemd-timesyncd auf einem Linux-Host implementiert werden kann.

Die NTP-, Chrony- und systemd-timesyncd-RPMs sind in den Standard-Fedora-Repositorys verfügbar. Das systemd-udev-RPM ist ein Kernel-Ereignismanager, der standardmäßig auf Fedora installiert ist, aber optional ist.

Sie können alle drei installieren und zwischen ihnen wechseln, aber das verursacht zusätzliche Kopfschmerzen. Also besser nicht. Moderne Versionen von Fedora, CentOS und RHEL wurden als Standardimplementierung auf Chrony umgestellt und verfügen außerdem über systemd-timesyncd. Ich finde, dass Chrony gut funktioniert, eine bessere Schnittstelle als der NTP-Dienst bietet und viel mehr Informationen und Kontrolle bietet, was Systemadministratoren sicherlich gefallen wird.

Deaktivieren von NTP-Diensten

Der NTP-Dienst läuft möglicherweise bereits auf Ihrem Host. Wenn ja, müssen Sie es deaktivieren, bevor Sie zu etwas anderem wechseln. Ich hatte Chronyd am Laufen, also habe ich die folgenden Befehle verwendet, um es zu stoppen und zu deaktivieren. Führen Sie die entsprechenden Befehle für jeden NTP-Daemon aus, den Sie auf Ihrem Host ausführen:

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

Überprüfen Sie, ob der Dienst gestoppt und deaktiviert ist:

[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 ~]#

Statusprüfung vor dem Start

Mithilfe des Synchronisierungsstatus der Systemuhr können Sie feststellen, ob der NTP-Dienst ausgeführt wird. Da Sie NTP noch nicht gestartet haben, weist der Befehl timesync-status darauf hin:

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

Eine direkte Statusabfrage liefert wichtige Informationen. Beispielsweise führt der Befehl timedatectl ohne Argumente oder Optionen standardmäßig den Unterbefehl status aus:

[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 ~]#

Dadurch erhalten Sie die Ortszeit Ihres Hosts, die UTC-Zeit und die RTC-Zeit. In diesem Fall wird die Systemzeit auf die Zeitzone Amerika / New_York (TZ) eingestellt, die RTC auf die Zeit in der lokalen Zeitzone und der NTP-Dienst ist nicht aktiv. Die RTC-Zeit beginnt leicht von der Systemzeit abzuweichen. Dies ist normal für Systeme, deren Uhren nicht synchronisiert wurden. Die Höhe des Offsets auf dem Host hängt von der Zeit ab, die seit der letzten Systemsynchronisierung vergangen ist.

Wir haben auch eine Warnung bezüglich der Verwendung der Ortszeit für RTC erhalten – dies gilt für Zeitzonenänderungen und Sommerzeiteinstellungen. Wenn der Computer ausgeschaltet ist, wenn Änderungen vorgenommen werden müssen, ändert sich die RTC nicht. Aber für Server oder andere Hosts, die rund um die Uhr laufen, ist das überhaupt kein Problem. Darüber hinaus passt jeder Dienst, der eine NTP-Zeitsynchronisierung bereitstellt, die Zeit des Hosts während der ersten Startphase an, sodass die Zeit nach Abschluss des Startvorgangs wieder korrekt ist.

Zeitzone einstellen

Normalerweise geben Sie die Zeitzone während des Installationsvorgangs an und haben nicht die Aufgabe, sie später zu ändern. Es kann jedoch vorkommen, dass Sie die Zeitzone ändern müssen. Es gibt mehrere Tools, die helfen können. Linux verwendet Zeitzonendateien, um die lokale Zeitzone des Hosts zu bestimmen. Diese Dateien befinden sich im Verzeichnis /usr/share/zoneinfo. Standardmäßig schreibt das System für meine Zeitzone Folgendes vor: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Aber Sie müssen solche Feinheiten nicht kennen, um die Zeitzone zu ändern.

Das Wichtigste ist, dass Sie den offiziellen Zeitzonennamen für Ihren Standort und den entsprechenden Befehl kennen. Angenommen, Sie möchten die Zeitzone auf Los Angeles ändern:

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

Jetzt können Sie die Zeitzone einstellen. Ich habe den date-Befehl verwendet, um nach Änderungen zu suchen, aber Sie können auch timedatectl verwenden:

[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 ~]#

Jetzt können Sie die Zeitzone Ihres Gastgebers wieder auf Ortszeit ändern.

systemd-timesyncd

Der Systemd-Timesync-Daemon stellt eine NTP-Implementierung bereit, die im Systemd-Kontext einfach zu verwalten ist. Es ist standardmäßig auf Fedora und Ubuntu installiert. Allerdings startet es standardmäßig nur unter Ubuntu. Bei anderen Distributionen bin ich mir nicht sicher. Sie können es selbst überprüfen:

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

Konfigurieren von systemd-timesyncd

Die Konfigurationsdatei für systemd-timesyncd ist /etc/systemd/timesyncd.conf. Dies ist eine einfache Datei mit weniger aktivierten Optionen als die alten NTP- und Chronyd-Dienste. Hier ist der Inhalt dieser Datei (ohne weitere Änderungen) auf meiner Fedora-VM:

#  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

Der einzige Abschnitt, der neben Kommentaren enthalten ist, ist [Zeit]. Alle anderen Zeilen sind auskommentiert. Dies sind die Standardwerte und sollten nicht geändert werden (es sei denn, Sie haben einen Grund dafür). Wenn in der NTP=-Zeile kein NTP-Zeitserver definiert ist, verwendet Fedora standardmäßig einen Fallback-Fedora-Zeitserver. Normalerweise füge ich meinen Zeitserver hinzu:

NTP=myntpserver

Timesync wird ausgeführt

Sie können systemd-timesyncd wie folgt starten und aktivieren:

[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 ~]#

Einstellen der Hardware-Uhr

So sieht die Situation nach dem Ausführen von timesyncd aus:

[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    

Der Unterschied zwischen RTC und Ortszeit (EDT) beträgt zunächst weniger als eine Sekunde, in den nächsten Tagen nimmt die Abweichung um weitere Sekunden zu. Da es in RTC kein Zeitzonenkonzept gibt, muss der Befehl timedatectl einen Vergleich durchführen, um die richtige Zeitzone zu ermitteln. Wenn die RTC-Zeit nicht genau mit der Ortszeit übereinstimmt, stimmt sie auch nicht mit der lokalen Zeitzone überein.

Auf der Suche nach weiteren Informationen habe ich den Status von systemd-timesync überprüft und Folgendes gefunden:

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

Beachten Sie die Protokollmeldung, die besagt, dass die Systemzeit nicht eingestellt oder zurückgesetzt wurde. Der Timesync-Dienst stellt die Systemzeit basierend auf dem Zeitstempel ein. Zeitstempel werden vom Timesync-Daemon verwaltet und bei jeder erfolgreichen Synchronisierung erstellt.

Der Befehl timedatectl hat keine Möglichkeit, den Wert der Hardware-Uhr von der Systemuhr zu übernehmen. Uhrzeit und Datum können nur anhand des in der Befehlszeile eingegebenen Werts eingestellt werden. Mit dem Befehl hwclock können Sie die RTC auf den gleichen Wert wie die Systemzeit einstellen:

[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: yes

Die Option --localtime weist die Hardware-Uhr an, die Ortszeit und nicht UTC anzuzeigen.

Warum braucht man überhaupt RTC?

Jede Implementierung von NTP stellt die Systemuhr beim Start ein. Und warum dann RTC? Das ist nicht ganz richtig: Dies geschieht nur, wenn Sie über eine Netzwerkverbindung zum Zeitserver verfügen. Allerdings haben viele Systeme nicht immer Zugriff auf eine Netzwerkverbindung, daher ist eine Hardware-Uhr für Linux sinnvoll, um die Systemzeit einzustellen. Dies ist besser als die manuelle Einstellung der Uhrzeit, auch wenn diese von der Echtzeit abweichen kann.

Abschluss

In diesem Artikel wurden einige Tools zum Bearbeiten von Datum, Uhrzeit und Zeitzonen besprochen. Das Tool systemd-timesyncd stellt einen NTP-Client bereit, der die Zeit auf dem lokalen Host mit einem NTP-Server synchronisieren kann. Allerdings stellt systemd-timesyncd keinen Serverdienst bereit. Wenn Sie also einen NTP-Server in Ihrem Netzwerk benötigen, müssen Sie etwas anderes, beispielsweise Chrony, als Server verwenden.

Ich bevorzuge eine einzige Implementierung für jeden Dienst in meinem Netzwerk, deshalb verwende ich Chrony. Wenn Sie keinen lokalen NTP-Server benötigen oder wenn es Ihnen nichts ausmacht, Chrony als Server und systemd-timesyncd als SNTP-Client zu verwenden. Schließlich besteht keine Notwendigkeit, die zusätzlichen Funktionen von Chrony als Client zu nutzen, wenn Sie mit der Funktionalität von systemd-timesyncd zufrieden sind.

Noch ein Hinweis: Sie müssen die systemd-Tools nicht verwenden, um NTP zu implementieren. Sie können eine ältere Version von ntpd, Chrony oder eine andere NTP-Implementierung verwenden. Schließlich besteht systemd aus einer Vielzahl von Diensten; Viele davon sind optional, sodass Sie sie deaktivieren und stattdessen etwas anderes verwenden können. Dies ist kein riesiges monolithisches Monster. Möglicherweise gefällt Ihnen systemd oder Teile davon nicht, aber Sie sollten eine fundierte Entscheidung treffen.

Mir gefällt die Implementierung von NTP durch systemd, aber ich bevorzuge Chrony, weil es meinen Anforderungen besser entspricht. Es ist Linux, Baby -)

Über die Rechte der Werbung

VDSina bietet Server für jede Aufgabe, eine riesige Auswahl an Betriebssystemen für die automatische Installation, es ist möglich, jedes Betriebssystem selbst zu installieren ISO, komfortabel панель управления Eigene Entwicklung und tägliche Bezahlung. Denken Sie daran, dass wir ewige Server haben, die definitiv zeitlos sind 😉

Source: habr.com