NTP - Zeit sychronisieren

[Flynn]

Hallo liebe Leute,

ich habe ein Problemchen. Und zwar möchte ich die Zeit per NTP synchronisieren. So weit so gut. Mit den klassischen Mitteln ist das wunderbar möglich - allerdings laufen eMail-Dienste darauf und genau das macht die Sache kompiliziert.

Postfix und dovecot beenden sich falls die Zeit "ruckartig" umgestellt wird. Das bedeutet - will ich die Dienste nicht bei jedem Zeitupdate neu starten - dass die Zeit eben langsam gestellt werden muss. Der ntpd macht das, aber er öffnet ne Menge Ports - die sich eben nicht in der config schließen lassen. Jede IP + 0.0.0.0 (also global) wird nen Port geöffnet, IPv6 muss natürlich auch noch sein

udp 0 0 <ip>:123 0.0.0.0:* 0 458864 4726/ntpd
udp 0 0 <ip>:123 0.0.0.0:* 0 458863 4726/ntpd
udp 0 0 <ip>:123 0.0.0.0:* 0 458862 4726/ntpd
udp 0 0 <ip>:123 0.0.0.0:* 0 458861 4726/ntpd
udp 0 0 <ip>:123 0.0.0.0:* 0 458860 4726/ntpd
udp 0 0 <ip>:123 0.0.0.0:* 0 458859 4726/ntpd
udp 0 0 <ip>:123 0.0.0.0:* 0 458858 4726/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 0 458857 4726/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 0 458850 4726/ntpd
udp6 0 0 fe80::21d:92ff:fe63:123 :::* 0 458856 4726/ntpd
udp6 0 0 ::1:123 :::* 0 458855 4726/ntpd
udp6 0 0 :::123 :::* 0 458851 4726/ntpd

Kurz gesagt: ich finde die Software ermassen bekackt, dass ich gern eure Lösungen für die Zeitsync hören würde.

Wie bekomme ich eine sanfte Umstellung hin ohne das ich tausende offene Ports (die ich dann wieder per iptables schließen muss - ich will die Zeit nicht weiterverteilen) habe? Wie macht ihr das?

[mistersixt]

Der ntpd lauscht immer nur auf UDP Port 123, wenn Du ihn von aussen dicht machen willst, dann brauchst Du also nur diesen einen Port UDP 123 zu rejecten/droppen.

Gruss, mistersixt.

[roli]

Hi,

schau mal:

Der Daemon muss also für Kontinuität sorgen, ein lineares Hochzählen der Uhrzeit ohne Vorwärts- oder Rückwärts-Sprünge sicherstellen. Er korrigiert daher die Uhr meist in winzigen Schritten - genauer gesagt verkürzt oder verlängert er die Systemsekunden um eine halbe Millisekunde pro Sekunde, das entspricht 0,05 Prozent. Das tut es so lange, bis die Uhr wieder ordnungsgemäß läuft.

zu finden auf Seite 2 von Wer hat an der Uhr gedreht?

[Flynn]

Der ntpd lauscht immer nur auf UDP Port 123, wenn Du ihn von aussen dicht machen willst, dann brauchst Du also nur diesen einen Port UDP 123 zu rejecten/droppen.

Trotzdem ist und bleibt es sehr unschön so viele Sockets zu öffnen und einen Port sperren zu müssen. Diese Lösung fahre ich ja gerade, aber will ja eben nicht, dass es irgendwie geht, sondern es muss auch noch gut sein

Der Daemon muss also für Kontinuität sorgen, ein lineares Hochzählen der Uhrzeit ohne Vorwärts- oder Rückwärts-Sprünge sicherstellen. Er korrigiert daher die Uhr meist in winzigen Schritten - genauer gesagt verkürzt oder verlängert er die Systemsekunden um eine halbe Millisekunde pro Sekunde, das entspricht 0,05 Prozent. Das tut es so lange, bis die Uhr wieder ordnungsgemäß läuft.

Das weiß ich - genau darum läuft der ntpd ja gerade (habe das Problem früher ja oben geschildert). Aber du willst mir nicht erzählen, dass bei einer Sync pro Woche der ntpd so ewig laufen muss um die korrekte Uhrzeit nachzustellen.

Am Liebsten wäre mir eben eine alternative Lösung. Beispielsweise ein ntpd der sich nach getaner Arbeit beendet. Warum es ist wie es ist weiß ich - das war nicht meine Frage

[cosmac]

hi,

Der Daemon muss also für Kontinuität sorgen, ein lineares Hochzählen der Uhrzeit ohne Vorwärts- oder Rückwärts-Sprünge sicherstellen. Er korrigiert daher die Uhr meist in winzigen Schritten - genauer gesagt verkürzt oder verlängert er die Systemsekunden um eine halbe Millisekunde pro Sekunde, das entspricht 0,05 Prozent. Das tut es so lange, bis die Uhr wieder ordnungsgemäß läuft.

Das weiß ich - genau darum läuft der ntpd ja gerade (habe das Problem früher ja oben geschildert). Aber du willst mir nicht erzählen, dass bei einer Sync pro Woche der ntpd so ewig laufen muss um die korrekte Uhrzeit nachzustellen.

