VPS-Uhr geht falsch: Zeitdrift finden und beheben

Warum die Uhr Ihres VPS abweicht

Die Uhr eines VPS weicht ab, weil sie nicht korrigiert wird. Der Kernel ermittelt die Zeit anhand eines Hardwarezählers, der etwas zu schnell oder zu langsam läuft. Wenn kein Zeit-Synchronisationsclient ausgeführt wird, wächst dieser kleine Fehler mit jeder Stunde.

In einer virtuellen Maschine gibt es eine zweite Ursache. Ihr Gast verwendet eine physische CPU gemeinsam mit anderen Gästen. Während der Gast nicht eingeplant ist, kann er die verstrichene Zeit nicht zählen.

Bei einem aktuellen KVM-Gast ist der Zähler selbst selten das eigentliche Problem. Die paravirtualisierte kvm-clock-Quelle liest einen Wert, den der Host verwaltet. Ein fehlerfreier Gast bleibt dadurch eng mit dem Host synchron. Sichtbar falsche Uhren haben meist einen einfacheren Grund. Entweder läuft kein Synchronisationsdienst, oder zwei Dienste laufen gleichzeitig und beeinflussen sich gegenseitig. Möglich ist auch, dass ausgehender UDP-Port 123 das Netzwerk Ihres Providers nicht verlässt. Ein Gast übernimmt seine Zeitsynchronisation vom Host oder über NTP (Network Time Protocol), nicht von seinem eigenen Oszillator.

Was eine falsche Uhrzeit tatsächlich beeinträchtigt

• TOTP-Codes (zeitbasierte Einmalpasswörter) stimmen nicht mehr überein. Dadurch werden Sie von einem Server ausgesperrt, obwohl Passwort und Schlüssel korrekt sind.
• Ein vor einer Minute ausgestelltes Zertifikat wird abgelehnt, und curl gibt SSL certificate problem: certificate is not yet valid aus.
• apt update lehnt ein Repository mit E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s) ab.
• Geplante Aufgaben werden zum falschen Zeitpunkt ausgeführt. Ein Zeitsprung kann dazu führen, dass ein Auftrag zweimal ausgeführt und ein anderer übersprungen wird.
• Logs von zwei Servern lassen sich nicht zeitlich ausrichten. Eine Zeitleiste des Vorfalls muss daher durch Vermutungen rekonstruiert werden.

Die Toleranz ist kleiner, als die meisten erwarten. Die folgenden Werte sind dokumentierte Standardwerte und keine Messungen aus einem Test.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Ein TOTP-Code wird anhand eines Zählers berechnet, der alle 30 Sekunden weiterläuft. Die meisten Prüfinstanzen akzeptieren außerdem einen Zeitschritt vor oder nach dem aktuellen Schritt. Eine Abweichung von einer halben Minute in jede Richtung entspricht bereits der gesamten Toleranz. Kerberos ist deutlich toleranter und erlaubt standardmäßig eine Abweichung von 300 Sekunden. Bei einem Zertifikat gibt es dagegen keine Toleranz: Es wird anhand fester Zeitpunkte mit einer Kulanz von 0 Sekunden geprüft. Eine um eine Sekunde vorgehende Uhr lehnt daher ein Zertifikat ab, das vollständig gültig ist.

Die drei Uhren und welche davon relevant ist

Die Systemuhr ist die relevante Uhr. Sie ist der CLOCK_REALTIME des Kernels: die Anzahl der Sekunden seit dem 1. Januar 1970 UTC, die im Speicher gehalten wird und von allem gelesen wird, was einen Zeitstempel setzt. Logzeilen, Zertifikatsprüfungen, TOTP-Codes und Änderungszeiten von Dateien stammen alle aus dieser Uhr. Wenn jemand sagt, dass die Zeit des Servers falsch ist, ist diese Uhr gemeint.

