NTP

Dieser Artikel oder Artikelabschnitt ist noch nicht vollständig!

---

Dieser Artikel behandelt die Installation, Konfiguration und Verwendung des NTP-Daemons „ntpd“ und gibt zudem vorher einen Überblick über NTP sowie die Bedeutung der Uhrzeit im Computerbereich.

Vorüberlegungen

Durch verschiedene, hardwareseitige Dinge kommt es bei den allermeisten Computern früher oder später zu Differenzen zur tatsächlichen Uhrzeit, je nach Dauer der Nicht-Korrektur und den Eigenschaften der Hardware von einigen wenigen Sekunden bis hin zu mehreren Minuten im Monat. Der NTP-Daemon synchronisiert die aktuelle Uhrzeit des Clients mit Hilfe eines Zeitservers, so dass der Client immer über eine möglichst aktuelle Uhrzeit verfügt.

Eine genaue Uhrzeit ist zum Beispiel auf Mail- oder Webservern wichtig, da an die Uhrzeit häufig noch andere Dinge gekoppelt sind. Beispielsweise könnte eine Mail auf einem Mailserver mit einer vorgehenden Uhr weitergereicht werden, und ein anderer Mailserver erhält damit eine Mail „aus der Zukunft“ – Dies könnte zum Ablehnen der Mail aus Spamverdachtsgründen resultieren.

Auch Clients profitieren von einer genauen Uhrzeit. Wenn die lokale Uhr nachgeht, erhält man plötzlich nur noch e-Mails „aus der Zukunft“, da es zum Beispiel anstelle 14:38:47 Uhr schon 14:39:52 Uhr ist. Auch beim Bearbeiten von Datenbanken, oder generell beim Arbeiten mit Daten kann es aufgrund einer falschen Uhrzeit zu Inkonsistenzen kommen.

Die meisten Computer verfügen nicht über einen hinreichend stabilen Taktgeber, wie einen thermostatgesteuerten Quarzoszillator oder einen Oszillator auf Rubidium-Basis und verfügen für gewöhnlich auch nicht über eine ausreichend stabile Energiequelle, um derlei Hardware zuverlässig zu betreiben, daher kommt es früher oder später unweigerlich zu einer Differenz zwischen lokaler Systemzeit und einer Referenzzeit (beispielsweise vom Funksender DCF77, der das Westliche Europa mit einer exakten Referenzzeit versorgt).

Abhilfe gegen dieses Problem bietet sehr zuverlässig NTP, mittels welchem mithilfe des NTP-Daemons die lokale Uhrzeit mit einer genauen Referenzzeit synchronisiert werden kann.

Installation

ntpd ist im Paket „ntp“ im community-Reposity enthalten und kann aus diesem installiert werden.

pacman -Sy ntp

Nach der Installation muss der Daemon noch in das DAEMONS-Array in der rc.conf eingetragen werden. Vor der Verwendung muss der Daemon allerdings noch etwas konfiguriert werden.

Konfiguration

In der Datei „/etc/ntp.conf“ werden die Parameter des NTP-Daemons definiert. Es wird in diesem Artikel davon ausgegangen, dass der Rechner nicht als Server für andere Rechner dienen soll (anhand der Kommentare in der Datei ist aber relativ einfach ersichtlich, wie dies zu bewerkstelligen ist).

Zeitserver(-Pool)

In einem Zeitserver-Pool sind mehrere Zeitserver vereint, bei jeder Anfrage wird zufallsgesteuert ein Zeitserver aus diesem Pool befragt. Dies hat zum Einen den Vorteil, dass die Ausfallsicherheit erhöht wird (wenn ein Server nicht antworten sollte, wird einfach ein anderer Server verwendet), und zum Anderen wird so die Last der weltweiten Anfragen besser verteilt.

Um den deutschen NTP-Zeitserverpool zu verwenden, ist folgendes in der „/etc/ntp.conf“ zu definieren:

server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org

Somit werden alle vier Anlaufstellen des deutschen NTP-Zeitserverpools verwendet. Man kann hier auch einen einzigen Server gezielt eintragen.

server ntp.example.com

Es ist jedoch nicht ratsam, einen einzigen Server zur Synchronisation anzugeben, sondern immer einen Pool zu verwenden. Wenn man in einem Netzwerk allerdings einen eigenen Zeitserver betreibt, kann man diesen natürlich auch als einzigen Server angeben, ansonsten sollte man immer einen Zeitserver-Pool verwenden.

Driftfile

Wie oben bereits angesprochen ist der lokale Taktgeber für gewöhnlich nicht ganz genau. Eine Sekunde kann mitunter länger oder kürzer sein, als das 9 192 631 770-fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustandes von Atomen des Nuklids 133Cs entsprechenden Strahlung. (so die offizielle Definition einer Sekunde).

