Der xntpd ist ein Dienst, der die Zeit eines Linuxservers
synchronisiert. Dazu verwendet er, wie ntpdate, Zeitserver im
Internet. Der Dienst arbeitet jedoch noch aufwendiger. Zunächst
sendet er alle paar Minuten (je nach Genauigkeit) Zeitpackete, um
die Zeit ständig aktuell zu halten. Dies ist notwendig, da die
Kerneluhr (und auch die Hardware- Echtzeituhr) nicht so genau
sind und beispielsweise temperaturbedingter Schwankungen
unterliegen.
Daher muß die Kerneluhr auch nachgestellt werden. Der xntpd macht
das Nachstellen allerdings sehr geschickt: er setzt nicht einfach
ruckartig die Zeit eine Sekunde zurück (oder natürlich vor),
sondern er bremst die Kerneluhr ein kleines bißchen ab, bis die
Zeiten gleich sind. Im Prinzip regelt der Dienst also die
Geschwindigkeit der Kerneluhr (und gleicht so die
temperaturabhängiger Schwankungen aus). So hat man - eine
Internetverbindung vorrausgesetzt - ständig eine genaue Zeit.
Genau heißt hier, auf einen Sekundenbruchteil genau; beispielsweise
auf eine Millisekunde genau. Das ist beachtenswert, denn die
Antwortzeiten der Server betragen oft mehr als das hundertfache
(also eine zehntel Sekunde).
Der Daemon sollte als ntpd oder als xntpd Paket in jeder
Distribution zu finden sein.
Dieser Text erklärt nicht ausführlich, wie man das ntpd Paket
installiert, da es in den großen Distributionen verfügbar ist und
hier auf die gleiche Weise wie andere Softwarepakete einfach
installiert werden kann. Meistens wird es soagr bereits
installiert sein, da man diesen Basisdienst auf fast allen Server
einsetzt. Man verwendet den Paketmanager oder das
Distributionsspezifische Installationswerkzeug, um das Paket
gegebenenfalls zu installieren.
Natürlich ist es auch möglich, den Quellcode downzuladen und
selbst zu kompilieren. Diese Prozedur basiert auf GNU autoconf
und ist daher sehr ähnlich zu anderen Softwarepaketen, die GNU
autoconf verwenden.
|
Eine einfache Konfigurationsdatei ist schnell erstellt. Im
westentlichen werden ein paar Server eingetragen und der Zugriff
darauf etwas beschränkt.
Datei /etc/ntp.conf
|
#lokale Uhr
server 127.127.1.0
#stratum 10 bedeutet "schlechte Qualität"
fudge 127.127.1.0 stratum 10
#Nun ein paar Server, die zur Synchronisation verwendet werden
# können. Bitte nicht unbedingt diese verwenden, sondern andere
# aus http://www.eecis.udel.edu/~mills/ntp/ auswählen.
# Stratum 2 Server sind mehr als ausreichend.
server ntps1-0.cs.tu-berlin.de prefer
server clock.isc.org
server ptbtime1.ptb.de
server ptbtime2.ptb.de
#Hat man mehrere NTP Server im LAN, sollte man diese als peer
# konfigurieren:
#peer ntps2-0.bedi.net # local time peer server
#Die ermittelte Laufzeitabweichung des Systems hier speichern:
driftfile /etc/ntp.drift
#Andere Server oder Clients dürfen die Zeit nur abfragen
restrict default notrust nomodify
#localhost darf alles (siehe "ntpdc")
restrict 127.0.0.1
#Normalerweise vertrauen wir dem Partnerserver im LAN auch:
#restrict ntps2-0.bedi.net
|
|
Vor dem Starten sollte man ntpdate ausführen, um eine korrekte
Ausgangszeit zu haben. Weicht die Zeit beim Start von ntpd stark
ab, so wird die Zeit vom ntpd nicht automatisch korrigiert, da es
sich möglicherweise um Fehler handelt, die manuell korrgiert
werden sollten.
Man könnte den xntpd einfach von der Kommandozeile starten, aber
dass kann die verwendete Distribution auch automatisch beim Start
über die sogenannten rc-Skripte. Bei SuSE-Distributionen kann man
beispielsweise über das Konfigurationswerkzeug den Dienst
aktivieren lassen und auch per Hand starten:
root@linux ~#
/etc/rc.d/xntpd start
|
Bei anderen Distributionen kann der Name geringfügig abweichen
und beispielsweise ntpd oder ntp lauten.
|
Hat man viele Server im LAN, so muss man natürlich nicht mit
jedem Server die Zeit aus dem Internet heraus synchronisieren.
Man kann auch Stratum 2 Server verwenden, um zwei (oder mehrere)
interne Stratum 3 Server zu betreiben. Diese sollten
untereinander als peer konfiguriert sein, um bei Internetausfall
höhere Genauigkeit zu bieten.
Die anderen lokalen Server können die Uhrzeit dann von den
eigenen Stratum 3 Servern beziehen. Dieses Verfahren ermöglicht
immernoch Zeiten auf hunderstel Sekunde genau, was meistens
ausreichend sein sollte. Man kann die lokalen Server auch alle
untereinander als peer konfigurieren, beziehungsweise die mit
ausreichend genauen Uhren (manche PCs haben sehr ungenaue
Systemuhren). Dies ist jedoch ein grosser Aufwand, der nicht
unbedingt durch Nutzen überwogen wird.
|
|