Die Hardwareuhr, auch RTC (real time clock) genannt, ist ein separater Zähler, der weiterläuft, während die Maschine ausgeschaltet ist. Auf einer physischen Maschine ist sie ein batteriegepufferter Chip. In einem Gast wird sie vom Hypervisor emuliert und ist daher weitgehend ein Artefakt des Hosts. Linux liest sie einmal beim Booten als Ausgangswert und führt danach einen eigenen Zähler weiter. timedatectl gibt sie in der Zeile RTC time aus. Verwenden Sie diese Zeile auf einem VPS nicht zur Fehlersuche, weil sie die Zeitvorstellung des Hosts und nicht den Synchronisierungsstatus Ihrer Systemuhr zeigt. In einem Container gibt es normalerweise überhaupt keine /dev/rtc, daher schlägt hwclock --show mit hwclock: Cannot access the Hardware Clock via any known method. fehl.

Die Clocksource legt fest, womit der Kernel zwischen diesen Lesevorgängen zählt. Fragen Sie den Kernel ab, welche Clocksource er ausgewählt hat:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Unter KVM sehen Sie normalerweise kvm-clock. Sie liest einen vom Host verwalteten Wert. Deshalb bleibt ein KVM-Gast auch ohne NTP-Client eine Zeit lang ungefähr korrekt. tsc ist der eigene Zähler der CPU. Xen-Gäste melden xen, und Hyper-V-Gäste melden eine hyperv-Quelle. Lassen Sie diese Einstellung unverändert, sofern kein konkreter Messwert eine Änderung begründet. Der Kernel wählt für die jeweilige Hardware bereits die beste vertrauenswürdige Quelle aus.

Einige Hosts stellen dem Gast außerdem ein PTP-Gerät (precision time protocol) bereit. Damit kann chrony die Host-Uhr direkt statt über das Netzwerk lesen. Eine Prüfung ist sinnvoll, aber auf einem gemeinsam genutzten VPS ist dieses Gerät häufig nicht verfügbar:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Wenn modprobe fehlschlägt oder kein Gerät angezeigt wird, stellt Ihr Host es nicht bereit. Dann ist NTP über das Netzwerk die geeignete Lösung. Wenn clock_name die virtuelle KVM-Uhr bezeichnet, kann chrony sie mit einer refclock PHC /dev/ptp0 poll 2-Zeile in seiner Konfiguration verwenden.

Zeitstatus auf dem eigenen Rechner auslesen

Beginnen Sie mit einem Befehl. Er beantwortet auf einem Bildschirm die Frage: „Hält irgendetwas diese Uhrzeit korrekt?“

timedatectl

Lesen Sie diese Zeilen, statt einer gemerkten Zahl zu vertrauen:

• Local time und Universal time bezeichnen denselben Zeitpunkt, einmal in Ihrer Zeitzone und einmal in UTC. Wenn sie identisch sind, verwendet der Rechner bereits UTC.
• RTC time ist die oben beschriebene Hardware-Uhr. Auf einem VPS können Sie sie ignorieren.
• Time zone gibt an, wie das System die lokale Zeit formatiert.
• System clock synchronized ist das eigene Flag des Kernels. Ein Zeit-Daemon setzt es, sobald er seinen Quellen vertraut. no bedeutet daher, dass seit dem Booten niemand diese Uhr synchronisiert hat.
• NTP service gibt speziell den Status von systemd-timesyncd aus. n/a ist auf einem Rechner mit chrony normal, weil timesyncd dort nicht installiert ist. System clock synchronized: yes zusammen mit NTP service: n/a bedeutet, dass chrony die Synchronisierung übernimmt und der Kernel dies bestätigt.

Prüfen Sie als Nächstes, wie groß die Abweichung ist. Vergleichen Sie sie nicht nach Augenmaß mit Ihrem Telefon. Wenn chrony läuft:

chronyc tracking
chronyc sources -v

chronyc tracking gibt die Zahlen aus, die diese Frage beantworten. System time ist die aktuelle Abweichung von der NTP-Zeit, gefolgt vom Wort fast oder slow. Last offset ist die Größe der letzten Korrektur. Frequency ist der von chrony gemessene Gangfehler Ihrer Uhr, den chrony bereits ausgleicht. Leap status sollte Normal anzeigen. Wenn Not synchronised angezeigt wird und Reference ID den Wert 00000000 () hat, hat chrony noch keine Quelle ausgewählt.