Im Driftfile wird dieser „drift“, also die Abweichung zu einer Referenzsekunde vermerkt. Dies geschieht durch den ntpd selbständig, sobald die entsprechende Information ermittelt ist. Sollte nun mal keine synchronisation mit einem Zeitserver möglich sein, wird anhand der drift-Angabe die lokale Systemzeit korrigiert. Dies funktioniert für eine gewisse Dauer relativ zuverlässig.

driftfile /var/lib/ntp/ntp.drift

Dieser Standardwert sollte belassen werden, wenn nichts elementar Wichtiges dagegen spricht.

Zugriffskontrolle

Standardmäßig erlaubt ntpd es, dass jeder beliebige Client die Uhrzeit abfragen und Serveroptionen ändern kann. Wenn man keinen NTP-Server betreiben möchte, sondern ntpd lediglich dazu verwenden möchte, die lokale Systemzeit genau zu halten, muss man dies durch eine restrict-Regel definieren

restrict default nomodify nopeer
restrict 127.0.0.1

Dies definiert, dass jeder abfragende Client standardmäßig keine Änderungen am Server vornehmen darf, und dass er den Server nicht als Peer in einem NTP-Zeitserverpool ansehen darf (komplettes sperren sämtlicher Kommunikation ist mittels „restrict default ignore“ möglich). Die zweite Zeile definiert, dass 127.0.0.1 vollen Zugriff hat, diese IP ist immer der Rechner selbst.

In der Konfigurationsdatei sowie der Manpage zu ntpd stehen noch weitere Beispiele der Zugriffskontrolle.

Port

NTP läuft über den UDP-Port 123. Dieser muss in einer eventuell vorhandenen Firewall freigegeben werden, bzw. muss auf dem Router entsprechendes Portforwarding eingerichtet werden.

Beispieldatei

Eine vollständige, funktionierende, unkommentierte Konfigurationsdatei für den NTP-Daemon sieht somit so aus:

server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org
driftfile /var/lib/ntp/ntp.drift
restrict default nomodify nopeer
restrict 127.0.0.1

Mit dieser Datei wird der NTP-Daemon so konfiguriert, dass er den gesamten offiziellen Deutschland-Pool von ntp.org verwendet, die angegebene drift-Datei benutzt, und nur dem Rechner, auf dem der Daemon läuft, vollen Zugriff gestattet, und sich ansonsten standardmäßig zu verhalten.

Startvorgang

Nach dem manuellen Starten des Daemons mittels „/etc/rc.d/ntpd start“ als root, oder einem Neustart des Rechners, wird der NTP-Daemon initialisiert. Mit oben angegebener Konfiguration erscheint der Startvorgang in der Logdatei „/var/log/daemon.log“.

ntpd 4.2.4p6@1.1549-o Tue Feb 10 04:47:14 UTC 2009 (1)
precision = 1.000 usec
ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Listening on interface #1 lo, 127.0.0.1#123 Enabled
Listening on interface #2 eth0, 10.10.0.10#123 Enabled
kernel time sync status 0040
frequency initialized -4.873 PPM from /var/lib/ntp/ntp.drift

Neben einiger System- und Genauigkeits-Angaben werden hier auch die restrict-Regeln ausgeführt und dokumentiert.

Synchronisation

Einige Minuten nach Start des NTP-Daemons synchronisiert dieser sich das erste mal mit einem NTP-Server.

synchronized to 141.40.103.103, stratum 2
kernel time sync status change 0001

In der NTP-Terminologie werden verschiedene Zeitservertypen Stratum (Latein für „Schicht“) genannt, jede dieser Strata ist mit einer Nummer versehen. Es gibt nach der NTP-Spezifikation 16 Strata (0 bis 15). In der Praxis werden allerdings nur die ersten vier verwendet.

Stratum 0 ist ein Zeitgeber wie eine Atomuhr. In Stratum 1 befinden sich alle Zeitserver, die direkt an einen Zeitgeber aus Stratum 0 angebunden sind, etwa mit einem seriellen Kabel, oder weil die zeitgebende Hardware direkt in den Zeitserver eingebaut ist. In Stratum 2 befinden sich alle Server, die einen Server aus Stratum 1 abfragen. In Stratum 3 befinden sich alle Server, die einen Server aus Stratum 2 abfragen, und so weiter.

Feb 15 15:40:28: synchronized to 213.198.55.2, stratum 2
Feb 15 15:42:38: synchronized to 141.40.103.103, stratum 2
Feb 15 15:49:23: synchronized to 213.198.55.2, stratum 2
Feb 15 15:53:56: synchronized to 141.40.103.103, stratum 2
Feb 15 15:58:56: synchronized to 78.46.51.71, stratum 2

