Zeit auf den LT-Clients stimmt nicht überall

[Rüdiger Kupper]

Das macht sich allerdings nur an der Anzeige auf dem Login-Screen bemerkbar. Später arbeiten die User ja auf dem Server, und dort gehen die Uhren (hoffentlich) richtig.

[Rüdiger Kupper]

Eine Auswirkung scheint #126 zu sein.

[Rüdiger Kupper]

Auf dem paedml führt ntpdate zu folgender Ausgabe:

# sudo ntpdate
20 Sep 00:27:49 ntpdate[8808]: no servers can be used, exiting

Als Server sind die belwue-Server eingetragen. Wieso können die nicht erreicht werden?

[Rüdiger Kupper]

Ist vielleicht der NTP-Port nicht offen?

[Rüdiger Kupper]

Also, erstmal: Mein Aufruf

# sudo ntpdate
20 Sep 00:27:49 ntpdate[8808]: no servers can be used, exiting

War falsch, denn der Befehl ntpdate verwendet gar nicht die Konfiguration in /etc/ntpd/ntpd.conf. Dafür gibt es noch einen zweiten Befehl namens ntpdate-debian. (Sehr sinnig.)
Also muss es heißen:

# sudo ntpdate-debian

oder man muss den Server dahinter angeben:

# sudo ntpdate 10.32.1.1

[Rüdiger Kupper]

Dann: Die Clients können sich die Zeit nicht von ihren jeweiligen Servern besorgen, weil sie darauf nicht zugreifen können:

root@LTClient128-01:~# ntpdate 10.32.1.245
20 Sep 17:33:24 ntpdate[7386]: no server suitable for synchronization found

Auf den paedml können sie hingegen zugreifen:

root@LTClient128-01:~# ntpdate 10.32.1.1
20 Sep 13:26:06 ntpdate[7429]: step time server 10.32.1.1 offset -14880.864347 sec

@bau

Woran liegt das? Eine Firewall-Regel?

provisorische Lösung

Ich habe erstmal in die lts.conf als Zeitserver für alle den paedml eingetragen. Jetzt stimmen die Zeiten nach dem Hochfahren der Clients. Damit sollten auch die Abmelde- und Herunterfahrskripte wieder funktionieren (#126).

[bau]

ltsp126:/etc/openntpd# ntpdate -q 10.32.1.249
server 10.32.1.249, stratum 3, offset 0.000015, delay 0.02568
20 Sep 13:52:12 ntpdate[21292]: adjust time server 10.32.1.249 offset 0.000015 sec
ltsp126:/etc/openntpd# ntpdate -q 10.32.1.248
server 10.32.1.248, stratum 16, offset 0.055718, delay 0.02594
20 Sep 13:52:23 ntpdate[21293]: no server suitable for synchronization found
ltsp126:/etc/openntpd# ntpdate -q 10.32.1.250
server 10.32.1.250, stratum 3, offset 0.096803, delay 0.02597
20 Sep 13:52:35 ntpdate[21294]: adjust time server 10.32.1.250 offset 0.096803 sec
ltsp126:/etc/openntpd# ntpdate -q 10.32.1.247
server 10.32.1.247, stratum 3, offset 0.079927, delay 0.02625
20 Sep 13:52:47 ntpdate[21295]: adjust time server 10.32.1.247 offset 0.079927 sec
ltsp126:/etc/openntpd# ntpdate -q 10.32.1.246
server 10.32.1.246, stratum 3, offset 0.098613, delay 0.02582
20 Sep 13:53:06 ntpdate[21296]: adjust time server 10.32.1.246 offset 0.098613 sec
ltsp126:/etc/openntpd# ntpdate -q 10.32.1.245
server 10.32.1.245, stratum 3, offset 0.074284, delay 0.02898
20 Sep 13:53:16 ntpdate[21297]: adjust time server 10.32.1.245 offset 0.074284 sec
ltsp126:/etc/openntpd# ntpdate -q 10.32.1.244
server 10.32.1.244, stratum 3, offset 0.124843, delay 0.02580
20 Sep 13:53:27 ntpdate[21298]: adjust time server 10.32.1.244 offset 0.124843 sec

Komisch, nur der LTSP118 kann keine Antwort geben???
Allenfalls die Firewall kann das blocken
Ich würde das Provisorium so belassen, es ist eigentlich gut so!

[Rüdiger Kupper]

Replying to bau:

Komisch, nur der LTSP118 kann keine Antwort geben???

Lokal von den Clients aus kann man überhaupt keinen der Server erreichen (ich kann mich ja neuerdings per ssh auf einem laufenden Client einloggen und sowas probieren) -- siehe comment:5.

Allenfalls die Firewall kann das blocken

Ja, wie würde man denn für die Clients den Zugriff auf die Server freischalten? Ich hab so eine dunkle Vermutung, dass uns das auch noch woanders reinfunkt, vielleicht bei der Grafikübertragung?

Ich würde das Provisorium so belassen, es ist eigentlich gut so!

Sicher, der paedml wird wohl kaum davon überlastet werden, dass die Clients beim Hochfahren einmal die Zeit abfragen. Außer vielleicht, sämtliche Clients werden auf einmal eingeschaltet (Thema LtspEtherwake oder Klasse-kommt-in-den-Computerraum)...

[bau]

OK, auf den LTSP-Servern

  iptables -L

z.B. auf LTSP118

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Nanny all -- anywhere anywhere

Chain Nanny (1 references)
target prot opt source destination

Das sieht eigentlich so aus, als ob gar keine Firewall-Regel eingetragen wäre!
Dann gilt die policy: ACCEPT (wenn keine Regel zutrifft)

Oder kann es sein, dass Nanny da ein Wörtchen mitredet?

[Rüdiger Kupper]

Kann es vielleicht an den Clients liegen? Sind da vielleicht die ausgehenden Ports zu?

Verwandtes Problem

#156

[Rüdiger Kupper]

Das Thema dieses Tickets ist gefixt. Weiteres zum Netzzugriff der Clients bitte unter #156.