chronyc sources -v gibt oberhalb der Liste eine Legende aus. Sie müssen sich die Symbole daher nicht merken. Zwei Spalten enthalten den größten Teil der relevanten Informationen. Das Statuszeichen am Anfang jeder Zeile gibt an, wie chrony diese Quelle bewertet. * kennzeichnet die aktuell verwendete Quelle. ? in jeder Zeile bedeutet, dass keine Quelle antwortet. Reach zeigt den Antwortverlauf der letzten acht Abfragen in Oktalnotation. 377 bedeutet, dass alle acht Abfragen beantwortet wurden. 0 bedeutet, dass keine beantwortet wurde.

Wenn stattdessen systemd-timesyncd zuständig ist:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status gibt den Server aus, mit dem der Dienst kommuniziert, das Abfrageintervall und einen Wert für Offset. Gibt der Befehl einen Fehler zum Dienst aus, statt den Status anzuzeigen, ist timesyncd auf diesem Rechner nicht der zuständige Daemon. Damit ist Ihre Frage bereits beantwortet.

Für eine grobe Prüfung gegenüber der Außenwelt ohne zusätzliche Tools können Sie Ihre Uhr mit einem öffentlichen HTTP-Header Date vergleichen. Dieser wird in GMT mit einer Auflösung von einer Sekunde bereitgestellt:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Eine Abweichung von ein oder zwei Sekunden ist hier normal und bedeutet nichts. Eine Abweichung von einer Minute ist Ihr Fehler.

chrony oder systemd-timesyncd auf einem VPS

Ubuntu und Debian liefern systemd-timesyncd standardmäßig mit. Es ist ein SNTP-Client (Simple Network Time Protocol): Er fragt jeweils einen Server ab und nähert die Systemzeit an dessen Zeit an. Auf einem System, das dauerhaft online ist und mit einer ungefähr korrekten Zeit startet, reicht das aus. Der Ressourcenverbrauch ist nahezu vernachlässigbar.

chrony ist eine vollständige NTP-Implementierung und auf einer virtuellen Maschine die bessere Standardwahl. Die Gründe dafür sind bereits in der eigenen Ausgabe erkennbar. chrony fragt mehrere Quellen gleichzeitig ab und verwirft Quellen, die voneinander abweichen. Es misst den Gangfehler der Systemuhr und schreibt ihn in eine Drift-Datei. Dadurch korrigiert es die systematische Abweichung der Uhr, statt jedem einzelnen Messwert hinterherzulaufen. Außerdem erholt sich chrony schnell von zwei Situationen, die bei einer VM auftreten können, nicht aber bei einem physischen Server: Der Host kann die VM pausieren, und die VM kann im laufenden Betrieb auf einen anderen Host verschoben werden. Wenn der Host ein PTP-Gerät bereitstellt, liest chrony dessen Zeit.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Lesen Sie die apt-Ausgabe während der Installation. Unter Debian und Ubuntu stellen sowohl die Pakete chrony als auch systemd-timesyncd time-daemon bereit. Daher entfernt apt timesyncd, während chrony installiert wird. Das ist korrekt und beabsichtigt. Führen Sie niemals beide Dienste gleichzeitig aus. Zwei Daemons, die dieselbe Uhr setzen, beeinflussen sich gegenseitig. Solange beide laufen, ist der gemeldete Offset keines der beiden Dienste zuverlässig. Installieren Sie chrony unter Rocky und AlmaLinux mit sudo dnf install -y chrony. Dort heißt die Unit chronyd und nicht chrony.

Die Konfigurationsdatei befindet sich unter Debian und Ubuntu in /etc/chrony/chrony.conf und unter Rocky und Alma in /etc/chrony.conf. Die Standardkonfiguration der Distribution ist für einen VPS bereits sinnvoll. Ändern Sie sie daher nur aus einem konkreten Grund. Zwei Direktiven sollten Sie kennen:

