Howto zu: NTP-Server einrichten

Beschreibung:
Dieses HowTo beschäftigt sich mit der Installation, der Konfiguration und dem Betrieb eines Zeitservers.
Alle Angaben beziehen sich auf den offiziellen NTP Daemon wie er vom ISC empfohlen wird.
Die Bezugsdistribution auf die sich alle hier gelisteten Befehle und Pfade beziehen, ist Debian "Sarge" 3.1. Wenn andere Distributionen Verwendung finden, können Befehle, Dateien und Pfade anders sein.

Installation

Der Server mit allen benötigten Tools und startscripten wird unter Debian mit dem Befehl apt-get installiert. Das Paket heißt ntp-server und demzufolge wird der NTP-Server mit folgendem Befehl installiert:
Code:
apt-get install ntp-server
Nachdem die Installation erfolgreich abgeschlossen wurde befindet sich die Konfigurationsdatei ntp.conf in /etc/ und das Startscript um den Server direkt beim Booten zu laden heißt /etc/init.d/ntp-server.
Auf den meisten Debian-Distributionen ist ntpdate bereits standardmäßig installiert. Es kann weiterhin auf dem System verbleiben. Der Server und ntpdate kommen sich nicht in die Quere. Außerdem kann man ntpdate später nutzen um den Server auf einfachste Weise zu testen.


Grundlegendes Wissen und grundlegende Informationen über NTP

Die Abkürzung NTP steht für Network Time Protocol und ist in RFC 1305 definiert.
Die Implementation des NTP-Protokolls wird vom ISC - Internet Systems Consortium verwaltet und durch das NTP R&D Project umgesetzt.
Die Zeit die durch NTP verbreitet wird, wird Sekundengenau in UTC weitergegeben. Es gibt auch Implementationen die die Zeit genauer, bis zu wenigen 100stel Sekunden, verbreiten, aber in den meisten Netzwerken ist eine genauere Zeit nicht notwendig und daher werden wir uns in diesem HowTo nicht damit auseinandersetzen.
Je nachdem wie dicht ein NTP-Server an der Atomuhr steht, umso niedriger ist sein sogenanntes Stratum. Es gibt insgesamt 15 Level. Stratum 1 ist das höchste Level. Ein NTP-Server, der Stratum 1 hat, holt seine Zeit direkt von der Atomuhr, die Stratum 0 hat. Die meisten Server im Internet bieten ein Level von Stratum 1 bis Stratum 4 an, was an Genauigkeit bei den meisten Anwendungen durchaus ausreichend ist.
Ein NTP-Server versucht grundsätzlich sich mit dem Server des höchsten verfügbaren Stratums zu synchronisieren. Wenn man also drei Server angibt und die Server Stratum 2, Stratum 3 und Stratum 4 haben, dann synchronisiert sich der lokale NTP-Server zuerst mit dem Server dessen Zeit am dichtesten an der eigenen Zeit ist und schaukelt die lokale Zeit dann langsam bis an die Zeit des Servers mit Stratum 2 heran. Das wird extrem langsam vollzogen und kann sich, je nach Abweichung der lokalen Uhr von der des Zeitservers, auch über mehrere Stunden hinziehen. Das wird gemacht um zeitabhängige Dienste wie cron oder at nicht durch einen plötzlichen Zeitsprung aus dem Tritt zu bringen.
Damit die Synchronisation sich eben nicht über Stunden hinzieht, sollte man vor dem Start des Zeitdienstes die lokale Zeit mit ntpdate möglichst genau einstellen.
Wenn sich der Server mit einem Zeitserver im Internet oder einem anderen Netzwerk synchronisert hat, gibt er sein eigenes Stratum immer um -1 vom Stratum des Servers an, mit dem sich der Server synchronisiert hat. Hat z.B. der Zeitserver im Internet mit man sich synchronisert hat, ein Stratum von 3, dann gibt der eigene NTP-Server sein Stratum mit 4 an.


Konfiguration

Die Konfiguration des Servers erfolgt in der Datei /etc/ntp.conf.
Es handelt sich um eine einfache Textdatei, die mit einem Texteditor wie beispielsweise vim oder nano editiert werden kann.
In dieser Datei wird eingestellt zu welchen Servern sich der Daemon verbinden soll um die lokale Zeit mit der offiziellen Zeit abzugleichen. Hier wird auch angegben welche Rechner welche Rechte haben. Zum Beispiel das Ändern der Uhrzeit oder der Zugriff auf den Daemon schlechthin.
Außerdem wird in dieser Datei angegeben wo die Log-Daten hingeschrieben werden sollen, wenn sie woanders landen sollen als in messages oder syslog, was ja durchaus erwünscht sein kann.
Ok. Soweit so gut. Kommen wir also zu den einzelnen Konfigurationsoptionen.

