ntpd und netbsd 1.6.2

[sebbo]

Hola!

Ich wollte einen Timeserver in meinem kleinen Netzwerk anbringen, damit nicht alle Rechner ntp.fu-berlin.de belasten.
In /etc/rc.conf habe ich folgendes eingetragen:

ntpd=YES
ntpd_flags="-g -A"

Meine /etc/ntp.conf sieht so aus:

# Process ID file, so that the daemon can be signalled from scripts
pidfile /var/run/ntpd.pid

# The correction calculated by ntpd(8) for the local system clock's
# drift is stored here
driftfile /var/db/ntp.drift

# suppress the syslog(3) message for each peer synchronization change
logconfig -syncstatus

server ntp.fu-berlin.de

restrict default ignore
restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap

Der Server hat die IP 192.168.0.1 (avalon) und die Clienten sind im selben Subnet.
Wenn ich nun "ntpdate -u avalon" ausfuehre, beschwert sich nptdate aus einem mir unverstaendlichen Grund:

20:43 ~ # ntpdate avalon
Looking for host avalon and service ntp
host found : avalon.euphoria.lan
11 Mar 20:43:58 ntpdate[8815]: no server suitable for synchronization found

Im Debugmode sieht das ganze so aus:

20:43 ~ # ntpdate -d avalon
11 Mar 20:45:15 ntpdate[8831]: ntpdate 4.2.0@1.1161-r Wed Jan 12 18:48:31 CET 2005 (1)
Looking for host avalon and service ntp
host found : avalon.euphoria.lan
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
receive(192.168.0.1)
transmit(192.168.0.1)
192.168.0.1: Server dropped: strata too high
server 192.168.0.1, port 123
stratum 16, precision -18, leap 11, trust 000
refid [192.168.0.1], delay 0.02576, dispersion 0.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: c5dc73cb.17e8ff32 Fri, Mar 11 2005 20:45:15.093
transmit timestamp: c5dc73cc.09f31f46 Fri, Mar 11 2005 20:45:16.038
filter delay: 0.02592 0.02577 0.02576 0.02576
0.00000 0.00000 0.00000 0.00000
filter offset: -0.94553 -0.94557 -0.94557 -0.94557
0.000000 0.000000 0.000000 0.000000
delay 0.02576, dispersion 0.00000
offset -0.945575

11 Mar 20:45:16 ntpdate[8831]: no server suitable for synchronization found

ntpdc -c kerninfo avalon und ntpdc -c reslist avalon sagen folgendes:

pll offset: 0 s
pll frequency: 0.000 ppm
maximum error: 0.747024 s
estimated error: 1.6e-05 s
status: 0041 pll unsync
pll time constant: 0
precision: 1e-06 s
frequency tolerance: 512 ppm

address mask count flags
=====================================================================
0.0.0.0 0.0.0.0 27 ignore
localhost 255.255.255.255 0 ntpport, interface, ignore
192.168.0.0 255.255.255.0 95 notrust, nomodify, notrap
avalon.euphoria 255.255.255.255 0 ntpport, interface, ignore
avalon.euphoria 255.255.255.255 0 ntpport, interface, ignore

Also ich weiss echt nicht mehr weiter. Hat jemand von euch ein aehnliches Problem oder seh ich vielleicht nur vor lauter Wald die Baeume nicht mehr?


mfg
sebbo

 

[p.h.]

Du möchtest bitte "Screenshots" in CODE-Blöcke einpacken, jetzt muß ich sie nämlich manuell in meinen Beitrag reinkopieren.

192.168.0.1: Server dropped: strata too high
server 192.168.0.1, port 123
stratum 16, precision -18, leap 11, trust 000

Server mit einem Statum von 16 werden natürlich nicht zur Synchronisation verwendet. Irgendwas läuft auf deinem NTP-Server schief. Was zeigt die Augabe von ntpq -p auf 192.168.0.1? Eventuell hilft es, wenn du in der ntp.conf des Servers noch:

restrict 127.0.0.1

anhängst, so habe ich das zumindest mal notiert

 

[sebbo]

Was zeigt die Augabe von ntpq -p auf 192.168.0.1?

Etwas mit dem ich noch weniger anfangen kann.

[root:~] > ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 chronos.zedat.f 0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00

Eventuell hilft es, wenn du in der ntp.conf des Servers noch:

restrict 127.0.0.1

anhängst, so habe ich das zumindest mal notiert

Nein, hilft leider nicht

Vielen Dank fuer deine Antwort
Sebbo

 

[p.h.]

[root:~] > ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 chronos.zedat.f 0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00

Dein NTP-Server kann sich nicht mit chronos.zedat.f... (der Rest ist in der Ausgabe von ntpq abgeschnitten) verbinden. Ansonsten würde vor dem Servernamen ein Sterchen angezeigt und unter refid die IP-Adresse des unter remote genannten Systems ausgewiesen. Daneben bescheinigt reach = 0, daß der andere Rechner in den letzten acht Versuchen nicht einmal erreicht wurde. Mit when = - wird dokumentiert, daß sich dein Server noch nie mit seinem Zeitgeber verbinden konnte. Da ist also etwas dauerhaft nicht in Ordnung.

Auch die letzten drei Spalten würden bei einer funktionierenden Synchronisation sinnvolle Werte anzeigen. Da dein NTP-Server ohne eine Verbindung zu einer Zeitquelle die Richtigkeit seiner eigenen Systemzeit nicht garantieren kann, setzt er sich auf den Stratum-Level 16 (Spalte st), der "schlechteste" Stratum-Wert in der NTP-Hierarchie. Kein NTP-Client wird sich mit so einem Server synchronisieren wollen.

Du solltest also zu erst einmal ausprobieren, wodurch das Problem auf dem Server begründet ist. Das kann natürlich viele Ursachen haben. Eventuell ist ein Paketfiler "im Weg"? Oder der Server chronos.zedat.f... hat selbst irgendein Problem? Versuche mal, den ntpd auf dem Server abzuschießen und die Zeit auf dem Server von Hand zu synchronisieren. Vielleicht kann man dann schon eventuelle Fehlermeldungen interpretieren. Du kannst auch mal testweise einen anderen Server als Referenz benutzen.

 

[sebbo]

Danke fuer die Antwort.

Sieht so aus als muesste ich das Ding wohl doch erstmal auseinandernehmen. Vielleicht sind auch wirklich nur ein paar uebertriebene Filterregeln im Weg.

Werde den Server mal morgen in ein anderes Netz stellen und durchtesten.

Nochmals vielen Dank fuer deine Hilfe.

sebbo

 

[sebbo]

So... Ich hab es hinbekommen.
Habe auf -current upgedatet und jetzt sieht die Config so aus:

pidfile         /var/run/ntpd.pid
driftfile       /var/db/ntp.drift
logconfig       -syncstatus

tos             minsane 2

server          0.pool.ntp.org
server          1.pool.ntp.org
server          2.pool.ntp.org

restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
restrict 127.0.0.1

Sieht ganz so aus als ob die Zeile "restrict default ignore" im Weg war.. Ich wuerde zwar trotzdem gerne den Zugriff von aussen "sauber" unterbinden, aber jetzt muss halt pf dran glauben..