• Die Zeilen pool und server benennen die Zeitquellen. Mit iburst veranlassen Sie chrony, beim Start eine schnelle Folge von Abfragen zu senden. Dadurch erfolgt die erste Synchronisierung innerhalb von Sekunden statt innerhalb von Minuten.
• makestep legt fest, wann chrony die Uhrzeit sprunghaft korrigiert, statt sie schrittweise anzupassen. Prüfen Sie den Wert mit grep -n makestep /etc/chrony/chrony.conf. Der Standardwert unter Debian und Ubuntu, makestep 1 3, bedeutet Folgendes: Bei den ersten drei Aktualisierungen nach dem Start von chronyd wird die Uhrzeit sprunghaft korrigiert, wenn sie um mehr als eine Sekunde abweicht. Danach wird die Uhrzeit nur noch durch Slewing korrigiert.

Wenn Sie den Zeitverkehr gegen Manipulationen auf dem Übertragungsweg authentifizieren möchten, unterstützt chrony ab Version 4 NTS (Network Time Security). Prüfen Sie zuerst Ihre Version mit chronyd -v. Beachten Sie außerdem, dass NTS neben UDP-Port 123 auch einen ausgehenden TCP-Port 4460 benötigt:

server time.cloudflare.com iburst nts

Starten Sie den Dienst neu und prüfen Sie ihn, bevor Sie ihm vertrauen. Wenn die Konfiguration nicht eingelesen werden kann, läuft überhaupt kein Zeitdienst. Die Systemuhr weist Sie darauf nicht hin.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Warum eine um Minuten falsche Uhr falsch bleibt

Ein Zeit-Daemon kann eine Abweichung auf zwei Arten korrigieren. Beim Slewing wird die Uhr schneller oder langsamer gestellt, bis die Abweichung verschwunden ist. Die Zeit läuft dabei weiter vorwärts, und kein Zeitstempel wird wiederholt oder übersprungen. Beim Stepping springt die Uhr direkt auf den korrekten Wert. Das geht schnell, kann die Uhr aber rückwärts stellen. Das ist für alles problematisch, was verstrichene Zeit anhand der Wanduhr misst. Deshalb bevorzugen beide Daemons das Slewing.

Diese Präferenz ist der Grund, warum eine stark falsche Uhr lange falsch bleiben kann. chrony führt ein Stepping nur innerhalb des von makestep erlaubten Zeitfensters durch. Standardmäßig gilt dieses Fenster nur für die ersten Aktualisierungen nach dem Start des Daemons. Läuft chronyd bereits seit einer Woche und stellt dann eine Abweichung von vierzig Sekunden fest, wird es diese per Slewing korrigieren. Das dauert deutlich länger, als Sie warten möchten. Erzwingen Sie die Korrektur einmal bewusst zu einem ruhigen Zeitpunkt:

sudo chronyc makestep
chronyc tracking

chronyc tracking sollte jetzt eine System time-Abweichung nahe null melden. Last offset sollte die Größe der gerade korrigierten Abweichung anzeigen. Überlegen Sie, bevor Sie dies auf einem ausgelasteten Datenbank-Host ausführen. Eine rückwärts springende Uhr kann Software verwirren, die davon ausgeht, dass die Zeit nur vorwärts läuft. Ein Neustart des Daemons ist die schonendere Variante derselben Korrektur, da das makestep-Fenster beim Start erneut geöffnet wird.

Container teilen die Uhr des Hosts

Ein Container hat keine eigene Systemzeit. Daher gibt es in ihm nichts zu synchronisieren. Linux-Zeit-Namespaces virtualisieren nur die monotone Uhr und die Bootzeit-Uhr. CLOCK_REALTIME wird nicht virtualisiert. Daher liest ein Container dieselbe Systemzeit wie der Host, auf dem er läuft. Korrigieren Sie die Uhr auf dem Host. Damit wird die Uhr jedes Containers auf diesem Host im selben Moment korrigiert.

