Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

Chrony – ein alternativer Zeitserver

Zeit… Ein unendliches Mysterium. Der stete Wandel. Und unsere Server müssen damit klar kommen.

Auf der gesamten Welt (sollten!) alle Maschinen wie ein gut synchronisiertes Orchester laufen. Und genau wie im echten Leben ein Trompeter, der nicht im Takt ist, am Liedgut massiven Schaden anrichtet, kann auch ein Internetserver, dessen Systemzeit nicht stimmt, böse Zwischentöne spucken.

Um dem entgegenzuwirken gibt es Zeitserver, welche den Maschinen rund um den Globus eine sauber eingetaktete Zeitquelle bieten. Wir müssen sie nur gekonnt anzapfen…

In diesem Sinne: Der Ball ist rund und ein Spiel dauert 90 Minuten. So viel ist schon mal klar. Der Rest ist Theorie. Und ab!

Kümmern wir uns heute mal um ein Orchideenthema :)

Im Basissystem installieren wir ja „ntpd“ – den „Network Time Protocol Daemon“. Der reicht auch und macht, was er soll.

Dann bin ich über diesen Artikel von heise gestolpert, der darlegt, dass Facebook intern auf Chrony wechselt. Facebook selbst hat dazu einen sehr umfangreichen Post in ihr Development Blog gestellt.

Im Zuge der Umstellung bietet Facebook aus seinem Netzwerk nun mehrere öffentlich zugängliche Zeitserver mit verschiedenen Standorten auf der ganze Welt an.

Hey, hab ich mir gedacht, warum dieses Thema nicht auch abschließend behandeln. Schauen wir uns das doch mal genauer an…

Chrony installieren

Die Installation geht sehr einfach und schnell mit einem Kommando:

apt -y install chrony dnsutils

[...]
Die folgenden Pakete werden ENTFERNT:
  ntp
Die folgenden NEUEN Pakete werden installiert:
  chrony dnsutils libirs161
[...]

Dabei wird der „ntp“-Server entfernt und stattdessen „chrony“ installiert. Die beiden würden sich sonst ins Gehege kommen. Wie zwei Web- oder Mailserver, die auch nicht einfach so parallel auf der gleichen Maschine laufen dürfen.

Chrony besteht aus zwei Teilen:

chronyd – der eigentliche Daemon, der im Hintergrund unseres Systems läuft.
chronyc – das Kommandozeilen-Tool, mit dem wir den Daemon beauskunften.

Nun müssen wir nachsehen, ob Chrony „enabled“ wurde, also beim Systemstart automatisch geladen wird:

systemctl status chronyd

● chrony.service - chrony, an NTP client/server           # |== hier müsste "enabled" stehen...
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-04-12 20:19:11 CEST; 31s ago
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)
 Main PID: 23266 (chronyd)
    Tasks: 2 (limit: 4701)
   Memory: 1.3M
   CGroup: /system.slice/chrony.service
           ├─23266 /usr/sbin/chronyd -F -1
           └─23267 /usr/sbin/chronyd -F -1

Apr 12 20:19:11 xp-server.de systemd[1]: Starting chrony, an NTP client/server...
Apr 12 20:19:11 xp-server.de chronyd[23266]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
Apr 12 20:19:11 xp-server.de chronyd[23266]: Frequency 10.473 +/- 0.293 ppm read from /var/lib/chrony/chrony.drift
Apr 12 20:19:11 xp-server.de chronyd[23266]: Loaded seccomp filter
Apr 12 20:19:11 xp-server.de systemd[1]: Started chrony, an NTP client/server.
Apr 12 20:19:17 xp-server.de chronyd[23266]: Selected source 2a03:2880:ff09::123

Steht hier „enabled“, dann passt alles. Sollte „disabled“ auftauchen, müssen wir den Dienst noch „enablen“:

systemctl enable chronyd

Chrony konfigurieren

Nachdem Chrony installiert wurde, tragen wir ihm die Zeitserver ein, von denen er sich mit der aktuellen Systemzeit versorgen soll. Die nehmen wir von Google und Facebook, weil diese beiden absolute Dickschiffe im Netz sind und den Laden am Laufen halten. Darum vertraue ich denen, dass sie – schon aus eigenem Interesse – eine vernünftige Zeit ausliefern, der man vertrauen kann.

Die Server sind über den ganzen Globus verteilt, damit man immer auch in seiner eigenen Region ein System stehen hat, das man „schnell“ ansprechen kann. Da macht nämlich die Laufzeit des Signals durch das WWW einen Faktor aus, den unser Zeitsystem später korrigieren muss. Die Konfiguration ist ebenfalls schnell erledigt:

