Frage Wie richte ich einen lokalen NTP-Server ohne Internetzugang auf Ubuntu ein?


Ich habe mehrere Anleitungen versucht, wie man einen lokalen NTP-Server auf Ubuntu einrichtet, aber keiner scheint richtig zu funktionieren. Meine Server sind aus irgendeinem Grund sehr zeitaufwendig und ich muss ihre Zeit eng beieinander verbringen, da ich Datenbanken betreibe, die dies erfordern.

  • Ich habe 8 Ubuntu 14.04 LTS Server, keiner von ihnen hat Internetzugang
  • Ich möchte einen NTP-Server auf einem (oder mehr, wenn das besser ist) der Server ausführen und alle anderen Server mit dem NTP-Server verbinden, um die Zeit einzustellen

Momentan führt mein Server (ip .24) diese /etc/ntp.conf aus:

server 127.127.1.0 prefer
fudge  127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

# Give localhost full access rights
restrict 127.0.0.1

# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap

broadcast 192.168.178.0

Und auf den "Kunden":

# Point to our network's master time server
server 192.168.178.24 iburst
fudge 192.168.178.24  stratum 10

restrict default ignore
restrict ::1
restrict 127.0.0.1
restrict 192.168.178.24 mask 255.255.255.255 nomodify notrap noquery

driftfile /var/lib/ntp/drift

minpoll 4
maxpoll 5

Hinweis: Ich habe Multi-Tabbed Putty verwendet, um die folgenden Befehle gleichzeitig an alle NTP-Clients zu senden. Ich habe die ntp-Dienste für alle außer dem Server gestoppt, benutzt sudo ntpdate 192.168.178.24 damit sie das Datum abrufen und die ntp-Dienste anschließend neu starten. Das ist gelungen. Alle Server zeigten dasselbe Datum, nachdem der Befehl beendet wurde. Nach ungefähr 10 Minuten zeigen meine Server die folgende Zeit:

Fr 30. Sep 11:16:53 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016 (server .24) 
Fr 30. Sep 11:16:50 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:17:05 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016

Wie werden sie korrekt mit dem NTP-Server synchronisiert? Und wie kann ich die Polling-Zeit senken? Es sieht so aus, als ob meine Server schnell nicht mehr synchron laufen, also brauche ich sie, um die "richtige" Zeit wieder zu bekommen ...

Mit "korrekter" Zeit meine ich eine Zeit, die für alle Server gleich ist. Es muss nicht unbedingt die exakt richtige Weltzeit sein (wenn Sie es so nennen).


Bearbeiten: Ich habe die vorgeschlagene Konfigurationseinstellung versucht. So weit ich verstanden habe, sollte meine Server / Client-Konfiguration so aussehen. In der Zwischenzeit habe ich gesehen, dass mein .24-Server tatsächlich zu einer schlechteren Zeit driftet. Der .20-Server ist der genaueste und ich verwende den .20-Server jetzt als Host für den ntp-Server. Entschuldigung für die Verwirrung.

Serverkonfiguration:

# Use the local clock
server 127.127.1.0 prefer
fudge  127.127.1.0
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

# Give localhost full access rights
restrict default

# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap

broadcast 192.168.178.0

Für die Kunden:

# Point to our network's master time server
server 192.168.178.20 iburst

restrict default

driftfile /var/lib/ntp/drift

minpoll 4
maxpoll 5

ntpq -as und ntpq -pe auf dem Server:

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 41906  963a   yes   yes  none  sys.peer    sys_peer  3
  2 41907  8811   yes  none  none    reject    mobilize  1

ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.           5 l   60   64  377    0.000    0.000   0.000
 192.168.178.0   .BCST.          16 u    -   64    0    0.000    0.000   0.000

Fünfmal ähnliche Ausgabe wie diese (diese Server driften in der Zeit):

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 62104  9024   yes   yes  none    reject   reachable  2


ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 hadoop20.xx LOCAL(0)         6 u   27   64  377    0.151  63591.8 33407.0

Für zwei (am wahrscheinlichsten?) Funktionierende Kunden:

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1  7757  963a   yes   yes  none  sys.peer    sys_peer  3

ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*hadoop20.xx LOCAL(0)         6 u   18   64  377    0.183    7.883   3.015

Edit 2:

Ich habe benutzt sudo service ntp stop, sudo ntpdate 192.168.178.20, warte bis ntpdate fertig ist, sudo service ntp start auf allen Clients. Es gibt immer noch nur 2 nachfolgende Clients und 5 ablehnende Clients.

Die ablehnenden Clients zeigen diese Ausgabe an. Das delay + offset Werte sehen hoch aus, weil die fehlerhaften Clients in der Zeit abdriften. Vielleicht vertrauen sie dem Server nicht, die Zeit zu aktualisieren, weil die Verzögerung / der Versatz so hoch ist?

ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 20981  905a   yes   yes  none    reject    sys_peer  5

ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 hadoop20.xx LOCAL(0)         6 u   34   64    3    0.166  18665.9 16201.3

Ich habe es auch versucht https://askubuntu.com/a/256004 Antwort, es funktioniert für ca. 30 Sekunden, dann wechselt der Zustand wieder zu "ablehnen"! Gleiches für ntpdate -s 192.168.178.20. Es hängt wahrscheinlich mit den NTP-Clients zusammen, die die Zeit des Servers ablehnen. Gibt es eine Möglichkeit, sie zu zwingen, die Zeit zu ändern?


6
2017-09-30 09:26


Ursprung




Antworten:


Tu das nicht. Ernst. Tu es einfach nicht. Die Leute kommen immer wieder auf die Idee, dass NTP so konzipiert ist, dass es einem Haufen von Computern erlaubt, das zu haben gleich Zeit. Es ist nicht. Es wurde sorgfältig entworfen, um vielen Maschinen zu ermöglichen, dass sie so nah wie möglich an der Maschine sein können richtig Zeit, die nicht das Gleiche ist.

Wenn Sie Zugriff auf ein Fenster haben, können Sie ein halb-anständiger Stratum-1-Server für ungefähr £ 50, oder ein gutes für £ 100. Sie würden viel besser tun, um so etwas zu bauen, dann zeigen Sie die anderen Kunden darauf. Korrekte Zeitstempel sind viel besser als nur selbstkonsistente, nicht zuletzt für die Forensik.

Aber wenn Sie unbedingt tun müssen, was Sie tun, dann müssen Sie erkennen, dass Sie ntpd pervertieren, und das wird bedeuten Verstehen was tust du.

Auf dem Server

server 127.127.1.0 prefer
fudge  127.127.1.0 stratum 10

meint "Verwenden Sie die lokale undisziplinierte Uhr so, als wäre sie autoritativ", was du willst. Ich bin mir nicht sicher, warum du es zu Stratum 10 zwingst stratum 10und lassen Sie den Treiber seine Standardschicht von 0 liefern. Auf den Clients

server 192.168.178.24 iburst
fudge 192.168.178.24  stratum 10

macht überhaupt keinen Sinn. fudge 127.127.x.y ist reserviert, um die Verwendung verschiedener Arten von lokalen Takttreibern zu erzwingen. Es macht keinen Sinn, eine andere Adresse anzugeben. Lass fallen fudge Linie von den Clients, und zeigen Sie sie nur auf dem Server. Sie verwenden auch ein geschlossenes Netzwerk. Lassen Sie also alle Sicherheitsfunktionen fallen, bis das funktioniert:

restrict default

Wenn das immer noch nicht funktioniert, müssen wir die Ausgabe von sehen ntpq -c as und ntpq -c pe sowohl auf dem Server als auch auf einem sich schlecht verhaltenden Client nach mindestens zehn Minuten ununterbrochener Ausführung.

Bearbeiten: Sie schreiben in einem Kommentar unten, dass "Ich denke, der Offset / Jitter ist sehr hoch, weil die Clients ausfallen Drift in der Zeit".

Ich denke du magst Recht haben. Das Blog dieses Jungen schlägt vor, er hatte die gleiche Erfahrung: dass die Client-Uhr so ​​schlecht war, dass es die Einheimischen täuschte ntpd zu denken, dass der Server unzuverlässig war. Er schrieb

Der Grund für den großen Jitter scheint endlich klar! Unsere Uhr driftet   so schnell, dass der Offset durch unsere wenigen um einige Sekunden steigt   Messungen

Angesichts der Tatsache, dass es sich um Ihre Kunden handelt, deren Zeit am schnellsten geht und die nicht synchronisiert werden können (indem Sie den Server als "ablehnen" markieren), haben Sie den gleichen Effekt. Seine Lösung war zu verwenden adjtimex Manuelles Einstellen der Kernel - Uhr (Anpassung der tick Wert), bis die Systemuhr weniger unberechenbar war, zu diesem Zeitpunkt konnte ntpd den Server als OK erkennen und mit ihm synchronisieren. Sie sollten wahrscheinlich versuchen, den schlechtesten Client zuerst zu versuchen, und sehen, ob es hilft.


7
2017-09-30 10:41



Ich habe meine ursprüngliche Frage bearbeitet. Es sieht so aus, als könnten zwei Clients sich jetzt mit dem Server verbinden, aber 5 konnten nicht. Zumindest kann ich das an der Ausgabe von ntpq -c as und ntpq -c pe - j9dy
Sieht so aus, als wäre es kein Firewall-Problem, da selbst die abweisenden Clients sehen können, dass der Server bei stratum 6 ist ntpd syslog etwas nützliches auf einem abweisenden Client, damit wir uns ein Bild davon machen können, warum sie es sind rejectden Server? Auch, wenn du das tust ntpdate zuerst? Plus, das cnt=2 über die Ablehnung der obigen Ausgabe ist beunruhigend; Du hast zehn Minuten auf Nachfrage gewartet, ja? - MadHatter
Ich habe gerade die Befehle wieder benutzt - ich denke es waren 10 Minuten schon das letzte Mal aber jetzt ist es sicher. Für die fehlerhaften Server, die cnt=2 bleibt, es hat sich nicht geändert. Ich habe inzwischen nicht neu gestartet. Ich werde jetzt alle Client-NTP-Dienste stoppen, verwenden ntpdate 192.168.178.20 auf den Clients und dann den NTP-Dienst auf den Clients neu starten. cat /var/log/syslog | grep ntp hat für die letzte Stunde auf den fehlerhaften Clients keine Ausgabe ausgegeben. Irgendeine Idee? was ist mit minpollund maxpoll in der Client-Konfiguration? - j9dy
Ich habe der ursprünglichen Frage mehr Output hinzugefügt. Ich denke, der Offset / Jitter ist wirklich hoch, weil die versagenden Clients mit der Zeit driften. Vielleicht vertrauen sie der Zeit des Servers nicht? - j9dy
Mein Gefühl ist, dass du wirklich musst ntpd auf dem Client, um Ihnen zu sagen, was vor sich geht. Sie müssen Ihre (r) Syslog-Konfiguration überprüfen, herausfinden, wo NTPD protokolliert und warum (auf meinem System (CentOS6) verwendet es Anlage daemon und Schweregrade 5, 6 und 7). Siehe auch meine Bearbeitung oben. - MadHatter