Daraus ergeben sich einige Konsequenzen. Installieren Sie kein chrony oder ntpd in einem Image. Im besten Fall bewirkt es nichts. Das Setzen des Datums in einem unprivilegierten Container schlägt mit date: cannot set date: Operation not permitted fehl, weil der Kernel für diesen Aufruf CAP_SYS_TIME benötigt. Durch die Vergabe von CAP_SYS_TIME erhält der Container keine eigene Uhr. Er erhält dadurch die Möglichkeit, die Uhr des Hosts und damit auch die Uhr jedes anderen Containers zu ändern.

Eine andere Zeitzone in einem Container ist kein Problem der Systemzeit. Ein Image mit einer eigenen /etc/localtime gibt denselben Zeitpunkt in einer anderen Zeitzone formatiert aus. Dadurch wirkt date falsch, obwohl die Uhr korrekt ist. Setzen Sie TZ=UTC in der Umgebung des Containers. Damit verschwindet die Verwirrung. Die ausgewählte Laufzeitumgebung ändert daran nichts. Der Vergleich von rootless Podman und Docker beschreibt, was sie tatsächlich ändert.

Zeitzonen: UTC auf dem Server, lokale Zeit für Menschen

Stellen Sie die Maschine auf UTC ein und belassen Sie sie dabei.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC kennt keine Sommerzeit. Das ist bereits das entscheidende Argument. Ein täglicher Job um 02:30 in einer Zeitzone mit Sommerzeit wird an dem Tag, an dem die Uhren zurückgestellt werden, zweimal ausgeführt und an dem Tag, an dem sie vorgestellt werden, überhaupt nicht ausgeführt. man 8 cron dokumentiert die spezielle Behandlung von Verschiebungen um weniger als drei Stunden: Jobs, die durch eine Vorwärtsverschiebung übersprungen wurden, werden kurz nach der Änderung ausgeführt. Jobs, die durch eine Rückwärtsverschiebung in eine wiederholte Stunde fallen, werden nicht ein zweites Mal ausgeführt. Dieses Verhalten ist sinnvoll. Trotzdem sollten Sie es nicht um 03:00 berücksichtigen müssen. Unter UTC wird der Job an jedem Tag des Jahres genau einmal ausgeführt. Wenn ein Job vollständig fehlt, statt zu einer ungewöhnlichen Uhrzeit ausgeführt zu werden, sind die Gründe, warum ein Cron-Job unbemerkt nie ausgeführt wird wahrscheinlich die zutreffendere Erklärung.

Dasselbe Argument gilt für das Lesen von Logs. journalctl formatiert Zeitstempel in der Systemzeitzone, und journalctl --utc erzwingt UTC. Zwei Server in zwei Zeitzonen machen aus jedem Vorfall eine Umrechnungsaufgabe. Unter Zeitdruck durchgeführte Umrechnungen führen dazu, dass Zeitabläufe falsch gelesen werden. Lassen Sie die Systeme auf UTC laufen, speichern Sie Zeitstempel in UTC und rechnen Sie sie erst an der Stelle um, an der ein Mensch sie liest. Wer für einen einzelnen Befehl eine lokale Zeitdarstellung benötigt, kann sie anfordern, ohne die Maschine umzustellen:

TZ=Europe/Berlin date

Eine weitere Zeile in der Ausgabe von timedatectl gehört in diesen Abschnitt. RTC in local TZ sollte no lauten. Die Einstellung auf yes ist eine Umgehungslösung für den Dual-Boot von Windows auf einem Laptop. Auf einem Server fügt sie lediglich einen Offset hinzu, über den später jemand stolpern kann. Wenn diese Einstellung gesetzt ist, gibt timedatectl eine Warnung aus, dass das System die RTC-Zeit in der lokalen Zeitzone lesen soll.

Fehlersuche anhand des Symptoms

Ihr Zwei-Faktor-Code wird auf einem Server abgelehnt. Prüfen Sie zuerst die Uhr, bevor Sie andere Ursachen untersuchen. Der Code stammt aus einem Zähler, der alle 30 Sekunden weiterläuft. Ein Server, dessen Uhr 90 Sekunden nachgeht, berechnet daher einen Code aus einem Zeitabschnitt, den Ihr Telefon bereits überschritten hat. timedatectl zeigt System clock synchronized: no an, oder chronyc tracking meldet einen großen System time-Versatz. Das ist ein anderer Fehler als die direkte Ablehnung eines Schlüssels. In diesem Fall wird eine eigene Meldung ausgegeben. Weitere Informationen finden Sie in der Anleitung zu Fehlern bei der Public-Key-Authentifizierung.