Die wahrscheinlich wichtigste Option ist die Option server.
Mit dieser Option gibt man an mit welchem Server sich unser Daemon verbinden soll um sich die aktuelle Zeit zu holen.
Da die Zeit des NTP-Protokolls bekannterweise in UTC verbreitet wird, ist es von der Sache her egal wo der Zeitserver, mit sich unser NTP-Daemon synchroniseren soll, steht. Aber es gibt eine Regel im Internet und die besagt, man solle sich idealerweise mit dem Server verbinden, der am dichtesten an seinem jetzigen lokalen Standort ist. Das hat schon seinen Grund, denn wenn das Paket über hunderte von Routern um die halbe Welt geht, ist das Paket im günstigsten Fall einige hunderstel Sekunden unterwegs, es kann aber durchaus auch ein bis zwei Sekunden unterwegs sein. Und da man die Zeit möglichst genau haben möchte, zumindest aber sekundengenau, sollte man einen Server nehmen wo die Daten wahrscheinlich nur ein paar zehntel Sekunden unterwegs sind - Also den Server der einem am nähesten ist.
In unserem Fall wären das Server aus Deutschland. Das NTP-Projekt bietet einen sogenannten Server-Pool an. Das heißt, dass in diesem Pool ein Haufen Server konzentriert sind und wenn man die Adresse des Pools aufruft bekommt man die IP des Servers, der aktuell die beste Erreichbarkeit liefert. Das NTP-Projekt bietet mehrere solcher Pools an. Einmal natürlich einen weltweiten Pool und einmal auch einen eher lokalen. Der deutsche Pool hat die Adresse de.pool.ntp.org.
Da man sich aber besser mit mehr als einem NTP-Server im Internet verbindet, falls der eine mal plötzlich nicht mehr erreichbar ist, sollte man sich auch mit dem internationalen Pool verbinden. Dieser hat die Adresse pool.ntp.org.
Ok. Die Frage mit dem Server ist weitestgehend geklärt und wir schreiben folgende Zeile in die Konfigurationsdatei:
Code:
server de.pool.ntp.org
server pool.ntp.org
Nun ist es leider auch so, dass man sich auf die Provider nicht immer hundertprozentig verlassen kann. Und so kann es vorkommen, dass die Verbindung zum Internet wegbricht und auch nicht wieder aufgebaut werden kann. Der Daemon reagiert nun folgendermaßen: Da er keinen NTP-Server hat mit dem er sich synchronisiern kann, er aber auch keine Zeit herausgeben will, die eventuell falsch ist, setzt er sein Stratum auf den Wert 16.
Wie wir wissen gibt es 16 Level, beginnend bei 0 und endet bei 15. Der Wert Stratum 16 ist also ein ungültiger Wert und NTP-Clienten akzeptieren eine Zeit von einem Stratum 16-Server nicht.
Nun ist es jedoch nicht so, dass der Computer gar keine Zeit mehr hat. Schon allein um das System stabil zu halten MUSS ja irgendwie eine ziemlich genaue Taktung der Signale erfolgen und jeder weiss, dass der Computer eine recht genaue interne Uhr hat. Diese Uhr ist genau genug, dass sie innerhalb eines Monates nur wenige Sekunden falsch geht und oftmals geht sie sogar über Jahre recht genau. Warum also nicht die interne Systemuhr zum Synchronisieren nutzen, wenn mal keine Verbindung zu Zeitservern im Internet besteht?
Genau das haben sich auch die NTP-Entwickler gedacht und haben Module entwickelt mit denen es möglich ist andere Zeitsignale zur Synchronisation zu nutzen als die der Internetzeitserver. Eines dieser Module nutzt die interne Systemuhr als Zeitgeber.
Da der NTP-Daemon IMMER einen Server benötigt mit dem er sich synchroniseren kann, muss das Modul also vorgeben selber ein Zeitserver zu sein. Und das tut es auch. Die Zeile zur Synchronisation mit der Systemuhr beginnt also ebenfalls mit dem Schlüsselwort server. Damit der Daemon jedoch grundsätzlich versucht sich mit einem (meist genaueren) Zeitserver im Internet zu synchronisieren, gibt es auch die Möglichkeit dem Daemon mitzuteilen wie er den angeblichen Zeitserver Systemuhr betrachten soll, sprich welches Stratum die Systemuhr haben soll.
Um also als Ausweichserver die Systemuhr zu verwenden, sollte man zwei Zeilen eingeben (obwohl eine vom Prinzip her genügen würde). Das Stratum für die Systemuhr sollte man recht hoch ansetzen. Und zwar irgendwo zwischen 8 und 12. Bedenke dabei, dass der NTP-Server sein eigenes Stratum noch um 1 vermindert!
Die Zeilen für die Systemuhr als Ausweichziel lauten also:
Code:
server 127.127.1.1
fudge 127.127.1.1 stratum 8
Die IP 127.127.1.1 zeigt auf den lokalen Host und in diesem speziellen Fall auf das Modul, welches die Systemuhr repräsentiert. Bei Debian ist dieses Modul bereits fertig mit im Paket enthalten. Es muss also nicht nochmal mit Unterstützung für dieses Modul neu übersetzt werden. Bei den meisten anderen Distributionen wird das wohl ebenfalls der Fall sein.
Mit der Zeile fudge 127.127.1.1 stratum 8 sagen wir dem Daemon, dass er den Server mit der IP 127.127.1.1 als einen Stratum 8-Server betrachten soll, was er dann auch tut. Der lokale NTP-Server meldet sich, wenn er sich mit der Systemuhr synchronisiert hat, als ein Stratum 9-Server.
In der ntp.conf steht jetzt:
Code:
server de.pool.ntp.org
server pool.ntp.org
server 127.127.1.1
fudge 127.127.1.1 stratum 8
Mit diesen Angaben alleine könnte man den Server bereits starten und er würde sämtlichen Clienten die ihn fragen auch seine Zeit anbieten. Und er würde sich auch bereits mit insgesamt drei Servern synchronisieren.

