OpenNTPD dsmod package

[level20peon]

Hallo,

der "PC" mit der IP "192.168.0.17" ist die Fritz!Box mit dem ds-mod / OpenNTPD Paket. Und wie du schon richtig vermutest holt er sich die Zeit von (wahrscheinlich) Stratum 1 Servern. Eben das kann ich nicht genau nachvollziehen, da ich keine Möglichkeit habe zu schauen woher genau das OpenNTPD nun die Zeiten bezieht. Wird dies eventuell vom ds-mod geloggt ? Die "/var/log/mod.log" enthält nur die Infos "gestartet" / "gestoppt" zu den einzelnen Paketen. Ich kann also nicht wirklich nachvollziehen, ob der Dienst überhaupt noch korrekt arbeitet. In den logs meines Routers finden sich trotzdem einige offene 123er UDP Ports, ausgehend von der Fritz!Box (UDP 123 ist der offizielle NTP Port).

Wie kann ich also, um hier beim ds-mod und der Fritz!Box zu bleiben überprüfen, ob diese Seite der Konfiguration korrekt funktioniert, sprich ob die Box überhaupt vom OpenNTPD Dienst aktualisiert wird ? Die Fehlermeldung "...da der Peer nicht synchronisiert ist bzw. die letzte Synchronisierung des Peers zu lange her ist." hat ja wenig mit "Strata" zu tun.

EDIT: Sollte ich vielleicht das syslogd Paket zum loggen installieren, oder würde das nicht die nötigen Ausgaben liefern ?

 

[kriegaex]

Die Standard-Konfiguration sieht doch so aus, daß die Zeit von Stratum-2-Servern geholt wird:

# Addresses to listen on (ntpd does not listen by default)
listen on $(ifconfig lan | head -n 2 | tail -n 1 | cut -d: -f2 | cut -d" " -f 1)

# use a random selection of 8 public stratum 2 servers
# see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
servers pool.ntp.org

Wieso läßt Du das nicht einfach so? Was macht Deine kleine Fritz!Box so wichtig, daß Du glaubst, sie müsse die Stratum-1-Server direkt belasten?

 

[level20peon]

Keine Angst, an der Konfiguration habe ich nichts geändert, deshalb schrieb ich ja "(wahrscheinlich) Stratum 1 Server". Die Aussage, die ich damit eigentlich treffen wollte war lediglich, dass die Fritz!Box in jedem Fall ein Stratum hat, welches niedriger ist als das der Server von denen sie die Zeit erfragt. Ich hätte wohl besser sowas wie "Stratum n-1" geschrieben.

 

[kriegaex]

Höher, meinst Du.

Und die zu synchronisierenden PCs im LAN sind so eingestellt, daß sie nur die Box fragen? Das solltest du trotzdem prüfen, schätze ich.

 

[level20peon]

hmpf Natürlich ist die Zahl höher, die Schicht ist niedriger:

Zumindest bei den Windows XP clients kann ich davon ausgehen, dass nur der eine Server benutzt wird, den man unter "Datum und Uhrzeit" eingibt. Nunja, ich merke, dass das hier eher in einer Definitionssache ausartet, als mich weiterzubringen. Gibt es denn wie ich früher schon gefragt hatte einen log auf der Fritz!Box, in dem steht "time synchronised successfully with NTP-Server xyz" ?

 

[kriegaex]

Hm, und wer postet Bildchen, um Begriffe zu definieren? Ich wollte mit meinem Hinweis auf höheres vs. niedrigeres Stratum lediglich Mißverständnisse vermeiden, denn die Fehlermeldungen, nach denen Du fragst, behandeln ja gerade diese Zahlenverhältnisse. Meine von Dir zunächst nicht beantwortete Frage, ob die Clients passend konfiguriert sind, bringt sehr wohl weiter, das ist nämlich nicht selbstverständlich. Irgendwoher müssen die Fehlermeldungen ja kommen.

Was das Logging betrifft, zeigt ein schneller Blick in die Manpage im Quellcode-Verzeichnis dies:

(... ) Adjustments larger than 128ms are logged using syslog(3). (...)

The options are as follows:
(...)
-d Do not daemonize. If this option is specified, ntpd will run in the foreground and log to stderr.
(...)

(Ja, Manpage lesen bringt auch weiter, das kann man sogar selbst machen, Schlaumeier.) Probier das doch mal und schau, was Du dabei erkennen kannst. Ansonsten ist ja bekannt, daß man sich das Syslog über "Extras" in der DS-Mod-Oberfläche, über dmesg von der Konsole aus oder, falls in Syslogd-CGI entsprechend konfiguriert, auch bequem am PC mittels einer Software wie Kiwi Syslog Daemon anschauen kann.

 

[level20peon]

Was das Logging betrifft, zeigt ein schneller Blick in die Manpage im Quellcode-Verzeichnis dies:

(... ) Adjustments larger than 128ms are logged using syslog(3). (...)

