Die meisten Menschen haben ein Zeitbewusstsein. Wir stehen rechtzeitig auf, um unsere morgendlichen Rituale zu erfüllen, zur Arbeit zu gehen, eine Mittagspause einzulegen, Projektfristen einzuhalten, Geburtstage und Feiertage zu feiern, einen Flug zu nehmen und so weiter.
Darüber hinaus gibt es unter uns diejenigen, die von der Zeit besessen sind. Meine Uhren betrieben mit Solarenergie erhalten die präzise Zeit vom National Institute of Standards and Technology () in Fort Collins, Colorado, über eine Langwellen-Radiostation . Die Zeit-Signale werden mit Atomuhren synchronisiert, die ebenfalls in Fort Collins stehen. Mein Fitbit synchronisiert sich mit meinem Handy, welches sich mit einem Server synchronisiert , der letztendlich mit den Atomuhren synchronisiert wird.
Auch Geräte achten auf die Zeit.
Es gibt viele Gründe, warum unsere Geräte und Computer genaue Zeit benötigen. Zum Beispiel müssen im Bankwesen, an den Aktienmärkten und in anderen Finanzinstitutionen Transaktionen in der richtigen Reihenfolge erfolgen, und präzise Zeitfolgen sind dabei von entscheidender Bedeutung.
Unsere Telefone, Tablets, Autos, GPS-Systeme und Computer benötigen eine präzise Zeiteinstellung. Ich möchte, dass die Uhr auf meinem Desktop die genaue Zeit anzeigt. Ich möchte, dass Erinnerungen in meinem lokalen Kalender zur richtigen Zeit erscheinen. Die richtige Zeit sorgt auch dafür, dass Cron-Jobs und systemd zum richtigen Zeitpunkt ausgeführt werden.
Datum und Uhrzeit sind auch wichtig für die Protokollierung, sodass es einfacher ist, bestimmte Logs anhand von Datum und Uhrzeit zu finden. Zum Beispiel habe ich einmal in DevOps gearbeitet (damals hieß es noch nicht so) und war mit der Einrichtung eines E-Mail-Systems in North Carolina beschäftigt. Früher haben wir über 20 Millionen E-Mails pro Tag verarbeitet. Die Verfolgung von E-Mails über mehrere Server oder die Bestimmung der genauen Reihenfolge von Ereignissen mit Hilfe von Log-Dateien auf geografisch verteilten Hosts kann viel einfacher sein, wenn die betreffenden Computer zeitlich synchronisiert sind.
Die Zeit ist eine — die Uhren sind viele
Linux-Hosts müssen berücksichtigen, dass es sowohl eine Systemzeit als auch eine RTC-Zeit gibt. RTC (Real Time Clock – Echtzeituhr) ist ein etwas seltsamer und nicht besonders präziser Name für die Hardware-Uhr.
Die Hardware-Uhr läuft kontinuierlich, selbst wenn der Computer ausgeschaltet ist, und nutzt hierfür eine Batterie auf dem Mainboard des Systems. Die Hauptfunktion der RTC besteht darin, die Zeit zu speichern, wenn keine Verbindung zu einem Zeitserver verfügbar ist. In Zeiten, in denen eine Verbindung zu einem Zeitserver über das Internet nicht möglich war, musste jeder Computer über eine präzise interne Uhr verfügen. Die Betriebssysteme mussten beim Booten auf die RTC zugreifen, und der Benutzer musste die Systemzeit manuell über die Hardware-Konfigurationsoberfläche des BIOS einstellen, um sicherzustellen, dass sie korrekt ist.
Die Hardware-Uhr versteht das Konzept von Zeitzonen nicht; in der RTC wird nur die Zeit gespeichert, nicht die Zeitzone oder die Verschiebung gegenüber UTC (Koordinierte Weltzeit, die auch als GMT oder Greenwich Mean Time bekannt ist). Sie können die RTC mit einem Tool einstellen, über das ich später in diesem Artikel sprechen werde.
Die Systemzeit ist die Zeit, die das Betriebssystem auf der GUI-Uhr auf Ihrem Desktop anzeigt, in den Ausgaben des Befehls date und in den Zeitstempeln der Protokolle. Sie bezieht sich auch auf die Erstellungs-, Änderungs- und Öffnungszeiten von Dateien.
Auf der Seite enthält eine vollständige Beschreibung von RTC und Systemuhren.
Was ist mit NTP?
Computer weltweit nutzen NTP (Network Time Protocol), um ihre Zeit mit standardisierten Referenzuhren über das Internet zu synchronisieren, wobei eine Hierarchie von NTP-Servern verwendet wird. Hauptzeitserver befinden sich auf Ebene 1 und sind direkt mit verschiedenen nationalen Zeitdiensten auf Ebene 0 über Satelliten, Funk oder sogar Modems über Telefonleitungen verbunden. Zeitdienste auf Ebene 0 können Atomuhren, Empfänger sein, die auf Signale eingestellt sind, die von Atomuhren gesendet werden, oder GPS-Empfänger, die hochgenaue Zeitsignale von GPS-Satelliten nutzen.
Auf den meisten Referenzservern sind mehrere tausend öffentliche NTP-Server der Stufe 2 verfügbar, die für alle zugänglich sind. Viele Organisationen und Benutzer (einschließlich mir), die über zahlreiche Hosts verfügen, die einen NTP-Server benötigen, ziehen es vor, ihre eigenen Zeitserver einzurichten, sodass nur ein lokaler Host auf die Stufen 2 oder 3 zugreift. Anschließend konfigurieren sie die verbleibenden Knoten im Netzwerk, um den lokalen Zeitserver zu nutzen. In meinem Heimnetzwerk handelt es sich dabei um einen Server der Stufe 3.
Verschiedene NTP-Implementierungen
Die ursprüngliche NTP-Implementierung ist ntpd. Danach kamen zwei neuere hinzu, chronyd und systemd-timesyncd. Alle drei synchronisieren die Zeit des lokalen Hosts mit einem NTP-Zeitserver. Der Dienst systemd-timesyncd ist nicht so zuverlässig wie chronyd, erfüllt aber die meisten Anforderungen. Wenn die RTC nicht synchronisiert ist, kann er die Systemzeit allmählich anpassen, um sich mit dem NTP-Server zu synchronisieren, wenn die lokale Systemzeit leicht abweicht. Der Dienst systemd-timesync kann nicht als Zeitserver verwendet werden.
— dies ist die Implementierung von NTP, die zwei Programme enthält: den chronyd-Daemon und eine Kommandozeilenoberfläche namens chronyc. Chrony bietet einige Funktionen, die in vielen Fällen einfach unverzichtbar sind:
- Chrony kann sich viel schneller mit einem Zeitserver synchronisieren als der alte Dienst ntpd. Dies ist vorteilhaft für Laptops oder Desktop-Computer, die nicht ständig laufen.
- Es kann Frequenzschwankungen ausgleichen, beispielsweise wenn der Host in den Ruhemodus wechselt oder wenn die Taktfrequenz aufgrund abrupten Frequenzwechsels schwankt, was die Taktfrequenzen bei geringer Belastung verlangsamt.
- Es löst Zeitprobleme im Zusammenhang mit instabilen Netzwerkverbindungen oder Netzwerküberlastung.
- Es regelt die Netzwerkverzögerungen.
- Nach der initialen Zeit-Synchronisation stoppt Chrony die Uhren niemals. Dies gewährleistet stabile und konsistente Zeitintervalle für viele Systemdienste und Anwendungen.
- Chrony kann sogar ohne Netzwerkverbindung arbeiten. In diesem Fall kann der lokale Host oder Server manuell aktualisiert werden.
- Chrony kann als NTP-Server fungieren.
Noch einmal: NTP ist ein Protokoll, das auf einem Linux-Host mit Chrony oder systemd-timesyncd implementiert werden kann.
Die RPM-Pakete NTP, Chrony und systemd-timesyncd sind in den Standard-Repositories von Fedora verfügbar. Das RPM systemd-udev ist ein Kernel-Ereignismanager, der standardmäßig in Fedora installiert ist, aber nicht zwingend erforderlich ist.
Sie können alle drei installieren und zwischen ihnen wechseln, aber das würde nur unnötige Komplikationen verursachen. Daher ist es besser, das zu vermeiden. Neuere Versionen von Fedora, CentOS und RHEL haben Chrony als standardmäßige Implementierung angenommen und außerdem ist systemd-timesyncd vorhanden. Ich finde, dass Chrony gut funktioniert, eine bessere Benutzeroberfläche als der NTP-Dienst bietet, viel mehr Informationen bereitstellt und eine bessere Kontrolle ermöglicht, was Systemadministratoren definitiv zusagen wird.
Deaktivierung von NTP-Diensten
Möglicherweise läuft bereits ein NTP-Dienst auf Ihrem Host. Wenn dies der Fall ist, müssen Sie ihn deaktivieren, bevor Sie zu etwas anderem wechseln. Ich hatte chronyd laufen, also verwendete ich die folgenden Befehle, um ihn zu stoppen und zu deaktivieren. Führen Sie die entsprechenden Befehle für jeden NTP-Daemon aus, den Sie auf Ihrem Host verwenden:
[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: geladen (/usr/lib/systemd/system/chronyd.service; deaktiviert; Hersteller-Voreinstellung: aktiviert)
Active: inaktiv (tot)
Docs: man:chronyd(8)
man:chrony.conf(5)
[root@testvm1 ~]#Überprüfen Sie den Status vor dem Start
Der Status der Systemsynchronisation ermöglicht es festzustellen, ob der NTP-Dienst läuft. Da Sie NTP noch nicht gestartet haben, deutet 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. Zum Beispiel führt der Befehl timedatectl ohne Argumente oder Parameter standardmäßig den Unterbefehl status aus:
[root@testvm1 ~]# timedatectl status
Lokale Zeit: Fr 2020-05-15 08:43:10 EDT
Universelle Zeit: Fr 2020-05-15 12:43:10 UTC
RTC-Zeit: Fr 2020-05-15 08:43:08
Zeitzone: America/New_York (EDT, -0400)
Systemuhr synchronisiert: nein
NTP-Dienst: inaktiv
RTC in lokaler TZ: ja
Warnung: Das System ist so konfiguriert, dass die RTC-Zeit in der lokalen Zeitzone gelesen wird.
Dieser Modus kann nicht vollständig unterstützt werden. Er führt zu verschiedenen Problemen
bei Änderungen der Zeitzone und Anpassungen der Sommerzeit. Die RTC
Zeit wird nie aktualisiert, sie ist auf externe Einrichtungen zur Pflege angewiesen.
Wenn möglich, nutzen Sie RTC in UTC, indem Sie
'timedatectl set-local-rtc 0' aufrufen.
[root@testvm1 ~]#So erhalten Sie die lokale Zeit für Ihren Host, die UTC-Zeit und die RTC-Zeit. In diesem Fall ist die Systemzeit auf die Zeitzone America / New_York (TZ) eingestellt, die RTC ist auf die Zeit in der lokalen Zeitzone eingestellt, und der NTP-Dienst ist inaktiv. Die RTC-Zeit beginnt sich leicht von der Systemzeit zu entfernen. Das ist normal für Systeme, deren Uhren nicht synchronisiert wurden. Der Betrag der Abweichung auf dem Host hängt von der Zeit ab, die seit der letzten Synchronisation des Systems vergangen ist.
Wir haben auch eine Warnung zur Verwendung der lokalen Zeit für die RTC erhalten – dies betrifft Änderungen der Zeitzone und die Sommerzeiteinstellungen. Wenn der Computer zu dem Zeitpunkt ausgeschaltet ist, an dem Änderungen vorgenommen werden müssen, wird die RTC-Zeit nicht angepasst. Aber für Server oder andere Hosts, die rund um die Uhr betrieben werden, stellt das überhaupt kein Problem dar. Darüber hinaus wird jeder Dienst, der NTP-Zeit-Synchronisierung bereitstellt, die Zeit des Hosts zu einem frühen Zeitpunkt beim Start anpassen, sodass die Zeit nach Abschluss des Bootvorgangs wieder korrekt ist.
Zeitzone einstellen
In der Regel geben Sie die Zeitzone während des Installationsprozesses an, und Sie haben keinen Bedarf, diese später zu ändern. Es gibt jedoch Fälle, in denen es notwendig ist, die Zeitzone zu ändern. Es stehen mehrere Werkzeuge zur Verfügung, die Ihnen dabei helfen können. Um die lokale Zeitzone zu bestimmen, verwendet Linux Zeitzonendateien. Diese Dateien befinden sich im Verzeichnis /usr/share/zoneinfo. Standardmäßig legt das System für meine Zeitzone Folgendes fest: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Aber es ist nicht erforderlich, solche Feinheiten zu kennen, um die Zeitzone zu ändern.
Wichtig ist, den offiziellen Namen der Zeitzone für Ihren Standort und den entsprechenden Befehl zu kennen. Nehmen wir an, Sie möchten die Zeitzone auf Los Angeles ändern:
[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/HelsinkiJetzt können Sie die Zeitzone einstellen. Ich habe den Befehl date verwendet, um die Änderungen zu überprüfen, aber Sie können auch timedatectl verwenden:
[root@testvm2 ~]# date
Di 19. Mai 2020 16:47:49 EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Di 19. Mai 2020 13:48:23 PDT
[root@testvm2 ~]#Sie können jetzt die Zeitzone Ihres Hosts wieder auf die lokale Zeit ändern.
systemd-timesyncd
Der Daemon systemd-timesync bietet eine leicht verwaltbare NTP-Implementierung im Kontext von systemd. Er wird standardmäßig in Fedora und Ubuntu installiert. Allerdings wird er standardmäßig nur in Ubuntu gestartet. Ich bin mir über andere Distributionen nicht sicher. Sie können selbst nachsehen:
[root@testvm1 ~]# systemctl status systemd-timesyncdKonfiguration von systemd-timesyncd
Die Konfigurationsdatei für systemd-timesyncd ist /etc/systemd/timesyncd.conf. Dies ist eine einfache Datei mit weniger aktivierten Optionen als bei den älteren NTP- und chronyd-Diensten. Hier ist der Inhalt dieser Datei (ohne zusätzliche Änderungen) auf meiner virtuellen Maschine mit 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=2048Der einzige Abschnitt, der neben Kommentaren enthalten ist, ist [Time]. Alle anderen Zeilen sind auskommentiert. Das sind die Standardwerte, die nicht geändert werden müssen (es sei denn, Sie haben dafür einen Grund). Wenn Sie keinen NTP-Zeitserver in der Zeile NTP= angegeben haben, wird standardmäßig der Backup-Zeitserver von Fedora verwendet. Ich füge normalerweise meinen eigenen Zeitserver hinzu:
NTP=myntpserverZeitynchronisation starten
Sie können systemd-timesyncd aktivieren und starten, indem Sie Folgendes verwenden:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Erstellter Symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Erstellter 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 ~]#Installation der Hardware-Uhr
So sieht die Situation nach dem Start von timesyncd aus:
[root@testvm2 systemd]# timedatectl
Lokale Zeit: Sa 2020-05-16 14:34:54 EDT
Universelle Zeit: Sa 2020-05-16 18:34:54 UTC
RTC-Zeit: Sa 2020-05-16 14:34:53
Zeitzone: America/New_York (EDT, -0400)
Systemuhr synchronisiert: ja
NTP-Dienst: aktiv
RTC in lokaler TZ: nein Anfänglich beträgt der Unterschied zwischen der RTC- und der lokalen Zeit (EDT) maximal eine Sekunde, und die Diskrepanz nimmt in den nächsten Tagen um einige Sekunden zu. Da es in der RTC keine Zeitzonen gibt, muss der Befehl timedatectl einen Vergleich durchführen, um die erforderliche Zeitzone zu bestimmen. Wenn die RTC-Zeit nicht genau mit der lokalen Zeit übereinstimmt, dann ist sie auch nicht mit der lokalen Zeitzone korrekt.
Auf der Suche nach weiteren Informationen habe ich den Status von systemd-timesync überprüft und Folgendes festgestellt:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Netzwerkzeit-Synchronisation
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
Active: active (running) seit Sa 2020-05-16 13:56:53 EDT; vor 18h
Docs: man:systemd-timesyncd.service(8)
Main PID: 822 (systemd-timesyn)
Status: "Initiale Synchronisation zum Zeitserver 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
16. Mai 09:57:24 testvm2.both.org systemd[1]: Starte Netzwerkzeit-Synchronisation...
16. Mai 09:57:24 testvm2.both.org systemd-timesyncd[822]: Systemuhrzeit nicht gesetzt oder zurückgesprungen, wiederhergestellt von aufgezeichneter Zeitmarke: Sa 2020-05-16 13:56:53 EDT
16. Mai 13:56:53 testvm2.both.org systemd[1]: Netzwerkzeit-Synchronisation gestartet.
16. Mai 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initiale Synchronisation zum Zeitserver 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Bitte beachten Sie die Protokollnachricht, die besagt, dass die Systemzeit nicht gesetzt oder zurückgesetzt wurde. Der Dienst Timesync setzt die Systemzeit basierend auf der Zeitmarke. Zeitstempel werden vom Timesync-Daemon unterstützt und bei jeder erfolgreichen Synchronisation erstellt.
Der Befehl timedatectl kann den Wert der Hardwareuhr nicht aus der Systemuhr übernehmen. Er kann Zeit und Datum nur aus dem in der Befehlszeile eingegebenen Wert setzen. Sie können die RTC auf denselben Wert wie die Systemzeit setzen, indem Sie den Befehl hwclock verwenden:
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Lokale Zeit: Mo 2020-05-18 13:56:46 EDT
Universelle Zeit: Mo 2020-05-18 17:56:46 UTC
RTC-Zeit: Mo 2020-05-18 13:56:46
Zeitzone: Amerika/New_York (EDT, -0400)
Systemuhr synchronisiert: ja
NTP-Dienst: aktiv
RTC in lokaler TZ: jaDie Option —localtime zeigt an, dass die Hardwareuhr die lokale Zeit und nicht UTC anzeigt.
Warum benötigen Sie überhaupt eine RTC?
Jede NTP-Implementierung wird die Systemuhr beim Start setzen. Und warum dann eine RTC? Das ist nicht ganz richtig: Dies geschieht nur, wenn Sie eine Netzwerkverbindung zu einem Zeitserver haben. Viele Systeme haben jedoch keinen ständigen Zugang zu einer Netzwerkverbindung, weshalb die Hardwareuhr nützlich ist, damit Linux auf ihrer Basis die Systemzeit setzen kann. Das ist besser, als die Zeit manuell einzustellen, auch wenn sie von der realen Zeit abweichen kann.
Fazit
In diesem Artikel werden einige Werkzeuge zur Verwaltung von Datum, Uhrzeit und Zeitzonen behandelt. Das Tool systemd-timesyncd bietet einen NTP-Client, der die Zeit auf dem lokalen Host mit einem NTP-Server synchronisieren kann. Allerdings stellt systemd-timesyncd keinen Serverdienst zur Verfügung. Wenn Sie also einen NTP-Server in Ihrem Netzwerk benötigen, müssen Sie etwas anderes verwenden – beispielsweise Chrony, um als Server zu fungieren.
Ich bevorzuge eine einzige Implementierung für alle Dienste in meinem Netzwerk, weshalb ich Chrony einsetze. Wenn Sie keinen lokalen NTP-Server benötigen oder wenn Sie kein Problem damit haben, Chrony als Server und systemd-timesyncd als SNTP-Client zu verwenden. Es ist schließlich nicht notwendig, die erweiterten Funktionen von Chrony als Client zu nutzen, wenn Ihnen die Funktionalität von systemd-timesyncd ausreicht.
Ein weiterer Hinweis: Sie sind nicht verpflichtet, systemd-Tools für die Implementierung von NTP zu nutzen. Sie können auch die frühere Version ntpd, Chrony oder eine andere NTP-Implementierung verwenden. Systemd besteht aus vielen Diensten; viele davon sind optional, sodass Sie sie deaktivieren und stattdessen andere Alternativen verwenden können. Es ist kein riesiges monolithisches Monster. Man kann systemd oder Teile davon nicht mögen, aber Sie sollten eine fundierte Entscheidung treffen.
Ich mag die NTP-Implementierung in systemd, bevorzuge aber Chrony, da es besser auf meine Bedürfnisse eingeht. Das ist Linux, Baby -)
Im Auftrag der Werbung
VDSina bietet , eine riesige Auswahl an Betriebssystemen für die automatische Installation, es besteht die Möglichkeit, jedes OS von Ihrem eigenen , benutzerfreundliche Eigenentwicklung und Tagesabrechnung. Denken Sie daran, dass wir unbefristete Server anbieten, die wirklich zeitlos sind 😉
Quelle: habr.com