Allerdings würde der Server auch von allen Rechnern die Zeit annehmen, die vorgeben ein NTP-Server zu sein und ein niedrigeres Stratum angeben als der aktuelle zeitsignalgebende Server hat.
Darum haben die Entwickler sich einen Mechanismus ausgedacht mit dem der NTP-Daemon selber entscheiden kann ob der Rechner das darf oder nicht. Es existiert also eine Art einfache Rechteverwaltung. Diese Rechteverwaltung wird mit der Option restrict aktiviert. Mit restrict wird dem Daemon mitgeteilt was einzelne Rechner dürfen und was nicht. Es ist z.B. nicht sinnvoll, wenn Rechner aus dem Netz das man mit der aktuellen Zeit versorgen will, auf dem Zeitserver die Zeit ändern dürfen. Sollten sie das versuchen und auch dürfen, dann haben zwar immer noch alle Rechner im Netzwerk die gleiche Zeit, aber die gleiche, falsche Zeit....
Darum sollten Rechner aus dem zu versorgenden Netzwerk lediglich "Leserechte" auf dem Server haben.
Andererseits ist es so, dass die Zeitserver aus dem Internet mit denen man sich synchronisieren will, durchaus auch "Schreibrechte" auf dem Server haben müssen. Denn sie sollen dem Server ja die aktuelle Zeit geben und der Server muss gegebenenfalls die Möglichkeit haben die Systemzeit mit der Zeit der Zeitserver abzugleichen, also im übertragenen Sinne "schreiben" dürfen.
Werden keine Restrictions gesetzt, dürfen alle Rechner alles auf dem Server. Wie bereits erwähnt ist das nur in Teilen erwünscht, aber bei den meisten Rechnern ist das unerwünscht.
Man sollte also wenigstens folgende Werte setzen (das hab ich so aus der Dokumentation erarbeitet):
Code:
restrict de.pool.ntp.org
restrict pool.ntp.org
restrict 127.127.1.1
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 nomodify
restrict default kod notrap nomodify nopeer noquery
Die Rechner von de.pool.ntp.org, pool.ntp.org, die interne Systemuhr und der Host selber dürfen also auf dem Server alles. Das Netzwerk für das der Server die aktuelle Uhrzeit bereitstellen soll ist das Netzwerk 192.168.0.0/24 und Rechner aus diesem Netzwerk dürfen alles außer die Uhrzeit auf dem Server manipulieren. Das besagt der Parameter nomodify.
Alle anderen Rechner dürfen auf dem Server gar nichts. Nicht einmal eine Anfrage wird beantwortet werden.