Was meinst du mit "einer Sync pro Woche"? Der ntpd holt sich regelmäßig die Zeit aus dem Netz (alle 64 bis 1024 Sekunden) und stellt die Kernel-Uhr kontinuierlich nach. Das muss er auch um z.B. die Temperaturunterschiede zwischen Tag und Nacht auszuregeln. Nur so erreicht man diese Genauigkeit. Das Verfahren ist auch um einiges kompliziert als in rolis Link beschrieben. Die o.g. "halbe Millisekunde pro Sekunde" ist nur der Maximalwert.

Am Liebsten wäre mir eben eine alternative Lösung. Beispielsweise ein ntpd der sich nach getaner Arbeit beendet.

dafür hat man bisher "ntpdate -B" verwendet, damit wird die Kernel-Uhr einmalig und langsam verstellt. Wenn man ntpdate z.B. einmal täglich per cron aufruft, wird der Fehler im Laufe des Tages immer grösser (z.B. bis 4 Sekunden) um dann in (z.B.) gut 2 Stunden wieder Null zu werden. Wenn man damit leben kann, braucht man keinen ntpd. Aber genaugenommen ist diese Arbeit nie beendet.

Neuerdings soll diese Funktionalität von ntpd übernommen werden, aber weil es ntpdate ja noch gibt hab' ich das noch nicht getestet.

Auch nicht getestet, gerade eben entdeckt, wird morgen hier installiert: ntpclient. Auf den ersten Blick ist das ein ntpd aus dem man den Server-Teil entfernt hat.

[mistersixt]

Der ntpd lauscht immer nur auf UDP Port 123, wenn Du ihn von aussen dicht machen willst, dann brauchst Du also nur diesen einen Port UDP 123 zu rejecten/droppen.

Trotzdem ist und bleibt es sehr unschön so viele Sockets zu öffnen und einen Port sperren zu müssen. Diese Lösung fahre ich ja gerade, aber will ja eben nicht, dass es irgendwie geht, sondern es muss auch noch gut sein

Was ist daran so schlimm, einen Port von aussen zu sperren? Andere Ports hast Du doch vermutlich auch gesperrt, oder nicht?
Und was sind das denn für IP-Adressen, die Du ganz oben mit <ip> versteckt hast? Sind das welche aus Deinem LAN?

Mach mal bitte ntp nicht so schlecht, das Tool ist Gold wert und funktioniert einwandfrei - wenn man weiss, wie man es bedienen muss.

Gruss, mistersixt.

[Flynn]

Was ist daran so schlimm, einen Port von aussen zu sperren? Andere Ports hast Du doch vermutlich auch gesperrt, oder nicht?

Wie gesagt, es funktioniert alles irgendwie
Du hast sicher schon in C programmiert und weißt wie das mit den sockets abläuft. Es ist daher schlicht unnötiger Overhead irgendwelche sockets aufzumachen ohne die zu benötigen. Zumal 0.0.0.0 registriert ist - das macht alle anderen sockets unnötig. Darum ist das mindestens schlechter Stil und maximal unnötige Verschwendung von Ressourcen. Nicht, dass es den Server langsam machen würde - es ist einfach unnötig wie ein Kropf. Und das nervt mich schon gewaltig, weil gerade sockets keine Sachen sind die "mal eben so" geöffnet werden sollen. Mir erschwert das die Administration - stell dir mal vor das würde jeder Dienst so machen

Und was sind das denn für IP-Adressen, die Du ganz oben mit <ip> versteckt hast? Sind das welche aus Deinem LAN?

Öffentlicher Server - daher will ich die IP nicht rausposaunen. Ist ja eh unerheblich welche IP das ist für meine Frage.

Mach mal bitte ntp nicht so schlecht, das Tool ist Gold wert und funktioniert einwandfrei - wenn man weiss, wie man es bedienen muss.

Na das kommt halt immer drauf an welche Ansprüche man hat. Ich könnte auch einfach ntp verwenden und die Zeit "reinhämmern", danach mailservices neu starten und gut is. Aber ich will eben eine optimale Lösung, nicht ein "es geht doch"
Jaja...ich bin da perfektionistisch, aber ich glaube das zahlt sich am Ende aus.

@cosmac: Hey danke! Werde ntpdate -B und ntpclient mal ausprobieren und Rückmeldung geben. Mir gehts nicht um die millisekundengenaue Einrichtung der Zeit, aber es sollte sich eben um Abweichungen < 10 Sekunden handeln - mit der Hardwareuhr scheint das nicht so zu klappen, nach einem Monat gibts da echt schon eine Abweichung die etwas heftiger ist (zwischen 5 und 7 Sekunden über die letzten Messungen).

[yeti]

Mach mal bitte ntp nicht so schlecht, das Tool ist Gold wert und funktioniert einwandfrei - wenn man weiss, wie man es bedienen muss.

Na das kommt halt immer drauf an welche Ansprüche man hat. Ich könnte auch einfach ntp verwenden und die Zeit "reinhämmern", danach mailservices neu starten und gut is. Aber ich will eben eine optimale Lösung, nicht ein "es geht doch"
Jaja...ich bin da perfektionistisch, aber ich glaube das zahlt sich am Ende aus.