apt update meldet, dass eine Release-Datei noch nicht gültig ist. Die vollständige Meldung nennt das Repository und die verbleibende Dauer, zum Beispiel is not valid yet (invalid for another 1d 2h 3min 4s). Ihre Uhr geht gegenüber dem Datum in der Release-Datei des Repositorys nach. Die angegebene Dauer misst direkt, wie groß der Rückstand ist. Korrigieren Sie die Uhrzeit. Deaktivieren Sie nicht die Datumsprüfung von apt, nur um den Fehler zu umgehen. Diese Prüfung verhindert, dass Ihnen jemand einen veralteten Paketindex bereitstellt.

Jede Source-Zeile zeigt den Status unreachable, und Reach ist 0. Es antwortet nichts. Prüfen Sie daher den ausgehenden Netzwerkverkehr und nicht zuerst Ihre Konfiguration. NTP verwendet ausgehend UDP-Port 123. Einige Netzwerke filtern oder leiten diesen Verkehr um. sudo chronyc ntpdata gibt Zähler für jede Source aus, darunter Total TX und Total RX. Steigt der TX-Zähler, während RX bei 0 bleibt, verlassen Ihre Pakete den Rechner, aber es kommt nichts zurück. Das deutet auf eine Firewall zwischen Ihnen und der Source hin.

Die Uhrzeit war korrekt und sprang dann. Host-Ereignisse können dies verursachen. Ein wiederhergestellter Snapshot, ein pausierter Gast oder eine Live-Migration auf einen anderen Host kann dazu führen, dass die Zeit im Gast hinter der tatsächlichen Zeit zurückbleibt. chrony erkennt dies beim nächsten Poll und korrigiert die Uhrzeit. systemd-timesyncd wartet möglicherweise zunächst ein langes Poll-Intervall ab. Stellen Sie mit systemctl is-enabled chrony sicher, dass der Daemon beim Booten gestartet wird. Ein manuell gestarteter Daemon ist nach dem nächsten Reboot nicht mehr aktiv.

Der Versatz ist klein, stabilisiert sich aber nie. Prüfen Sie den CPU-Steal. Ein Gast, der beim fälligen Timer-Interrupt nicht eingeplant wird, erhält seine Messwerte verspätet. Dadurch schwankt der Versatz, statt sich zu verringern. top zeigt dies als Wert st in der CPU-Zeile an. CPU-Steal-Zeit auf einem gemeinsam genutzten Host lesen erklärt die Bedeutung dieses Werts und mögliche Gegenmaßnahmen.

Ein gerade ausgestelltes Zertifikat wird als noch nicht gültig abgelehnt. curl gibt SSL certificate problem: certificate is not yet valid aus. Browser zeigen eine ähnliche Meldung. Das Zertifikat ist in Ordnung. Die Uhr des Rechners, der es prüft, geht nach. Der fehlerhafte Rechner kann der Client oder der Server sein. Prüfen Sie daher beide. Wenn der Server, der das Zertifikat ausgestellt hat, die falsche Uhrzeit verwendet, behandelt die Anleitung zu Zertifikaten mit certbot und nginx die Erneuerung in derselben Konfiguration.

Fügen Sie die Prüfung zu den bereits ausgeführten Kontrollen hinzu

Die Zeitsynchronisierung ist eine Einstellung beim Systemstart, die Monate später unbemerkt ausfallen kann. Genau für solche Fälle ist eine Routineprüfung geeignet, während man sich nicht zuverlässig daran erinnert. timedatectl und chronyc tracking sind gemeinsam in zwei Sekunden geprüft. Führen Sie sie im Rahmen von den ersten zehn Minuten auf einem neuen VPS und erneut bei der Bearbeitung der regulären Wartungscheckliste für Linux-Server aus. Wenn die Prüfung automatisch ausgeführt werden und melden soll, sobald der Offset größer wird, beschreibt das Erstellen eines systemd-Dienstes und -Timers das Muster für eine kleine Unit, die regelmäßig einen Statusbericht ausgibt.