Nicht auf allen Systemen ist es erwünscht, dass der NTP-Server alle Aktionen ins syslog schreibt, was er in der Standardeinstellung jedoch tut. Darum gibt es die Möglichkeit dem Daemon mitzuteilen, dass er seine Log-Ausgaben in eine andere Datei schreiben soll. Das tut die Option logfile.
Außerdem kann man den Ort der sogenannten Driftdatei ändern. In der Driftdatei steht drin wie gross die Abweichung im Mittel ist. Anhand dieses Driftfiles orientiert sich der Daemon beim Start welche Abweichungen der lokalen Systemzeit zur Zeit im Internet zu erwarten sein könnten. Den Ort der Driftdatei ändert man mit der Option driftfile.
Außerdem führt der Daemon eine Art Statistik. Ich weiß zwar nicht genau was der Daemon da jetzt so ablegt, aber das Statistik-Vrezeichnis wird in jedem Fall angelegt und befindet sich standardmäßig in /var/log/ntpstats/. Es kann mit statsdir geändert werden.
Ich persönlich habe Daten von einem Dienst immer schön in einem Verzeichnis. Und so halte ich es auch mit den Daemons, wenn es möglich ist. Daher habe ich den Daemon angewiesen seine Daten im Verzeichnis /var/log/ntp/ abzulegen (Das Verzeichnis /var/log/ntp/ muss auf den meisten System wahrscheinlich erst erstellt werden.). Es werden also noch folgende Zeilen in die Konfigurationsdatei hinzugefügt:
Code:
logfile /var/log/ntp/ntpd
driftfile /var/log/ntp/driftfile
statsdir /var/log/ntp/stats/
Neben den Restrictions bietet das NTP-System noch eine weitere Sicherheitsmaßnahme. Man kann sogenannte Schlüssel verteilen. Das heißt, dass man auf dem Server einen Key erstellt und diesen Key auf jeden Client-Rechner kopiert. Das Ergebnis ist, dass nur noch Rechner mit gültigem Key auf den Server dürfen und sich von dort ihre Zeit holen dürfen.
Meiner Meinung nach ist das in den meisten Fällen überflüssig, ja sogar unerwünscht, da dadurch das ohnehin komplizierte System noch weiter verkompliziert wird. Denn man muss jedem Rechner, der neu in das Netzwerk kommt nicht nur mitteilen wo sich der NTP-Server befindet, man muss ihm auch noch den Key übermitteln, damit de Zeitserver ihn überhaupt akzeptiert.
Um auf Nummer sicher zu gehen, schalte ich die Authentifizierung explizit ab. Dies erfolgt mit der Option disable auth.
Wer die Authentifizierung jedoch haben möchte, der kann sich in der Dokumentation des Projektes (nur html-Seiten) diesbezüglich belesen.

Die Konfigurationsdatei sieht nun folgendermaßen aus (jetzt sind sowohl Kommentare enthalten und die Log-Einstellungen sind ganz am Anfang des Files):
Code:
# /etc/ntp.conf, configuration for ntpd

# ntpd will use syslog() if logfile is not defined
logfile /var/log/ntp/ntpd
driftfile /var/log/ntp/drift
statsdir /var/log/ntp/stats/


# you need one or more servers
server de.pool.ntp.org
server pool.ntp.org

# ... and use the local system clock as a reference if all else fails
# NOTE: in a local network, set the local stratum of *one* stable server
# to 10; otherwise your clocks will drift apart if you lose connectivity.
server 127.127.1.1
fudge 127.127.1.1 stratum 8

# set restrictions
restrict de.pool.ntp.org
restrict pool.ntp.org
restrict 127.127.1.1
restrict 127.0.0.1 
restrict 192.168.0.0 mask 255.255.255.0 nomodify
restrict default kod notrap nomodify nopeer noquery

# disables critical procedure of athentication
disable auth

#end

Dienst starten, neu starten und beenden

Der Dienst wird mit dem Befehl
Code:
/etc/init.d/ntp-server start
gestartet.
Beendet wird der Dienst wie üblich mit
Code:
/etc/init.d/ntp-server stop
Normalerweise soll der Dienst mit
Code:
/etc/init.d/ntp-server restart
neugestartet werden. Allerdings erfolgt bei meinem System der Neustart des Daemons grundsätzlich zu schnell auf das Beenden und der Daemon schoss sich grundsätzlich selbst mit folgender Meldung ins Aus:
Code:
parent died before finished
Daher ist es vielleicht ratsam ein kleines Script zu schreiben, welches den Neustart verzögert ausführt. Dieses Script könnte diese Form haben:
Code:
#!/bin/bash