The options are as follows:
(...)
-d Do not daemonize. If this option is specified, ntpd will run in the foreground and log to stderr.
(...)

(Ja, Manpage lesen bringt auch weiter, das kann man sogar selbst machen, Schlaumeier.) Probier das doch mal und schau, was Du dabei erkennen kannst.

Tut mir Leid, ich habe in den "openntpd-3.9p1-dsmod-0.2" und in dem "ds26-15.2" Paketen keine derartige manpage gefunden. In keiner der enthaltenen Dateien ist der von dir beschriebene content vorhanden. Ich mache wohl wieder etwas falsch... wahrscheinlich bin ich noch zu unfähig, um mich Problemen auf dieser Ebene stellen zu können, da ich bis vor zwei Wochen noch nie etwas mit UNIX zu tun hatte (das ist nicht sarkastisch gemeint). Das loggen selbst wird kein Problem darstellen denke ich.

Ich werde mich mal durchs Wiki und diese Seite wühlen, um rauszubekommen, wie ich dem installierten ntp-Dienst nun den "-d" Parameter verpassen kann.

 

[kriegaex]

Ich habe auch nicht von Paketen gesprochen, sondern vom Quellcode-Verzeichnis (source/openntpd-3.9p1). Schau dort mal nach ntpd.8 und ntpf.conf.5. P.S.: Macht doch nix.

 

[level20peon]

Puh, also nach einigen Tests und Recherchen habe ich nun folgendes rausgefunden: Der OpenNTPD-Server der FritzBox lässt keine updates zu, solange er nicht synchron ist. Dies ist der Fall, nachdem die Box neu gestartet wird und nachdem die Internet-Verbindung unterbrochen wurde, eine Minute Unterbrechung reicht hierbei schon aus. Nun synchronisiert sich der NTPD der Box aber entgegen meinen Erwartungen nicht sofort nach Wiederaufnahme der Internet-Verbindung neu, sondern errechnet mithilfe des sogenannten "Marzullo-Algorithmus" die genaue Differenz der lokalen Zeit mit dem remote NTP-Server. Diese Vorgehensweise beinhaltet, dass einige "Zeitproben" der remote NTP-Server genommen und abgeglichen werden, bis die Zeit letztenendes im lokalen NTP-Dienst gesetzt wird. Bei meinen Tests war es jedes mal eine gute halbe Stunde, bis dies vollbracht war. In dieser Zeit tauchen die von mir im ersten Post beschriebenen Fehler auf, danach läuft alles reibungslos.
Nun gibt es jedoch laut manpage folgende Möglichkeit:

[noparse]
[...]
The options are as follows:
[...]
-S Do not set the time immediately at startup. This is the
default.

-s Set the time immediately at startup if the local clock is off
by more than 180 seconds. Allows for a large time correc-
tion, eliminating the need to run rdate(8) before starting
ntpd. Currently, the -s option is added unconditionally in
rc(8). Make sure to specify the -S option (add/edit
ntpd_flags in rc.conf.local(8)) if this behaviour is not
desired.
[/noparse]

Der OpenNTPD müsste also mit dem Parameter "-s" gestartet werden, um eine Synchronisierung direkt beim Start zu bewirken. Nun muss ich nur noch rausfinden, wie ich diesen Parameter in die "/etc/default.openntpd" einpflegen kann, damit dies standardmäßig gemacht wird (Wenn ich alles richtig interpretiert habe). Ich melde mich später wieder.

 

[RalfFriedl]

In Datei /etc/init.d/rc.openntpd wird der ntpd aufgerufen. Allerdings ist die Option -s schon drin.

ntpd -s -f /mod/etc/ntpd.conf

 

[level20peon]

Hmm, das ist komisch. In der Manpage steht ja, dass "-S" (uppercase) default ist, aber wenn nun "-s" (lowercase), was eine unmittelbare Zeitsetzung bewirkt schon drin ist, frage ich mich warum es (bei mir) nicht funktioniert.

 

[RalfFriedl]

Vielleicht ist die Box noch nicht online, wenn ntpd aufgerufen wird. Dann würde ntpd bei Start versuchen, die Zeit zu setzen, erreicht keinen Zeitserver und synchronisiert später ganz normal, also erst nach mehreren Versuchen.

Bei mit baut die Box die Verbindung zum Internet nicht auf, so daß der Zeitserver sofort erreichbar ist, daher ist die Zeit fast sofort nach dem Start vorhanden.

 

[level20peon]

Meine Box baut ebenfalls die Verbindung zum Internet nicht selbst auf. Nachdem ich die OpenNTPD-Box reboote, ohne die Internetverbindung des Netzwerkes zu trennen, dauert es wie oben beschrieben eine gute halbe Stunde, bis die Zeitsetzung dann letztenendes erfolgt.

 

[RalfFriedl]

Dann stell mal den automatischen Start von OpenNTP aus, starte die Box neu.
Ruf ntpd von Hand auf mit

ntpd -d -s -f /mod/etc/ntpd.conf