Durch den NTP-Daemon wird die Zeit kontinuierlich mit der Referenzzeit synchron gehalten. Sollte die lokale Zeit plötzlich einen relativ großen Unterschied zur Referenzzeit aufweisen, wird dies mittels …

time reset +0.153894 s

… in der Logdatei vermerkt, und die Zeit dann korrigiert, im Beispiel um rund 0,15 Sekunden.

Problembehebung

Es kann vorkommen, dass die lokale Uhrzeit über einen gewissen Sekundenwert hinaus ungenau ist, dieses so genannte „sanity limit“ steht standardmäßig auf 1000 Sekunden. Beim ersten Synchronisieren nach dem Start wird das Limit nicht berücksichtigt und die Uhrzeit auf jeden Fall korrigiert, wenn ein Server erreichbar ist. Wenn nach dem ersten Synchronisieren die Differenz zwischen Referenzzeit und lokaler Zeit über dem Limit liegt, wird nicht synchronisiert

time correction of 4290 seconds exceeds sanity limit (1000); set
  clock manually to the correct UTC time.

Dies ist so, damit es nicht zu sehr großen Zeitdifferenzen von einer Sekunde auf die Andere kommt, da dadurch mitunter erhebliche Inkonsistenzen auftreten können.

Manueller Abgleich

Das Programm „ntpdate“, welches ein Teil des „ntp“-Paketes ist kann verwendet werden, um die Zeit einmalig einzustellen. Allerdings ist angeraten, das Programm nicht mehr zu verwenden, da es „bald“ aus dem Paket genommen werden soll. Stattdessen soll ntpd mit dem Parameter „-q“ verwendet werden, um die Zeit einmalig zu setzen. Bei der Standard-Konfiguration von Arch benötigt man zum setzen der Uhrzeit root-Rechte.

ntpd -q

Sollte die Differenz mehr betragen als das „sanity limit“, so muss noch der Parameter „-g“ verwendet werden. Dieser steht für das „panicgate“ und bestimmt, dass auf jeden Fall synchronisiert werden soll, unabhängig davon, wie groß die Differenz zur Referenzzeit ist.

Hinweis

Es wird davon abgeraten, „ntpdate“ oder „ntpd -q“ per Cronjob regelmäßig laufen zu lassen. Vor allem der stündliche einmalige Abgleich ist mitunter ungenau, da viele Clients relativ gleichzeitig einen Server abfragen. Dies erzeugt nicht nur unnötige Lastspitzen, sondern sorgt auch für eine hohe Latenz bei der Abfrage.

Der manuelle Abgleich kann bei neu installierten Systemen verwendet werden, wenn man unbedingt sofort die genaue Uhrzeit benötigt, und man nicht die Minuten bis zur Erstsynchronisation durch ntpd warten kann, oder der Abgleich mittels ntpd aufgrund einer zu großen Differenz fehlschlägt.

Sollte man permanent mit extrem großen Genauigkeitsproblemen zu kämpfen haben, sollte man, statt die Symptome zu bekämpfen, besser versuchen, die Ursache des Problems zu lösen. Es könnte hier eine überalterte Bios-Batterie oder ein defekter Taktgeber vorhanden sein, oder der Kernel hat einen Bug, etc.

Erzwingen der Synchronisation

Sollte nicht die Möglichkeit bestehen, das Problem zu beheben, und will man auch nicht regelmäßig einen manuellen Abgleich ausführen, so bietet sich an, in der Datei „/etc/rc.conf“ in eine Zeile …

ntpd_flags="-g"

… zu schreiben. Dies erzwingt bei jedem Ausführen der Synchronisation, dass die Zeit unabhängig der Differenz abgeglichen wird, sofern ein Zeitserver verfügbar ist.

Weitere Tools

Zum Abfragen von NTP-Zeitservern, und zum Einstellen von Optionen ebendieser befinden sich im ntp-Paket neben „ntpd“ und „ntpdate“ noch weitere Tools.

• ntpc
• ntpq
• ntptime
• ntptrace

Auf diese Tools wird in diesem Artikel allerdings nicht weiter eingegangen, da deren Verwendung Erfahrung im Umgang mit Linux erfordert, und die Tools zudem sowieso nur in wenigen Ausnahmefällen überhaupt benutzt werden müssen.

Weblinks

• Beschreibung des NTP in der Wikipedia
• Seite zum deutschen NTP-Zeitserverpool
• FAQ-Seite der PTB zum Thema Zeitserver

Todo

• Startvorgang Eine kurze Beschreibung der Zeilen, die nicht Aufgrund der restrict-Regeln entstanden sind, wäre schön, bis auf die Versionsnummer ist mir allerdings nichts so wirklich einleuchtend, und die Informationen dazu sind auch nur sehr spärlich …
• Ich fand keine Option, das sanity limit in der Konfigurationsdatei zu definieren. Geht das irgendwie?