10
Ubuntu Server 12.04: NTP Problem
Hallo Zusammen,
habe ein Problem mit der Zeitsynchronisation. Wenn ich über "date" die Zeit abfrage, geht die Uhr genau eine Stunde nach:
Habe die richtige Zeitzone konfiguriert und 3 Zeitserver in die ntp.conf eingetragen (ptbtime1/2/3)
Hier ein Auszug aus dem syslog:
19:00:07 sxsrv-mx ntpdate[664]: no server suitable for synchronization found
Jan 7 19:00:07 sxsrv-mx ntpd[1120]: ntpd 4.2.6p3@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1)
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: proto: precision = 1.447 usec
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen and drop on 1 v6wildcard :: UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 3 eth0 192.168.10.6 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 4 lo ::1 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 5 eth0 fe80::8070:45ff:feb5:21c8 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: peers refreshed
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listening on routing socket on fd #23 for interface updates
"ntpq -p" gibt folgendes aus:
remote refid st t when poll reach delay offset jitter
ptbtime1.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.000
ptbtime2.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.000
ptbtime3.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.000
"ntpdate ptbtime1.ptb.de" gibt das hier aus:
7 Jan 19:19:14 ntpdate[3037]: the NTP socket is in use, exiting
manchmal auch
7 Jan 19:36:41 ntpdate[3787]: no server suitable for synchronization found
"ntpdate" sagt folgendes:
7 Jan 19:21:17 ntpdate[3142]: no servers can be used, exiting
Kann mir bei hierbei jemand helfen?
habe ein Problem mit der Zeitsynchronisation. Wenn ich über "date" die Zeit abfrage, geht die Uhr genau eine Stunde nach:
Habe die richtige Zeitzone konfiguriert und 3 Zeitserver in die ntp.conf eingetragen (ptbtime1/2/3)
Hier ein Auszug aus dem syslog:
19:00:07 sxsrv-mx ntpdate[664]: no server suitable for synchronization found
Jan 7 19:00:07 sxsrv-mx ntpd[1120]: ntpd 4.2.6p3@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1)
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: proto: precision = 1.447 usec
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen and drop on 1 v6wildcard :: UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 3 eth0 192.168.10.6 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 4 lo ::1 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listen normally on 5 eth0 fe80::8070:45ff:feb5:21c8 UDP 123
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: peers refreshed
Jan 7 19:00:07 sxsrv-mx ntpd[1121]: Listening on routing socket on fd #23 for interface updates
"ntpq -p" gibt folgendes aus:
remote refid st t when poll reach delay offset jitter
ptbtime1.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.000
ptbtime2.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.000
ptbtime3.ptb.de .INIT. 16 u - 64 0 0.000 0.000 0.000
"ntpdate ptbtime1.ptb.de" gibt das hier aus:
7 Jan 19:19:14 ntpdate[3037]: the NTP socket is in use, exiting
manchmal auch
7 Jan 19:36:41 ntpdate[3787]: no server suitable for synchronization found
"ntpdate" sagt folgendes:
7 Jan 19:21:17 ntpdate[3142]: no servers can be used, exiting
Kann mir bei hierbei jemand helfen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 226037
Url: https://administrator.de/forum/ubuntu-server-12-04-ntp-problem-226037.html
Ausgedruckt am: 25.12.2024 um 21:12 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
bitte beachte folgende Punkte:
1. Der NTP Dienst syncronisiert die Zeit nur dann, wenn sie nicht mehr als einen bestimmten Schwellwert abweicht.
Wie hoch dieser Schwellwert ist, liegt an der verwendeten Distribution. Alles über 5 bis 10 Minuten ist aber meist zu hoch und wird vom Dienst nicht gerade gezogen.
2. ntpdate funktioniert nur, wenn der Port frei ist.
Sprich du musst den Dienst vorher ausschalten.
Versuche folgendes:
1. NTP-Dienst anhalten
2. ntpdate ausführen
3. NTP-Dienst wieder starten
4. Einige Zeit warten (2-3 Minuten sind normal), bis der NTP-Dienst bei ntpstat und ntpq -p eine Synchronisation anzeigt.
So lange da INIT steht, läuft das noch nicht.
Alternativ mal diese NTP Server probieren:
0.de.pool.ntp.org
1.de.pool.ntp.org
2.de.pool.ntp.org
3.de.pool.ntp.org
Grüße,
Daniel
bitte beachte folgende Punkte:
1. Der NTP Dienst syncronisiert die Zeit nur dann, wenn sie nicht mehr als einen bestimmten Schwellwert abweicht.
Wie hoch dieser Schwellwert ist, liegt an der verwendeten Distribution. Alles über 5 bis 10 Minuten ist aber meist zu hoch und wird vom Dienst nicht gerade gezogen.
2. ntpdate funktioniert nur, wenn der Port frei ist.
Sprich du musst den Dienst vorher ausschalten.
Versuche folgendes:
1. NTP-Dienst anhalten
2. ntpdate ausführen
3. NTP-Dienst wieder starten
4. Einige Zeit warten (2-3 Minuten sind normal), bis der NTP-Dienst bei ntpstat und ntpq -p eine Synchronisation anzeigt.
So lange da INIT steht, läuft das noch nicht.
Alternativ mal diese NTP Server probieren:
0.de.pool.ntp.org
1.de.pool.ntp.org
2.de.pool.ntp.org
3.de.pool.ntp.org
Grüße,
Daniel
NTP nutzt als Quell- und Zielport den gleichen Port, somit gibt es also ein Problem, wenn ein NTP-Server gleichzeitig NTP-Client ist. Was man machen könnte wäre ein bisschen Pfusch. Du gibst dem Server noch ne weitere IP-Adresse, bindest den Server auf die eine IP, den Client auf die zweite IP, dann gibt es das Port-Problem nicht mehr.
ntpdate 0.de.pool.ntp.org
7 Jan 21:23:39 ntpdate[2537]: no server suitable for synchronization found
Bei gestoppten ntp Dienst. Habe es auch mit der IP statt dem Namen versucht.
7 Jan 21:23:39 ntpdate[2537]: no server suitable for synchronization found
Bei gestoppten ntp Dienst. Habe es auch mit der IP statt dem Namen versucht.
Hallo,
hier noch einige Ansätze:
- Netzwerk: Kannst du den Server pingen?
- Netzwerk: Zeigt route -n ein Default-Gateway an?
- Netzwerk: Firewall aus? (Für Inbound und Outbound Traffic)
- Netzwerk: Kannst du eine UDP Verbindung zu dem NTP Server aufbauen (nc --udp <Server> 123 und auch telnet <Server> 123 liefert KEIN "Connection refused" am Ende)?
- SELinux: Zeigt setenforce 0 eine Auswirkung?
- NTP: Was erzählt ntpdate -d 0.pool.ntp.org?
- NTP: Hilft es was, die ursprüngliche Konfigurationsdatei /etc/ntp.conf zurückzusichern?
Grüße,
Daniel
hier noch einige Ansätze:
- Netzwerk: Kannst du den Server pingen?
- Netzwerk: Zeigt route -n ein Default-Gateway an?
- Netzwerk: Firewall aus? (Für Inbound und Outbound Traffic)
- Netzwerk: Kannst du eine UDP Verbindung zu dem NTP Server aufbauen (nc --udp <Server> 123 und auch telnet <Server> 123 liefert KEIN "Connection refused" am Ende)?
- SELinux: Zeigt setenforce 0 eine Auswirkung?
- NTP: Was erzählt ntpdate -d 0.pool.ntp.org?
- NTP: Hilft es was, die ursprüngliche Konfigurationsdatei /etc/ntp.conf zurückzusichern?
Grüße,
Daniel
Hallo,
Folgende Punkte testen:
- In /etc/default/ntp ein "-4" eintragen um nur IPv4 zu verwenden
- Namensauflösung per "dig <ntp.server.name>" prüfen
- Prüfen ob NAT auch für UDP funktioniert und eingehendes UDP -> Port 123 zugelassen wird, im Zweifelsfall tcpdump fragen
Gruß
Andi
Folgende Punkte testen:
- In /etc/default/ntp ein "-4" eintragen um nur IPv4 zu verwenden
- Namensauflösung per "dig <ntp.server.name>" prüfen
- Prüfen ob NAT auch für UDP funktioniert und eingehendes UDP -> Port 123 zugelassen wird, im Zweifelsfall tcpdump fragen
Gruß
Andi
So, ich bin nun einen Schritt weiter. Ich habe nun als NTP Server unseren Domänencontroller genommen und siehe da es geht.
Der DC befindet sich im selben Netz, hat das selbe Gateway und ist auch hinter der selben Firewall, wie Ubuntu
Schlauer bin ich also immernoch nicht. Zugegebenerweise bin ich aber auch noch nicht so Linux erfahren. DNS Abfragen auf ptb und Konsorten waren auf jeden Fall erfolgreich.
Auch wenn ich mit dieser Lösung nun leben könnte, würde mich trotzdem interessieren, wo hier nun mein Fehler liegt.
Hier das Ergebnis von ntpq -p
remote refid st t when poll reach delay offset jitter
DC.DOMÄNE.local .LOCL. 1 u 59 64 377 1.560 -0.425 0.574
ptbtime1.ptb.de .INIT. 16 u - 256 0 0.000 0.000 0.000
192.168.10.255 .BCST. 16 u - 64 0 0.000 0.000 0.002
Der tcpdump sagt folgendes:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:58:06.598424 IP UBUNTU.DOMÄNE.local.ntp > DC.DOMÄNE.local.ntp: NTPv4, Client, length 48
13:58:06.601052 IP DC.DOMÄNE.local.ntp > UBUNTU.DOMÄNE.local.ntp: NTPv3, Server, length 48
13:58:07.600516 IP UBUNTU.DOMÄNE.local.ntp > ptbtime1.ptb.de.ntp: NTPv4, Client, length 48
Der DC befindet sich im selben Netz, hat das selbe Gateway und ist auch hinter der selben Firewall, wie Ubuntu
Schlauer bin ich also immernoch nicht. Zugegebenerweise bin ich aber auch noch nicht so Linux erfahren. DNS Abfragen auf ptb und Konsorten waren auf jeden Fall erfolgreich.
Auch wenn ich mit dieser Lösung nun leben könnte, würde mich trotzdem interessieren, wo hier nun mein Fehler liegt.
Hier das Ergebnis von ntpq -p
remote refid st t when poll reach delay offset jitter
DC.DOMÄNE.local .LOCL. 1 u 59 64 377 1.560 -0.425 0.574
ptbtime1.ptb.de .INIT. 16 u - 256 0 0.000 0.000 0.000
192.168.10.255 .BCST. 16 u - 64 0 0.000 0.000 0.002
Der tcpdump sagt folgendes:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:58:06.598424 IP UBUNTU.DOMÄNE.local.ntp > DC.DOMÄNE.local.ntp: NTPv4, Client, length 48
13:58:06.601052 IP DC.DOMÄNE.local.ntp > UBUNTU.DOMÄNE.local.ntp: NTPv3, Server, length 48
13:58:07.600516 IP UBUNTU.DOMÄNE.local.ntp > ptbtime1.ptb.de.ntp: NTPv4, Client, length 48
Zitat von @n0cturne:
So, ich bin nun einen Schritt weiter. Ich habe nun als NTP Server unseren Domänencontroller genommen und siehe da es geht.
Der DC befindet sich im selben Netz, hat das selbe Gateway und ist auch hinter der selben Firewall, wie Ubuntu
Schlauer bin ich also immernoch nicht. Zugegebenerweise bin ich aber auch noch nicht so Linux erfahren. DNS Abfragen auf ptb und
Konsorten waren auf jeden Fall erfolgreich.
Auch wenn ich mit dieser Lösung nun leben könnte, würde mich trotzdem interessieren, wo hier nun mein Fehler
liegt.
Hier das Ergebnis von ntpq -p
remote refid st t when poll reach delay offset jitter
DC.DOMÄNE.local .LOCL. 1 u 59 64 377 1.560 -0.425 0.574
ptbtime1.ptb.de .INIT. 16 u - 256 0 0.000 0.000 0.000
192.168.10.255 .BCST. 16 u - 64 0 0.000 0.000 0.002
Der tcpdump sagt folgendes:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:58:06.598424 IP UBUNTU.DOMÄNE.local.ntp > DC.DOMÄNE.local.ntp: NTPv4, Client, length 48
13:58:06.601052 IP DC.DOMÄNE.local.ntp > UBUNTU.DOMÄNE.local.ntp: NTPv3, Server, length 48
13:58:07.600516 IP UBUNTU.DOMÄNE.local.ntp > ptbtime1.ptb.de.ntp: NTPv4, Client, length 48
So, ich bin nun einen Schritt weiter. Ich habe nun als NTP Server unseren Domänencontroller genommen und siehe da es geht.
Der DC befindet sich im selben Netz, hat das selbe Gateway und ist auch hinter der selben Firewall, wie Ubuntu
Schlauer bin ich also immernoch nicht. Zugegebenerweise bin ich aber auch noch nicht so Linux erfahren. DNS Abfragen auf ptb und
Konsorten waren auf jeden Fall erfolgreich.
Auch wenn ich mit dieser Lösung nun leben könnte, würde mich trotzdem interessieren, wo hier nun mein Fehler
liegt.
Hier das Ergebnis von ntpq -p
remote refid st t when poll reach delay offset jitter
DC.DOMÄNE.local .LOCL. 1 u 59 64 377 1.560 -0.425 0.574
ptbtime1.ptb.de .INIT. 16 u - 256 0 0.000 0.000 0.000
192.168.10.255 .BCST. 16 u - 64 0 0.000 0.000 0.002
Der tcpdump sagt folgendes:
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:58:06.598424 IP UBUNTU.DOMÄNE.local.ntp > DC.DOMÄNE.local.ntp: NTPv4, Client, length 48
13:58:06.601052 IP DC.DOMÄNE.local.ntp > UBUNTU.DOMÄNE.local.ntp: NTPv3, Server, length 48
13:58:07.600516 IP UBUNTU.DOMÄNE.local.ntp > ptbtime1.ptb.de.ntp: NTPv4, Client, length 48
Keine Antwort von ptbtime1.ptb.de d.h. das wohl eine Firewall oder ein Router was dagegen hat. Wie ist eure Internet Verbindung gesichert? Dort einfach mal fragen ich nehme an der DC hat eine Ausnahme.
Gruß
Andi
Als Firewall nutzen wir endian Community. Den Port 123 habe ich geöffnet.
Endian nimmt eine PPPoE Einwahl vor und ist somit ist die einzige Komponente, die zwischen Ubuntu und dem Internet steht.
Endian nimmt eine PPPoE Einwahl vor und ist somit ist die einzige Komponente, die zwischen Ubuntu und dem Internet steht.
Hallo,
- Was ist mit der Firewall des Linux-Systems?
- Wie genau ist der Port 123 offen? (Inbound, Outbound, TCP, UDP ?)
- Ist auf der Firewall eine Art von NAT (Source NAT, Destination NAT) konfiguriert?
Bitte beachte, dass das Paket folgenden Weg nimmt:
1. Dein Server sendet ein NTP Paket los (DNS benötigt)
2. Das Paket muss die Firewall des lokalen Linux Servers passieren
3. Das Paket wird an das Gateway (endian Comunity Firewall) weitergeleitet
4. Die Firewall muss das Paket akzeptieren und weiterleiten
5. (optional) Abhängig von der Konfiguration findet auf der Firewall evtl. eine Adressübersetzung (NAT) statt
So weit, so gut.
Ein sehr verbreiteter Fehler ist aber, das selbst wenn das Paket den Zielhost erfolgreich erreicht, die Antwort auch wieder den Weg zurück finden muss.
Viele Firewalls erkennen zwar, dass das eine Sitzung (Anfrage und Antwort) ist, aber wenn z.B. das NAT nur für ausgehende Pakete konfiguriert ist, schlägt das fehl.
Hat die Firewall denn ein Logfile, wo man sieht, welche Pakete rein- und rausgehen?
Wenn ja, siehst du dort die Anfrage (Ausgehend) und die Antwort (Eingehend) ?
Grüße,
Daniel
Als Firewall nutzen wir endian Community. Den Port 123 habe ich geöffnet.
Endian nimmt eine PPPoE Einwahl vor und ist somit ist die einzige Komponente, die zwischen Ubuntu und dem Internet steht.
Endian nimmt eine PPPoE Einwahl vor und ist somit ist die einzige Komponente, die zwischen Ubuntu und dem Internet steht.
- Was ist mit der Firewall des Linux-Systems?
- Wie genau ist der Port 123 offen? (Inbound, Outbound, TCP, UDP ?)
- Ist auf der Firewall eine Art von NAT (Source NAT, Destination NAT) konfiguriert?
Bitte beachte, dass das Paket folgenden Weg nimmt:
1. Dein Server sendet ein NTP Paket los (DNS benötigt)
2. Das Paket muss die Firewall des lokalen Linux Servers passieren
3. Das Paket wird an das Gateway (endian Comunity Firewall) weitergeleitet
4. Die Firewall muss das Paket akzeptieren und weiterleiten
5. (optional) Abhängig von der Konfiguration findet auf der Firewall evtl. eine Adressübersetzung (NAT) statt
So weit, so gut.
Ein sehr verbreiteter Fehler ist aber, das selbst wenn das Paket den Zielhost erfolgreich erreicht, die Antwort auch wieder den Weg zurück finden muss.
Viele Firewalls erkennen zwar, dass das eine Sitzung (Anfrage und Antwort) ist, aber wenn z.B. das NAT nur für ausgehende Pakete konfiguriert ist, schlägt das fehl.
Hat die Firewall denn ein Logfile, wo man sieht, welche Pakete rein- und rausgehen?
Wenn ja, siehst du dort die Anfrage (Ausgehend) und die Antwort (Eingehend) ?
Grüße,
Daniel
Was eventuell noch sein könnte, ist eine fiese Sache:
Ich hatte früher einen HP-Switch, einen 1810G, der hatte eine Funktion, die irgendwas mit DoS hieß, sobald die aktiv war, war kein NTP mehr möglich. Sobald der Switch erkannte, dass Quell- und Zielport identisch waren, hat das Ding die Pakete einfach weggeblockt.
Eventuell ist das gleiche auch bei deiner Firewall gegeben.
Ich hatte früher einen HP-Switch, einen 1810G, der hatte eine Funktion, die irgendwas mit DoS hieß, sobald die aktiv war, war kein NTP mehr möglich. Sobald der Switch erkannte, dass Quell- und Zielport identisch waren, hat das Ding die Pakete einfach weggeblockt.
Eventuell ist das gleiche auch bei deiner Firewall gegeben.