Heiliges Lötzinn: Totaler Quatsch!
Deine Probleme mit NTP verschwinden genau dann, wenn Du es benutzt, wie es gedacht ist: ntpd dauerlaufen lassen!
Dann gibt es maximal beim Start von ntpd einen Zeitsprung und danach keinen Weiteren...
Und dieser eine Sprung findet beim Hochfahren des Systemes statt und da läuft noch kein Mailerdämon!
Informier Dich mal gründlicher!

[Flynn]

Deine Probleme mit NTP verschwinden genau dann, wenn Du es benutzt, wie es gedacht ist: ntpd dauerlaufen lassen!

Gerne, solange keine sockets geöffnet werden die ich schlicht nicht brauche.

Wir reden etwas aneinander vorbei
Mir ist klar wie ntpd funktioniert und die Funktionsweise ist auch gar nicht das Problem, sondern eben die unnötigen "Features" und der Ballast den der Quatsch mitbringt. Ich nutzt doch schon ntpd, damit ich eben nicht die Zeit "reinhämmern" muss - aber ideal ist's eben auch nicht (dazu steht ja oben schon WAS ich bekackt finde).

Jetzt erkläst du mir noch warum 0.0.0.0 als socket benötigt wird und warum er dazu noch parallel auf anderen IPs (also allen die er finden kann) lauscht. Das hat nix mit der Funktionsfähigkeit zu tun, oder?
Ich will die Uhr stellen, nicht verteilen und ich will nicht irgendwelche Ports sperren müssen um irgendwelche blödsinnigen Features zu unterbinden.

Vielleicht solltest auch du dir die Sache etwas genauer durchlesen und etwas netter Schreiben
Finds nett wenn du helfen willst, aber dann bitte auch höflich bleiben

[AlterSack]

Also erstmal: Unter http://www.ntp.org/ findest Du ausführliche Dokumentation rund um ntp.

Ich habe nicht ganz begriffen, wo eigentlich Dein Problem liegt: Ein ntpd läuft kontinuierlich, damit er die Kernelzeit kontinuierlich anpassen kann. Er pollt in gewissen Abständen, die umso größer sind, je besser die momentan erreichte lokale Genauigkeit ist, einen oder mehrere öffentliche Zeitserver, genau die, die man in ntp.conf eingetragen hat. Er stellt die Zeit wiederum zur Verfügung. Letzteres kann man mit geeigneten Einträgen in der ntp.conf auch unterbinden (Stichwort "restrict", siehe http://www.eecis.udel.edu/~mills/ntp/ht ... l#restrict). Wenn Du den Zugriff von außen komplett unterbinden willst, dann mußt Du halt den Port sperren. So ist das nun mal bei Serverdiensten.

ntpdate ist keine Alternative, da es die Zeit nicht quasikontinuierlich korrekt hält. Ich setze ntpdate nur in zwei Fällen ein:

- Beim Booten, wenn ich davon ausgehen muß, daß die Uhr für ntpd zu stark verstellt ist (wenn ich zB weiß, daß der Pufferakku hinüber ist);
- Bei Rechnern, wo der Einsatz von ntpd zu viele Ressourcen frißt UND es nicht auf kontinuierlich genaue Zeit ankommt (beispielsweise einer Firewall mit sehr wenig RAM [8-16MB]).

[cosmac]

hi,

Heiliges Lötzinn

damit diesen Uhrenchip einlöten: das könnte allerdings die Lösung aller Zeitprobleme sein! Aber wie kommt man als ungläubiger an sowas ran?

Der ntpclient hat hier gerade den ersten Test nicht bestanden. Meine PC-Uhr läuft um 150ppm zu schnell und war am Anfang um 0.7s daneben. Nach gut 3 Stunden hatte der ntpclient die Frequenz nachgeregelt, der Fehler war inzwischen 1.55s. Weitere 3 Stunden später ist der Fehler immer noch 1.47s, ohne dass er die Frequenz nochmal angepasst hätte. Man könnte also in 2 Tagen nochmal nachschauen... Also für den Desktop ist der ntpclient so nicht zu gebrauchen. Meine einzige Hoffnung ist ein größeres Abfrageintervall, vielleicht gibt's mit nur 60 Sekunden zuviel Rauschen.

Ansonsten beschränkt sich der ntpclient wirklich auf das Wesentliche.
- er kann nur einen Server abfragen: was passiert, wenn der nicht richtig tickt?
- er kann das Abfrageintervall nicht dynamisch anpassen: die Synchronisation dauert unötig lange.
- er ändert den Sync-Status im Kernel nicht: die CMOS-Uhr wird nicht automatisch mit eingestellt.
- er kennt kein Drift-File: nach dem Booten läuft die Uhr mit einer unnötig schlechten Frequenz.
Wenn man diese Funktionen mit einem Script nachrüstet, könnte es allerdings gut funktionieren.

Edit: nach einem "ntpclient -s" bleibt ein systematischer Fehler von 25ms. WTF?