/etc/init.d/ntp-server stop
sleep 10 
/etc/init.d/ntp-server start
Dadurch liegen 10 Sekunden zwischen dem Beenden und dem Neustart des Dienstes. Diese Zeitspanne reichte bei mir aus, damit der Dienst problemlos neustartete.


Fehlerbehebung

Das NTP-System wie es das ISC verteilt ist nicht ganz einfach zu handhaben und meiner Meinung nach recht anfällig für Probleme aller Art.
Das bei mir am häufigsten auftretende Problem hängt wahrscheinlich mit der bei den meisten Providern üblichen Zwangstrennung zusammen. Jedesmal nach der Neueinwahl konnte sich der Dienst nicht mehr mit den Servern im Internet synchronisieren und musste neu gestartet werden. Daher ist es bei mir sinnvoll geworden ein Script zu schreiben welches die DSL-Verbindung kappt und wieder herstellt und dabei auch den Daemon beendet und nach erfolgreicher "Wiedereinwahl" den Daemon wieder startet. Dieses Script sollte dann regelmäßig mit dem Cron-Daemn ausgeführt werden um dieses Problem zu vermeiden.
Folgender Logeintrag weißt auf ein solches Problem hin:
Code:
ntpd[8565]: sendto(62.72.66.166): Invalid argument
Es kann wie gesagt einfach behoben werden, indem man den Daemon neu startet.

Der NTP-Daemon selber benötigt eine ganze Weile bis er bereit ist um die aktuelle Zeit auszugeben. Während dieser Zeit gibt er an Stratum 16, also ein ungültiges Stratum, zu haben.
Im Log sieht das folgendermassen aus:
Code:
ntpd[9043]: kernel time sync disabled 0041
Ein erfolgreicher Start sieht in etwa so aus:
Code:
12 Jun 16:31:11 ntpd[9043]: frequency initialized 25.063 PPM from /var/log/ntp/drift
12 Jun 16:34:26 ntpd[9043]: synchronized to 62.101.81.203, stratum 2
12 Jun 16:34:28 ntpd[9043]: synchronized to 194.231.42.100, stratum 1
12 Jun 16:34:28 ntpd[9043]: kernel time sync disabled 0041
12 Jun 16:39:50 ntpd[9043]: kernel time sync enabled 0001
Sobald die Meldung kernel time sync enabled 0001 erscheint, kann die Zeit vom Dienst abgefragt werden. Wie aus dem Log zu ersehen ist, dauert es vom Start des Dienstes bis zur Bereitstellung der Zeitinformation durch den Dienst insgesamt 9 Minuten. Das ist in etwa die übliche Zeit, die der Daemon benötigt um zu starten.

Die grundsätzliche Funktionstüchtigkeit des Daemons kann man mit zwei Tools testen. Einmal mit ntpq und einmal auch mit ntpdate.
Das erstgenannte Tool ntpq ist nur auf Systemen verfügbar, wo der NTP-Dienst installiert ist. Es dient eigentlich dazu den Daemon im laufenden Betrieb zu manipulieren. Man kann es jedoch auch als Diagnose-Tool "missbrauchen".
Wenn man ntpq mit der Option -p aufruft und den eigenen Server auf localhost abfragt, dann gibt der Daemon aus mit welchen Servern er verbunden ist und mit welchem Server er sich aktuell synchronisiert. Ausserdem werden noch Informationen wie Abweichung der Internetzeit von der lokalen Zeit, Ping, Stratum und weitere Informationen angegeben. Eine typische Ausgabe sieht in etwa so aus:
Code:
# ntpq -p localhost
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*u19-100.dsl.via .GPS.            1 u  104  512  377   84.353   -2.096   0.337
+sciniext.scinic 193.204.114.232  2 u  491  512  377   53.699    0.934   0.777
 LOCAL(1)        LOCAL(1)         8 l   39   64  377    0.000    0.000   0.001