FAQ

Wie prüfe ich, ob die Uhr meines VPS synchronisiert ist?

Führen Sie timedatectl aus und lesen Sie die Zeile System clock synchronized. Das ist das eigene Flag des Kernels. Es wird von dem Daemon gesetzt, der die Uhr synchronisiert. Daher ist yes zusammen mit NTP service: n/a auf einem System mit chrony normal und korrekt. Für die Größe der Abweichung führen Sie chronyc tracking aus und lesen Sie System time. Wenn systemd-timesyncd zuständig ist, führen Sie alternativ timedatectl timesync-status aus und lesen Sie Offset. Für einen Vergleich mit einer Quelle außerhalb des Systems vergleichen Sie date -u mit dem Header Date, den jede HTTPS-Site zurückgibt.

Sollte ich auf einem VPS chrony oder systemd-timesyncd verwenden?

Verwenden Sie für wichtige Systeme chrony. systemd-timesyncd ist ein SNTP-Client, der einem Server folgt. Er eignet sich für ein System, das dauerhaft online ist und bereits annähernd die korrekte Zeit hat. chrony fragt mehrere Quellen ab, verwirft widersprüchliche Quellen, ermittelt die Gangabweichung der Uhr und synchronisiert sich nach einer Host-Pause oder einer Live-Migration schnell wieder. Die Installation von chrony unter Debian oder Ubuntu entfernt systemd-timesyncd automatisch, weil beide Pakete time-daemon bereitstellen. Führen Sie niemals zwei Zeit-Daemons gleichzeitig aus.

Warum schlagen meine TOTP-Codes auf einem Server fehl, funktionieren aber überall sonst?

Weil ein TOTP-Code eine Funktion der aktuellen Zeit ist. Der Code basiert auf einem Zähler, der alle 30 Sekunden weiterläuft. Daher müssen der Server und Ihr Telefon denselben Zeitschritt verwenden. Die meisten Prüfsysteme akzeptieren jeweils einen Zeitschritt davor und danach. Dadurch besteht in beiden Richtungen ein Spielraum von ungefähr einer halben Minute. Prüfen Sie auf diesem Server timedatectl. Wenn System clock synchronized den Wert no enthält, beheben Sie die Zeitsynchronisierung. Danach stimmen die Codes wieder überein, ohne dass das gemeinsame Geheimnis geändert werden muss.

Kann ich die Zeit innerhalb eines Docker-Containers setzen?

Nein, und das ist auch nicht erforderlich. Ein Container verwendet den CLOCK_REALTIME des Hosts gemeinsam, weil Linux-Zeit-Namespaces nur die monotone Uhr und die Bootzeit-Uhr virtualisieren. Ein nicht privilegierter Container erhält date: cannot set date: Operation not permitted. Das Hinzufügen von CAP_SYS_TIME ermöglicht ihm, die Uhr des Hosts zu ändern, statt eine eigene Uhr bereitzustellen. Synchronisieren Sie stattdessen den Host. Eine abweichende lokale Zeit innerhalb eines Containers ist eine Zeitzoneneinstellung. Setzen Sie daher TZ in der Container-Umgebung.

Sollte ein Server UTC oder die lokale Zeit verwenden?

UTC. Die lokale Zeit sollte erst an der Stelle angewendet werden, an der eine Person die Ausgabe liest. UTC ändert sich nicht wegen der Sommerzeit. Daher wird ein täglicher Auftrag das ganze Jahr über einmal pro Tag ausgeführt, und Zeitstempel verschiedener Server lassen sich ohne Umrechnung vergleichen. Setzen Sie UTC mit sudo timedatectl set-timezone UTC. Für eine lokale Darstellung können Sie einem einzelnen Befehl beispielsweise TZ=America/New_York date voranstellen. Dadurch ändert sich die Systemuhr nicht.