nano /etc/chrony/chrony.conf

### Wir kommentieren den voreingestellten Pool aus:
#pool 2.debian.pool.ntp.org iburst

### Dafür tragen wir gleich darunter unsere neuen Zeitserver ein:
server time1.google.com iburst
server time2.google.com iburst
server time3.google.com iburst
server time4.google.com iburst
server time1.facebook.com iburst
server time2.facebook.com iburst
server time3.facebook.com iburst
server time4.facebook.com iburst
server time5.facebook.com iburst

Wir speichern die Änderungen. Dann starten wir den Chrony Daemon neu, damit er sich die geänderte Config lädt und entsprechend auch unsere gerade eingestellten Server benutzt.

Chrony neustarten und den Status abfragen

systemctl restart chronyd

Jetzt ist der Dienst neu gestartet. Schauen wir mal, was er macht:

chronyc activity

200 OK
0 sources online
0 sources offline
9 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address

Chrony „pingt“ die neun Server an. Sobald das Ergebnis vorliegt, werden die Server „online“ geschaltet.
Ein paar Sekunden später:

chronyc activity

200 OK
9 sources online
0 sources offline
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address

Schön, die Server wurden abgefragt und sind jetzt verfügbar.
Mehr Info, bitte:

chronyc tracking

Reference ID    : A8EF0BC5 (time1.facebook.com)
Stratum         : 2
Ref time (UTC)  : Sun Mar 29 11:55:42 2020
System time     : 0.000000003 seconds fast of NTP time
Last offset     : -0.000026087 seconds
RMS offset      : 0.000026087 seconds
Frequency       : 10.218 ppm fast
Residual freq   : -2.659 ppm
Skew            : 2.513 ppm
Root delay      : 0.003839974 seconds
Root dispersion : 0.000210573 seconds
Update interval : 1.8 seconds
Leap status     : Normal

Chrony hat sich für einen Zeitserver von Facebook entschieden.
Die genauen Werte sind für uns aber nicht wirklich von Bedeutung. Hauptsache, er macht „sein Ding“ und setzt uns die Zeit richtig.

Was haben wir denn noch für Quellen?

chronyc sources -v

210 Number of sources = 9

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time1.google.com              1   6    17    16   -138us[ -138us] +/- 5285us
^+ time2.google.com              1   6    17    17    -62us[  -88us] +/- 5503us
^+ time3.google.com              1   6    17    17    -50us[  -76us] +/- 5380us
^+ time4.google.com              1   6    17    16    -19us[  -45us] +/- 5495us
^* time1.facebook.com            1   6    17    16  -9567ns[  -36us] +/- 2073us
^- time2.facebook.com            1   6    17    17  +2980us[+2953us] +/-   11ms
^- time3.facebook.com            1   6    17    17    -16us[  -42us] +/- 6387us
^+ time4.facebook.com            1   6    17    16   -162ns[  -26us] +/- 2093us
^+ time5.facebook.com            1   6    17    17    +50us[  +24us] +/- 3997us

Mit diesem Kommando erhalten wir eine detaillierte Übersicht zu allen neun Zeitservern, welche wir eingetragen haben. Daraus setzt sich Chrony nun unsere Systemzeit zusammen.

systemd Zeitgeber ausschalten

Sven hat mich freundlicherweise darauf hingewiesen, den systemd-Zeitgeber abzuschalten, da wir ihn ja dank Chrony nicht mehr brauchen…

timedatectl set-ntp 0

Fazit

Chrony – besser oder schlechter als ntpd?
„Time will tell“ (Pun not intendet)…

Nein, ohne Schmarrn. Für einen kleinen Einzelserver sollte das ziemlich wurscht sein, ob wir über ntpd oder Chrony unsere Zeit synchronisieren. In einem riesigen Serververbund, wie den Facebook Rechenzentren, macht das allerdings schon was aus. Und wenn die sagen, dass bei denen Chrony Vorteile zum ntpd hat…?

In der Gastronomie haben die auch das HACCP-Konzept bis in die kleinste Dorfwirtschaft aufgedrückt bekommen. Das ist ein Protokoll, das die NASA dafür entwickelt hat, bestmöglich sicherzustellen, dass Astronautennahrung nicht kontaminiert wird. Weil – schlecht. Und was für die NASA toll ist – hey – das kann man natürlich auch bis ins letzte Dorfgasthaus übertragen. Overkill hin oder her.

Sprich wenn Facebook sagt, Chrony ist für ihr Netzwerk OK… Dann bin ich mir sicher, dass es für unseren kleinen Server auch passt!

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top