Das Tool ntpq kann NUR als privilegierter Benutzer aufgerufen und benutzt werden.
Die Beispielausgabe gibt folgendes an:
  • der Dienst ist mit drei Servern verbunden
  • der Server mit dem er sich synchronisiert hat ist der mit dem * davor
  • das Stratum eines jeden einzelnen Servers (st)
  • das sogenannte Pollution-Intervall (die Zeit die zwischen jeder Synchronisation liegt) (poll)
  • die Verzögerung, sprich der Ping zum Server (delay)
  • das Offset in Sekunden (die Abweichung der eigenen Zeit von der gelieferten Zeit) (offset)

Um von aussen zu testen ob der Dienst funktioniert und mit welchem Stratum er die Zeit ausliefert, kann man das Werkzeug ntpdate nutzen. Es ist das gleiche Werkzeug mit dem man später die Uhrzeit der Clienten mit dem Server abgleicht.
Um nur zu erfahren ob der Dienst läuft und Zeit ausgibt, ruft man ntpdate mit der Option -q (für query) und der Adresse des Servers auf. Man bekommt dann in etwa folgende Ausgabe:
Code:
$ /usr/sbin/ntpdate -q disastersmaster
server 192.168.0.1, stratum 2, offset 0.003466, delay 0.02579
12 Jun 19:37:48 ntpdate[23778]: adjust time server 192.168.0.1 offset 0.003466 sec
Wenn man lediglich die Funktionstüchtigkeit des NTP-Servers testen möchte, dann kann man ntpdate auch als unprivilegierter Benutzer aufrufen, muss dann jedoch kompletten Pfad zu ntpdate angeben, da es auf den meisten Systemen in einem */sbin-Verzeichnis liegt und diese Verzeichnisse bei den meisten Usern nicht in der PATH-Variable eingetragen sind.
Sollte ntpdate ein Stratum von 0 liefern, dann liegt das meist daran, dass der NTP-Server entweder nicht erreichbar ist oder nicht gestartet ist. Bei ersterem sollte man seine Firewall-Einstellungen überprüfen. Der Port 123/UDP wird für die Kommunikation verwendet und sollte deshalb offen sein.
Bei letzterem, also wenn der Dienst offline ist, sollte man den Dienst neu starten.
Wenn man mit ntpdate das Stratum 16 geliefert bekommt, dann ist der Server (noch) nicht bereit. Man sollte nach einer viertel bis halben Stunde noch einmal versuchen den Server zu kontaktieren. Sollte das Stratum dann immer noch bei 16 liegen, dann ist es ratsam sich auf dem Rechner einzuklinken und ins Log zu schauen ob alles in Ordnung ist. Meist ist das Log sehr auskunftsfreudig, wenn es Probleme gibt. Ein häufiger Grund kann sein, dass sich der Server nicht mit einem anderen NTP-Server synchronisieren konnte. Ein anderer Grund kann sein, dass die Abweichung zwischen Systemzeit und Zeit im Internet zu hoch ist und es zu lange dauern würde bis sich der Server mit einem anderen Server synchronisiert hat. Dann beendet sich der Server meist mit dem Hinweis, dass man die Zeit zuerst per Hand auf einen aktuellen Wert setzen soll und dann den Server erneut starten soll.
Die aktuelle Zeit kann man mit date setzen (Syntax unter Linux. Bei BSD kann sie anders sein.):
Code:
date -s 19:52:55
Damit setzt man die aktuelle Zeit auf 19:52:55. Alternativ dazu kann man die Zeit nat. auch mit ntpdate setzen lassen. Es ist daher grundsätzlich eine gute Idee ntpdate vor dem ntp-server zu starten und die Zeit zu synchronisieren.


Mit diesen Informationen ist es jetzt möglich alle Rechner in einem lokalen oder einem Firmennetzwerk zu synchronisieren. Dazu müssen lediglich alle im Netzwerk vorhandenen Rechner mit einem NTP-Clienten ausgestattet sein (bei Microsoft-Betriebssystemen haben ab Windows 2000 alle Versionen einen NTP-Clienten an Board; bei Linux muss ntpdate installiert werden, was meist jedoch standardmässig der Fall ist) und die Clienten aktiviert werden.
Man kann auch mehrere Server im Netzwerk haben, jedoch sollte nur einer den Hut auf haben und die Zeit an alle anderen weitergeben. Dabei tritt dann der Server "mit dem Hut auf" als Server auf und die anderen Server bei diesem Server als Client. Das ist kein Problem, denn so ist das ganze NTP-System aufgebaut. Ein Server ist meist auch gleichzeitig Client bei einem anderen Server.