Zeitabgleich mit NTP

Zeitabgleich via NTP – Eine Einführung Autor: Xero

Voraussetzungen

Dieses Tutorial setzt auf SuSE 9.1 Prof auf, alle Befehle und Beispiele wurden mit dieser Version durchgeführt. Natürlich existierte NTP schon vorher und sollte auch mit ältern Versionen funktionieren. Die Möglichkeit über YaST existiert seit 9.0 .

Einleitung

Was ist NTP?

Das NTP Projekt (NTP = Network Time Protocol , http://www.ntp.org ) ist eine Sammlung mehrere Programme und eines Daemonen, die dazu entwickelt wurden, die Systemzeit eines Rechners mit Zeitsignalen abzugleichen. Diese können dabei von der Lokalen Hardwareuhr kommen, die in jedem Rechner tickt. Allerdings sind diese konstruktionsbedingt nicht sehr genau. Besser ist es, die Zeit über Zeitserver im Netz oder auch über Funkuhren oder sogar GPS-Signale abgleichen zu lassen.

Warum soll ich meine Zeit abgleichen lasen?

Bei einfachen Desktop-Heimrechnern reicht es vielleicht aus, die Uhr alle Paar Wochen von Hand nachzustellen. Doch erstens ist das lästig, und zweitens gibt es in Netzwerken noch viel größere Gründe, die eine exakte Zeit verlangen. Was ist z.B. mit e-mails, die man mit 2 Stunden hinterherhinkender Zeit verschickt? Beim Empfänger werden die mails meist nach Absenddatum geordnet, womit die eigentlich neue Mail eventuell unter schon gelesenen untergeht, da sie nach Absenddatum schon 2 Stunden alt ist. Oder was ist in Büros mit Terminen, die man in seinem Terminkalender gespeichert hat? Was hilft einem eine Erinnerungsfunktion, wenn sie erst 10 Minuten nach Anfang der Super-Wichtigen Sitzung mit dem Chef Alarm schlägt? Job weg, Obdachlosigkeit, Alkoholsucht... Man sieht, eine genaue Zeit ist in der Heutigen Gesellschaft wichtig Wink Ach ja, und nicht zu vergessen: Time is Money!!!

Zeitabgleich

Na gut, überzeugt. Aber wie fange ich das an?

Nun, der einfachste Weg, seine Systemzeit auf dem laufenden zu halten, führt wohl über das Internet. Das wohl grundlegendste Kommando von NTP ist „ntpdate“. Mit ihm werden Zeitserver (Server= Rechner, der einen Dienst anbieten, in diesem Fall eine exakte Zeit) nach der aktuellen Zeit gefragt und die Systemzeit (also die Zeit des Rechners, an dem ihr sitzt) entsprechend gestellt. Dem Befehl werden die gewünschten Server einfach als Argument übergeben. Es ist möglich und sehr sinnvoll, mehrere Server zu übergeben, denn NTP kann dann entscheiden, welcher Server am nächsten an der richtigen „Echtzeit“ liegt und auch „schwarze Schafe“ aussondern, die ansonsten dem Rechner eine schlechte Zeit übergeben.

Na dann machen wir uns mal daran! Wir rufen eine Konsole auf, entweder mit Strg+Alt+F(1-6) und loggen uns dort als root ein, oder grafisch in KDE mit dem kleinen Muschelsymbol unten links. Im zweiten Fall wird man mit dem Befehl

su -

zu root. Dann folgt die Eingabe des eigentlichen Befehls:

ntpdate de.pool.ntp.org  de.pool.ntp.org  de.pool.ntp.org

Damit haben wir ihm 3 Server übergeben. Der aufmerksame Leser wird sich jetzt sicher fragen „Das ist doch 3 mal der gleiche!!??“. Man lese sich bitte dazu den Link über pool.ntp.org am Ende des Tutorial durch. Kurz kann man dazu sagen: es schient bloß dreimal der gleiche, in Wirklichkeit wird die Last auf mehrere unterschiedliche Server verteilt, womit Ressourcen geschont werden.

Es sollte nun (bestehende Internetverbindung vorrausgesetzt!!!) eine Ausgabe wie folgt erschienen:

Code: 8 Dec 18:54:55 ntpdate: adjust time server 131.188.34.45 offset 0.038449

Dann hat alles geklappt, und die Systemzeit ist aktuell(=synchronisiert)! Herzlichen Glückwunsch!

Und was mache ich, wenn meine Systemzeit wieder falsch geht? Ich will nicht alle 2 Tage den Befehl noch mal eingeben!!

Ja, da hast du recht. Außerdem kann der ntpdate-Befehl ungute Auswirkungen haben. Denn er stellt die Uhr hart ein, macht also unter Umständen starke Sprünge.

Was ist daran so schlimm?

Nun, stellen wir uns einfach mal vor, du willst ein Programm selber kompilieren. Du lädst es dir runter und entpackst es, und es bekommt eine Zeitmarke. Jetzt wird die Zeit via ntpdate aktualisiert, und um 2 Stunden zurückgestellt. Tja, und jetzt kannst du das Programm nicht kompilieren, da make nichts anfasst, was eine Zeitmarke hat, die erst in der Zukunft liegt! Toll, was? Und so Beispiele gibt es noch mehr.

Ok, also nicht so. Aber wie dann?

Die Antwort lautet XNTPD! Das ist der Daemon vom NTP Projekt. Er hat einen ganz entscheidenden Vorteil: Er stellt die Zeit langsam auf die Richtige um! Keine harten Sprünge mehr, sondern langsame Annäherung an die Echtzeit. Und er merkt sich Verschiebungen der Lokalen Zeit, so dass er schon vorausberechnet, wie sich die Uhr verstellen wird, und damit auch ohne Zeitserver im Netz (z.B. bei vorübergehendem Ausfall) die Uhr korrekt laufen lassen (=Stabilisation der Zeit).

Bevor wir uns daran machen, sollten wir aber erst die Uhr per ntpdate auf die aktuelle Zeit bringen, so dass XNTP keine großen Unterschiede ausgleichen muss und sich langsam an die Stabilisation der Zeit machen kann. Dazu führen wir den Befehl

Code: ntpdate ptbtime1.ptb.de

aus. Genau gleich wie oben, bloß das wir hier einen Server nehmen, dem man 100%ig vertrauen kann, nämlich die Atomuhr der Physikalisch-Technischen Bundesanstalt, um eine möglichst genaue Anfangszeit zu haben . Dann geht es an den XNTPD:

Es gibt mehrer Möglichkeiten den XNTPD zu konfigurieren. Die einfachste führt über YaST im grafischen Modus. In YaST geht man unter Netzwerkdienste-->NTP-Client (Client=Rechner, der einen Dienst in Anspruch nimmt).

Im folgenden Konfigurationsdialog aktiviert man das Kästchen „Beim Systemstart“, um den XNTPD schon beim Hochfahren zu starten. Dann geht man auf „Komplexe Konfiguration“ und klickt auf „Hinzufügen“. Nun wählt man „Server“ aus, klickt auf „Weiter“, trägt unter „NTP-Server“ „de.pool.ntp.org“ ein, und klickt auf „OK“. Nun hat man wie beim „ntpdate“ Programm einen Server übergeben. Aber auch hier sind mehrere Server sinnvoll, also führt man den „Hinzufügen“-Schritt noch zwei mal genauso aus, um dann wie beim „ntpdate“ 3 Server zu haben. Nun reicht noch ein Klick auf „Beenden“, und schon steht eure ständig aktuelle Systemzeit (nach einem Neustart des XNTPD mit dem Befehl „rcxntpd restart“ auf der Konsole als root)!

Ich habe mehrere Rechner bei mir im LAN. Also mach ich bei allen das gleiche, oder?

Nein, besser nicht. Das Internet hat begrenzte Ressourcen, und Zeitserver sind recht belastet. Also ist eine andere Möglichkeit besser. Und zwar, einen Rechner wie oben beschreiben zu konfigurieren. Und nun, auch was tolles am XNTP, können alle anderen Rechner im LAN diesen als Server benutzen. Ihr müsst genau das gleiche wie oben durchführen, nur eben diesmal nicht drei Server, sondern einmal euren eben eingerichteten (die IP oder den Hostnamen) angeben. Das war´s schon.

Komplexe Konfiguration / Sicherheit

Mit YaST lässt sich nur die grundlegenste Konfigurationsarbeit erledigen. Wer tiefer Einsteigen will, muss sich um die Konfigurationsdatei /etc/ntp.conf bemühen. Also schauen wir uns die dann mal genauer an: Unter der Konsole als root rufen wir die Datei mit

vi /etc/ntp.conf

auf. Dort sehen wir die Standard-Suse-Datei, mit einigen Beispielen. Alles, was mit einem # beginnt, ist ein Kommentar und wird vom Programm nicht beachtet. Als erstes wichtiges (ohne #) sehen wir zwei Zeilen, die die lokale Hardware-Uhr beschreiben . Als nächstes folgt die Pfadangabe für das Drift-File, in dem Statistiken zur Abweichung der Systemzeit gesammelt werden, mit denen es möglich ist,. auch ohne erreichbare Zeitserver die Zeit konstant zu halten (wie oben schon mal erwähnt.) Dann die Pfandangabe für das Log-File. Und dann sieht man schon den Eintrag den wir mit YaST getätigt haben, unsere eigenen Server!! Man sieht, das man diese auch von Hand eintragen könnte, im Syntax (=Aufbau)

server [Name des Servers]

XNTP kann noch einiges mehr, allerdings gehört das hier nicht her. Der geneigte Leser wird sich mit den Links zufrieden geben müssen, die unten stehe. Auf was ich jetzt noch eingehen werde ist die Sicherheit, die nicht aus dem Auge gelassen werden darf. Ich werde auf 2 Mechanismen eingehen, keys und restrict Anweisungen.

Keys

Keys sind Schlüssel, die zu gegenseitigen Authentifizierung (= Bestätigung der Identität, so dass man sich vertrauen kann) zwischen Server und Client dienen. Vor allem LANs mit mehreren Rechner und einem NTP-Server sollten mit Keys arbeiten.

Als erstes muss eine Datei definiert werden, in der die Keys stehen. Dazu kommentieren wir in /etc/ntp.conf die Zeile

# keys /etc/ntp.keys            # path for keys file

aus (führendes # löschen) (mit I in den Bearbeiten-Modus des Editors wechseln). Das muss auf Server und Client Seite gemacht werden. Damit haben wir eine Datei festgelegt in der unsere Schlüssel stehen. Jetzt müssen wir die nur noch erstellen! Also machen wir eine mit

vi /etc/ntp.keys

(auch auf Client und Server) und tragen dort unsere Schlüssel ein. Die Datei hat folgendes Format: Sie ist in drei Spalten aufgeteilt. In der ersten steht eine Zahl, die zur Identifikation des Schlüssels dient. Mit ihr werden die Schlüssel dann angesprochen. In der zweiten steht ein Buchstabe, der die Art der Keys angibt. Ich verwende hier M , was einem Key aus Ziffern und Buchstabe verschlüsselt mit dem MD5-Algorithmus entspricht. In der Dritten Zeile steht schließlich der eigentliche Key (mit M bis zu 8 Zeichen lang).

Wir legen nun auf Clients und Server die gleichen Keys an, ungefähr so:

Code:

1  M Hallo
14 M Tschö

Natürlich muss ein individuelles Passwort genommen werden!!! Nun kann man in der Konfigurationsdatei /etc/ntp.conf mit der Zeile

trustedkeys 1 14

angeben, dass diesen Keys vertraut wird, daher, wenn man sich mit diesen Authentifiziert, wird eine Synchronisation zugelassen. Allerdings muss man einem Client ja noch sagen, dass er einem Server einen Key übergeben soll. Das geschieht, indem man die Zeile

server [Euer Server]

um

server [Euer Server] key 1

ergänzt. Somit wird [Eurem Server] der Key 1 übergeben, und wenn dieser Server diesem Key vertraut, wird die Synchronisation erlaubt.

Wenn man die Zeile

enable auth

noch einfügt, werden nur authentifizierte Verbindungen zugelassen, ansonsten geht es auch ohne. Keys können noch mehr, aber dazu bitte andere Dokus heranziehen.

Restrict

Außerdem gibt es noch restrict Anweisungen, mit denen man den Zugriff nur von bestimmten Rechner erlauben kann. Sie dienen also nicht zur Authentifizierung, sondern der Zugriffs-Kontrolle („Access Control“) Diese können auch sowohl auf Clients wie auf Servern gesetzt werden. Man trägt sie in die /etc/ntp.conf ein, und zwar mit folgendem Syntax:

restrict IP [mask NETZMASKE] [FLAG] [FLAG] […]

Alles was in [] steht ist optional. Anstatt einer IP kann auch der wert default verwendet werden. Ohne Flags ist alles erlaubt, den nach dem Prinzip schränken Flags den von vornherein vorhandene vollen Zugriff ein. Am besten erläutere ich es an Beispielen:

restrict default ignore

könnte z.B. die erste Zeile lauten. Damit wird erst mal jedem (default) alles verweigert (Flag ignore). In der nächsten Zeile könnte wir dann diese Bestimmung lockern, und einem Rechner die Synchronisation, aber sonst nichts erlauben:

restrict 192.168.1.1 noquery nomodify notrap

erlaubt dem Rechner 192.168.1.1 die Synchronisation, aber nicht, den Server zu administrieren, oder ihn zu überwachen (Flags noquery, nomodify, notrap). Oder das gleiche für einen ganzen Netzbereich, alles was mit 192.168.1 anfängt:

restrict 192.168.1.0 mask 255.255.255.0 noquery nomodify notrap

Mit der abschließenden Zeile

restrict 127.0.0.1

erlauben wir noch localhost (dem lokalen Rechner) den kompletten Zugriff (Keine Flags). So läst sich ein umfassender Schutz aufbauen, indem man z.B. auf dem Server nur dem eigenen Netzbereich das Synchronisieren erlaubt, und auf den Clients nur dem Server. Mit default Anweisungen lässt sich auch allgemein das Administrieren und Überwachen verbieten:

restrict default noquery nomodify notrap

Mit diesen Maßnahem sollte das ganze recht sicher sein. Um die Änderungen wirksam zumachen, muss man den XNTPD mit dem befehl „rcxntpd restart“ auf der Konsole als root neustarten.

Abschließend sollte man noch beachten: -Die Konfigurationsdateien /etc/ntp.conf und /etc/ntp.keys sollten nur von root lesbar sein, sonst nichts (nach dem Abschluss der Konfiguration Rechte setzten). -Es sollte eine Firewall laufen, damit von außen keine ungebeten Gäste hereinkommen, und nach innen mit restrict und keys abgeschlossen werden. -Sollte der Rechner an sich unsicher sein, hilft auch das alles nichts!

Eine ganze Konfigurationsdatei auf dem Server könnte ungefähr so aussehen:

server 127.127.1.0              # local clock (LCL)
fudge  127.127.1.0 stratum 10   # LCL is unsynchronized

server de.pool.ntp.org
server de.pool.ntp.org
server de.pool.ntp.org 

driftfile /var/lib/ntp/ntp.drift # path for drift file
logfile   /var/log/ntp          # alternate log file

trustedkeys 1
keys /etc/ntp.keys 

restrict default noquery nomodify notrap
restrict 127.0.0.1

Und auf dem Client so:

server 127.127.1.0              # local clock (LCL)
fudge  127.127.1.0 stratum 10   # LCL is unsynchronized

server [Euer Server] key 1

driftfile /var/lib/ntp/ntp.drift # path for drift file
logfile   /var/log/ntp          # alternate log file

trustedkeys 1
enable auth
keys /etc/ntp.keys

restrict default ignore
restrict 192.168.1.1 noquery nomodify notrap
restrict 127.0.0.1

Noch Fragen?

Meine Zeit stimmt nicht, obwohl keine Fehlermeldungen kommen. Was tun?

Nach meiner Erfahrung sollte man in diesem Fall den Befehl

Code:

rm /etc/adjtime

durchführen.

Wenn ich ntpdate ausführe, erscheint die Fehlermeldung „ntpdate[13944]: the NTP socket is in use, exiting“!?

Wahrscheinlich läuft der XNTPD gerade. Kann man mit „rcxntpd status“ nachprüfen.

Wie war das mit Funkuhren?

Ja, auch das geht, guckt z.B. mal auf die Homepage von Linum ( http://www.linum.com ) dort kann man Funkuhren für NTP kaufen, und dort gibt es ein recht gute Anleitung dafür.

Kann NTP noch mehr?

Ja, noch viel mehr! Aber dazu soll man sich die Dokumentationen auf www.ntp.org angucken.

Weitere Infos

Die Homepage des NTP Projektes, mit vielen sehr guten Links zu (auch externen) Dokumentationen: http://www.ntp.org

Die Homepage des pool.ntp Projekts: http://www.pool.ntp.org

Die Physikalisch-Technische Bundesanstalt: http://www.ptb.de