Damit bekommst Du die Meldungen des ntpd angezeigt. Vielleicht kommt da etwas sinnvolles heraus.

 

[level20peon]

Diese Eingabe wirft leider ein "/mod/etc/ntpd.conf: No such file or directory" zurück. Wenn ich den OpenNTPD Dienst einmal starte und dann wieder beende wird diese Datei scheinbar erstellt und ich erhalte Ausgaben. In diesen Ausgaben ist alle paar Minuten ein "adjusting local clock by 0.xxxxxxs" enthalten, die Uhr scheint also gestellt zu werden. Eine Synchronisierung mit einem client ist trotzdem erst nach der von mir beschriebenen guten halben Stunde möglich.

 

[RalfFriedl]

Bei mir kommen beim Start folgende Meldungen (mit vorhandener Config):

$ ntpd -d -s -f /mod/etc/ntpd.conf
listening on 192.168.2.1
ntp engine ready
reply from 192.168.2.2: offset 1187458596.926250 delay 0.001750, next query 9s
set local clock to Sat Aug 18 19:37:59 CEST 2007 (offset 1187458596.926250s)

Das Ganze kommt fast sofort.

Der riesige Offset kommt daher, daß ich vorher das Datum auf 010101011970 gesetzt habe.

Bei der Gelegenheit habe ich auch festgestellt, daß das Programm telefon verhindert, daß die Zeit zurück gestellt wird. Allerdings nach einem Neustart nicht mehr. Anscheinend nur dann, wenn es schon eine Zeit über ISDN bekommen hat.

Die Konfigurationsdatei wird erstellt mit

/var/mod/etc/default.openntpd/openntpd_conf
test -f /tmp/flash/openntpd_conf && /tmp/flash/openntpd_conf

Die zweite Zeile braucht man nur, wenn man dort eine eigene Konfiguration hinterlegt hat.

Damit kannst Du ntpd aufrufen, ohne vorher den Dienst zu starten.

 

[level20peon]

Nach dem Aufruf von "/var/mod/etc/default.openntpd/openntpd_conf" habe ich versucht das "ntpd -d -s -f /mod/etc/ntpd.conf" auszuführen. Diesmal kam ein "ntpd: unknown user ntp" zurück.
Ich möchte an dieser Stelle anmerken, dass ich an dem ds-mod dieser Box nichts geändert habe, ausser "openntpd" und "syslogd" im menuconfig ausgewählt zu haben mit anschließender Kompilierung. Außerdem ist mir aufgefallen, dass wenn ich den Service im ds-mod stoppe "Stopping ntp server...failed." angezeigt wird. Im Statusfenster wird trotzdem anschließend "stopped" angezeigt. Vielleicht hilft diese Information ja irgendwie weiter...
Ich verstehe nicht, warum es bei mir trotz "Standardkonfiguration" zu solchen Problemen kommen kann. Danke trotzdem für alle Mühen.

 

[RalfFriedl]

Anscheinend braucht man da doch etwas mehr.

echo "ntp:x:123:123::/mod/home/ntp:/bin/false" >> /var/tmp/passwd
mkdir -p /mod/home/ntp
chown root /mod/home/ntp
chmod 700 /mod/home/ntp
/var/mod/etc/default.openntpd/openntpd_conf
test -f /tmp/flash/openntpd_conf && /tmp/flash/openntpd_conf

Das sollte dann aber reichen, um den ntpd zu starten.
Ansonsten kannst Du in der /etc/init.d/rc.openntpd nachschauen, wenn doch noch etwas fehlen sollte.

 

[level20peon]

Damit konnte ich den ntpd starten, danke. Ich bin auf etwas interessantes gestoßen.
Nach etwa einer Minute taucht zum ersten mal "adjusting local clock by -0.xxxxxxs" auf. Trotzdem ist zu diesem Zeitpunkt noch keine Synchronisation mit dem OpenNTPD Server möglich. Dieses "adjusting local clock..." taucht alle paar Minuten auf. Doch erst nach der von mir bereits festgestellten Zeit von einer guten halben Stunde taucht folgendes im log auf:

adjusting local clock by -0.013668s
skew change -6.134 exceeds limit
opening drift file for writing failed: No such file or directory
interval 2228.203 skew -6.134 total skew -5.000
[COLOR="Red"]clock is now synced[/COLOR]

Nach diesem event kann ich dann die clients mit dem OpenNTPD Server synchronisieren.

 

[RoyceMcKnight]

Richig, openntpd sychronisiert schon ziemlich genau, nur dauert das eben auch seine Zeit. Z.B. werden mehrere Zeitserver verwendet, und openntpd muss auch den Lag der bei der Übertragung entsteht kompensieren, auch wenn es nur 5ms sind. Dann kommt es noch drauf an wie genau die Uhr der Box ging. Zwischen Start von openntpd und dem erfolgreichen "clock is now synced" können somit zum Teil auch gut und gerne mal 45 Minuten vergehen.