Hallo, ich habe unter SuSE 9.0 ein Problem mit xntpd. Beim Starten des Dienstes kommt folgende Meldung in der Datei /var/log/ntp: ntpd exiting on signal 15 Meine /etc/ntp.conf lautet: server 192.53.103.103 fudge 192.53.103.103 stratum 10 Ich verwende zur Einrichtung nur YaST, aber trotzdem ist der XNTPD-Daemon nicht für Synchronisationszwecke zu erreichen. Wer weiss rat? Viele Grüße Michael PS: Die Firewall ist komplett ausgeschaltet.
Am Montag, 21. August 2006 18:56 schrieb Michael Post:
Hallo,
ich habe unter SuSE 9.0 ein Problem mit xntpd. Beim Starten des Dienstes kommt folgende Meldung in der Datei /var/log/ntp:
ntpd exiting on signal 15
Meine /etc/ntp.conf lautet:
server 192.53.103.103 fudge 192.53.103.103 stratum 10 Wenn ich das hier (10.0) versuche, kommt in /var/log/messages zusätzlich die Meldung, dass der Server für "fudge" nicht geeignet sei. Die Synchronisation funktioniert dann aber trotzdem. Ist der 9.0-xntp da vielleicht etwas kritischer?
Versuchs mal damit: ------------- server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized server de.pool.ntp.org server 192.53.103.103 #fudge 192.53.103.103 stratum 10 driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file ------------- "ntpq -p" sollte dir dann den Fortschritt der Synchronisation anzeigen, das braucht einige Minuten. Falls dein ntpd beide Server nicht erreichen kann, ist vielleicht "weiter draußen" noch ein Firewall im Weg. -- Viele Grüße ------------------------------------------------------------------------ Michael
Hallo Michael, Michael Behrens schrieb:
Wenn ich das hier (10.0) versuche, kommt in /var/log/messages zusätzlich die Meldung, dass der Server für "fudge" nicht geeignet sei. Die Synchronisation funktioniert dann aber trotzdem. Ist der 9.0-xntp da vielleicht etwas kritischer?
Versuchs mal damit: ------------- server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
server de.pool.ntp.org server 192.53.103.103 #fudge 192.53.103.103 stratum 10
driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file -------------
"ntpq -p" sollte dir dann den Fortschritt der Synchronisation anzeigen, das braucht einige Minuten. Falls dein ntpd beide Server nicht erreichen kann, ist vielleicht "weiter draußen" noch ein Firewall im Weg.
das interessante ist ja eher, dass er den Server einwandfrei erreichen kann und auch synchronisiert. Die Uhrzeit wird einwandfrei geändert. Nur kann meinen lokalen Server kein anderer Rechner in meinem Netzwerk erreichen. Nur kann ich, wenn ich meinen eigenen Server mit "netdate localeIP" erreichen möchte, er nicht synchronisieren, da der NTPServer nicht erreichbar ist. Warum? Firewall ist aus!
das interessante ist ja eher, dass er den Server einwandfrei erreichen kann und auch synchronisiert. Die Uhrzeit wird einwandfrei geändert. Nur kann meinen lokalen Server kein anderer Rechner in meinem Netzwerk erreichen. Nur kann ich, wenn ich meinen eigenen Server mit "netdate localeIP" erreichen möchte, er nicht synchronisieren, da der NTPServer nicht erreichbar ist. Warum? Firewall ist aus!
Netdate wendet sich an den time-port, nicht an ntp. time kannst du via (x)inetd aktivieren.
Hallo Dominik, Dominik Klein schrieb:
Netdate wendet sich an den time-port, nicht an ntp.
time kannst du via (x)inetd aktivieren.
Ok. Aber auf den anderen Rechnern habe ich auch XNTPD installiert und dort als Server den Lokalen Rechner eingetragen. Trotzdem können die den Rechner nicht erreichen. Ping und SMB etc funktionieren einwandfrei. Firewalls sind ÜBERALL ausgeschaltet. Unter den Windows-Clients verwende ich den net-Befehl zum erreichen des Servers. Scheint aber auch nicht mehr zu funktionieren. Wenn meine Kenntnisse mich nicht in die Irre leiten, dann sollte ich doch eigentlich unter netstat -an | grep LISTEN den Port des xntpd sehen, oder? Dort ist aber nur 10024 und 22 von ausserhalb des Servers erreichbar. Welchen Port nutzt xntpd und warum ist der entspr. Port nicht aufgelistet? Vielen Dank Michael
On Tuesday 22 August 2006 13:07, Michael Post wrote:
Hallo Dominik,
Hallo Michael,
Dominik Klein schrieb:
Netdate wendet sich an den time-port, nicht an ntp.
time kannst du via (x)inetd aktivieren.
Ok. Aber auf den anderen Rechnern habe ich auch XNTPD installiert und dort als Server den Lokalen Rechner eingetragen. Trotzdem können die den Rechner nicht erreichen. Ping und SMB etc funktionieren einwandfrei. Firewalls sind ÜBERALL ausgeschaltet.
Unter den Windows-Clients verwende ich den net-Befehl zum erreichen des Servers. Scheint aber auch nicht mehr zu funktionieren.
Wenn meine Kenntnisse mich nicht in die Irre leiten, dann sollte ich doch eigentlich unter netstat -an | grep LISTEN den Port des xntpd sehen, oder?
Dort ist aber nur 10024 und 22 von ausserhalb des Servers erreichbar.
Welchen Port nutzt xntpd und warum ist der entspr. Port nicht aufgelistet?
Erlaube in Deiner ntp.conf das lokale Netz. Beispiel: restrict 172.27.177.0 mask 255.255.255.255 notrust notrap nomodify IIRC ist restrict 127.0.0.1 default.
Vielen Dank
LG, Benni -- Benjamin Zeller Ing.-Büro Hohmann Bahnhofstr. 34 D-82515 Wolfratshausen Tel.: +49 (0)8171 347 88 12 Mobil: +49 (0)160 99 11 55 23 Fax: +49 (0)8171 910 778 mailto: zeller@ibh-wor.de www.ibh-wor.de
Hallo. * Dienstag, 22. August 2006 um 13:07 (+0200) schrieb Michael Post:
Wenn meine Kenntnisse mich nicht in die Irre leiten, dann sollte ich doch eigentlich unter netstat -an | grep LISTEN den Port des xntpd sehen, oder?
Oder! NTP nutzt UDP und UDP kennt keinen Status "LISTEN" (und auch keine anderen Stati). kocom:~ # netstat -pan | grep ntp udp 0 0 192.168.39.1:123 0.0.0.0:* 5277/ntpd udp 0 0 192.168.0.1:123 0.0.0.0:* 5277/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 5277/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 5277/ntpd udp 0 0 :::123 :::* 5277/ntpd
Dort ist aber nur 10024 und 22 von ausserhalb des Servers erreichbar.
Welchen Port nutzt xntpd
s.o. und warum ist der entspr. Port nicht aufgelistet? Falsches grep-Pattern... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
participants (5)
-
Andreas Koenecke
-
Benjamin Zeller
-
Dominik Klein
-
Michael Behrens
-
Michael Post