|
Betreibt man ntp Server, so sollte man diese hin und wieder
kontrollieren. Weicht die Zeit einmal erheblich ab, so stellt der
ntpd die Zeit beispielsweise nicht mehr automatisch nach.
|
Zur Überwachung gibt es das Werkzeug ntpdc. Dieses baut eine
Verbindung zum Server auf und kann über Kommandos Einstellungen
und Statusanzeigen abfragen und setzen. Daher sollte auch die
restrict Option im Server gesetzt werden, um zu verhindern, daß
jeder Optionen ändern kann.
ntpdc verbindet per Voreinstellung zu localhost. Möchte man zu
einem anderen Server, so gibt man dessen Name einfach auf der
Kommandozeile an.
Nach dem Start befindet sich das Werkzeug im interaktiven Modus,
was durch ein Prompt angezeigt wird, und erwartet ein Kommando.
Eine Hilfe gibt es mit dem Kommando help.
|
|
Ein Überblick gibt eine Tabelle, in der die verwendeten Server
und Informationen darüber angezeigt werden. Diese Tabelle kann
man sich mit dem Kommando peers anzeigen lassen:
ntpdc> peers
remote local st poll reach delay offset disp
=======================================================================
*ntp1.ptb.de 193.178.163.162 1 1024 377 0.03285 -0.001386 0.01483
=LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.00093
=hora.cs.tu-berl 193.178.163.162 2 1024 377 0.03644 -0.001299 0.01486
+secu.bedi.net 193.178.163.162 2 1024 376 0.11745 -0.003707 0.02843
=ntp2.ptb.de 193.178.163.162 1 1024 377 0.03380 -0.001047 0.01485
=clock.isc.org 193.178.163.162 2 1024 377 0.21767 -0.012278 0.01485
=ntp-nasa.arc.na 5.0.0.0 16 1024 0 0.00000 0.000000 0.00000
=ntp0-rz.rrze.un 5.0.0.0 16 1024 0 0.00000 0.000000
0.00000
|
Hier erkennt man, dass mit fünf Servern die Zeit synchron läuft.
Zusätzlich werden Informationen über die lokale Systemuhr (LOCAL)
angezeigt. Die unteren beiden Einträge stammen von Servern, die
vermutlich nicht erreichbar sind und deuten auf eine ungünstige
Konfiguration hin (beispielsweise eine Firewall, die diese Pakete
abweist).
Die Spalte offset gibt an, wie synchron die Uhren laufen. Die
Spalte disp gibt die Dispersion, also Streuung, der Zeitwerte
an. Eine Dispersion größer als 1 deutet auf grobe Fehler hin, ist
diese jedoch kleiner als 0.1, sind die Werte in Ordnung.
Beim Start des Servers ist die Dispersion zunächst sehr groß und
pegelt sich im Laufe der Zeit auf einen kleineren Wert ein. Dies
kann jedoch etliche Minuten dauern!
|
|
Im Beispiel sah man, das der Server clock.isc.org gute, der
Server ntp.nasa.gov (ntp-nasa.arc.nasa.gov) jedoch keine
sinnvollen Werte übermittelt. Das Kommando pstats gibt nähere
Informationen. Zunächst für den ersten Server:
ntpdc> pstats clock.isc.org
remote host: clock.isc.org
local interface: 62.154.193.196
time last received: 778s
time until next send: 247s
reachability change: 3079649s
packets sent: 19408
packets received: 18658
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 11395
bad reference time: 0
candidate order: 3
|
Man sieht, das vor 778 Sekunden Daten empfangen wurden und in 247
Sekunden das nächste Mal ein Datenaustausch stattfinden soll. Der
Server ist seit 35 Tagen (3079649 Sekunden) ununterbrochen
erreichbar gewesen.
ntpdc> pstats ntp.nasa.gov
remote host: ntp-nasa.arc.nasa.gov
local interface: 7.0.0.0
time last received: 3209635s
time until next send: 10s
reachability change: 3209635s
packets sent: 3150
packets received: 0
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 0
bad reference time: 0
candidate order: 0
|
Man erkennt, dass der Server seit 37 Tagen (3209635 Sekunden)
nicht erreichbar ist. Möglicherweise ist dieser Server nicht mehr
frei verfügbar.
|
|
Für globale Serverinformationen gibt es die Kommandos sysinfo und
sysstats. sysinfo gibt den aktuellen Serverstatus aus:
ntpdc> sysinfo
system peer: ntp1.ptb.de
system peer mode: client
leap indicator: 00
stratum: 2
precision: -17
root distance: 0.07309 s
root dispersion: 0.01715 s
reference ID: [192.53.103.103]
reference time: c243ecfe.50fd08d4 Sun, Apr 13 2003
16:04:46.316
system flags: auth monitor ntp kernel stats kernel_sync
jitter: 0.001297 s
stability: 0.003 ppm
broadcastdelay: 0.003998 s
authdelay: 0.000000 s
|
Man erkennt, welcher Server momentan zur Synchronisation
verwendet wird (hier ntp1.ptb.de), und das im Clientmode
gearbeitet wird. Hat man mehrere NTP Server im LAN, die
untereinander auch peer sind, arbeitet ein System bei
Internetzugangsproblemen im peer Modus. Der Beispielserver
befindet sich aber im Clientmodus, so dass die Internetverbindung
offensichtlich funktioniert.
Die Ausgaben von systats:
ntpdc> sysstats
system uptime: 19681383
time since reset: 19681383
bad stratum in packet: 0
old version packets: 21927
new version packets: 525853
unknown version number: 0
bad packet length: 0
packets processed: 114444
bad authentication: 0
limitation rejects: 0
|
zeigen beispielsweise, wie lange (in Sekunden) das System schon
läuft (hier also 19.681.383 Sekunden, das entspricht ca. 227
Tagen) und das 114.444 Pakete bearbeitet wurden.
|
|
Es bietet sich an, den Dienst automatisch überwachen zu lassen:
so kann man es nicht vergessen und wird informiert, sobald ein
Fehler auftritt.
Man kann das netsaint Paket verwenden, dass man über
 http://www.netsaint.org downloaden kann. Netsaint hat neben vielen
anderen Tests auch ein check_ntp, welches NTP Server über das
Netzwerk kontrolliert. Antwortet ein Server nicht, oder hat seine
Uhrzeit schlechte Qualität, kann ein Information verschickt
werden. Der Administrator bekommt dann eine eMail mit einer
entsprechenden Fehlermeldung. Über ein Webfrontend kann er sich
Details anschauen, beispielsweise die Verfügbarkeit des Dienstes
als Diagramm.
|
|
SelfLinux 
