NTP via DHCP mit Network Manager

[Kolibri]

Hallo,

ich möchte gern den lokalen Router als Zeitserver unter Debian 12 (GNOME mit Network Manager) nutzen, statt dass jeder Debian-Rechner einzeln den NTP-Pool befragt. So weit ich weiß, reicht der network-manager die Information aber nicht an systemd-timesyncd weiter. Im Arch-Wiki wird ein Dispatcher-Skript beschrieben, dass die Konfiguration von systemd-timesyncd mit dem über DHCP ermittelten Zeitserver aktualisieren soll. Allerdings zeigt mir timedatectl timesync-status, dass auch nach Neustarts und Trennen der Verbindung immer noch der Debian-NTP-Pool verwendet wird.

Eine Konfiguration unter /etc/npt.conf wie bspw. in diesem Thread Ntpd: Uhrzeit wird nicht eingestellt gibt es bei mir nicht. Daher nehme ich mal an, dass keine weiteren NTP-Dienste laufen. Ich kann natürlich eine Konfiguration mit der IP-Adresse des Routers unter /etc/systemd/timesyncd.conf.d hinterlegen, aber dann muss die jedes Mal angepasst werden, wenn der Router in einem Netzwerk nicht unter dieser Adresse erreichbar ist.

Hat jemand eine Idee, wie sich das bewerkstelligen ließe?

[smutbert]

So ein Skript wie im Archwiki beschrieben wäre imho schon der richtige Weg und ich würde einfach versuchen herauszufinden woran es scheitert.

Liefert der DHCP-Server überhaupt die Information über den ntp-Server aus?
Hast du das Skript unverändert übernommen und auch ausführbar gemacht?
Wird mit dem Skript die »/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf« angelegt, wenn du dich über den network-manager verbindest und wenn was steht drin?

[rhHeini]

Bei Debian 12: schau mal in /etc/ntpsec nach einer ntp.conf.

[Kolibri]

Liefert der DHCP-Server überhaupt die Information über den ntp-Server aus?
Hast du das Skript unverändert übernommen und auch ausführbar gemacht?
Wird mit dem Skript die »/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf« angelegt, wenn du dich über den network-manager verbindest und wenn was steht drin?

Der Router sendet die Informationen aus und das zeigt mir auch der Network Manager:

Code: Alles auswählen

nmcli connection show 'Name des WLANs'
...
DHCP4.OPTION[4]:                        dhcp_server_identifier = IP-Adresse des Routers

Das Skript habe ich unverändert übernommen, root zu gewiesen (verwende kein sudo) und ausführbar gemacht:

Code: Alles auswählen

cd /etc/NetworkManager/dispatcher.d/
chown root:root 10-update-timesyncd.sh
chmod +x 10-update-timesyncd.sh

Code: Alles auswählen

ls -l /etc/NetworkManager/dispatcher.d/10-update-timesyncd.sh
-rwxr-xr-x 1 root root 529 14. Jan 13:14 /etc/NetworkManager/dispatcher.d/10-update-timesyncd.sh

Nach einem Neustart sehe ich aber bei systemctl status NetworkManager, dass er das Script nicht ausführen konnte mit "status code 2". Wenig überraschend wird auch unter /etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf nichts angelegt.

Bei Debian 12: schau mal in /etc/ntpsec nach einer ntp.conf.

Das Verzeichnis existiert bei mir nicht.

[rhHeini]

Bei Debian 12: schau mal in /etc/ntpsec nach einer ntp.conf.

Das Verzeichnis existiert bei mir nicht.

Dann hast Du ntp und ntpdate nicht installiert. Wäre der klassische Weg an systemd vorbei.

[JTH]

Ah, danke für den Thread. Mir war gar nicht bewusst, dass der NetworkManager (noch) keinen direkten Draht zum timesyncd hat.

Im Arch-Wiki wird ein Dispatcher-Skript beschrieben

Das verlinkte NM-Dispatcher-Skript hat allerdings ein paar Probleme, wie du ja schon beobachtet hast, Kolibri:

Wegen des benutzten Here-Docs ist das Skript relativ anfällig für Probleme nach Copy & Paste. Dort

Code: Alles auswählen

    cat <<-THE_END >"/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf"
        [Time]
        NTP=$DHCP4_NTP_SERVERS
    THE_END

muss nämlich unbedingt – will die Shell so – mit Tabs eingerückt werden. Im Arch-Wiki enthält das Skript da aber Leerzeichen. Das führt nach dem Kopieren dann zum

"status code 2"

Außerdem führt diese Zeile

Code: Alles auswählen

[ -n "$DHCP4_NTP_SERVERS" ] || exit

zu nem unnötigen Fehler im Journal, wenn per DHCP keine NTP-Infos reingekommen sind. (Was ja ein regulärer, unproblematischer Fall ist.)


Ich hab das Janze mal etwas copy-&-paste-freundlicher und anderweitig weniger problemanfällig gemacht:

Code: Alles auswählen

#!/bin/sh
set -eu

rm_conffile_or_exit()
{
	# Skip removing---and subsequent restarting---if there is no old conffile.
	[ -f "$conffile" ] || exit 0
	rm "$conffile"
}

# Some global events like "connectivity-change" don't come with a UUID. We are
# not interested in them, anyway.
[ "${CONNECTION_UUID-}" ] || exit 0

interface="$1"
action="$2"

confdir=/run/systemd/timesyncd.conf.d
conffile=${confdir}/${CONNECTION_UUID}.conf

case $action in
up | dhcp4-change | dhcp6-change)
	if [ "${DHCP4_NTP_SERVERS-}" ]; then
		mkdir -p "$confdir"
		printf '[Time]\nNTP=%s\n' "$DHCP4_NTP_SERVERS" >"$conffile"
	else
		rm_conffile_or_exit
	fi
	;;
down)
	rm_conffile_or_exit
	;;
*)
	exit 0
	;;
esac

# We will only get here and restart if we actually changed something.
systemctl try-reload-or-restart --no-block systemd-timesyncd.service

Wie gehabt abgespeichert als /etc/NetworkManager/dispatcher.d/10-update-timesyncd und ausführbar gemacht (besonders einschränken muss man die Leserechte nicht) – funktioniert einwandfrei

[Kolibri]

Das funktioniert in der Tat einwandfrei. Vielen Dank!

Macht es einen Unterschied, wenn man die Konfiguration nach /run/systemd/timesyncd.conf.d statt nach /etc/systemd/timesyncd.conf.d schreiben lässt?

Ich hatte mich etwas über die eigenartige Darstellung des Arch-Skriptes in nano gewundert, weil die unter Hälfte komplett als Kommentar gerendert wurde. Allerdings kenne ich mich mit der Shell-Syntax nicht aus, deswegen war mir die Einrückung über Tabs z. B. nicht geläufig.

[smutbert]

Danke auch von mir.

Macht es einen Unterschied, wenn man die Konfiguration nach /run/systemd/timesyncd.conf.d statt nach /etc/systemd/timesyncd.conf.d schreiben lässt?

Von der Funktion her ist es kein Unterschied, aber /run liegt normalerweise auf einem tmpfs (also nur im Hauptspeicher, was für eine Konfigurationsdatei, die zur Laufzeit erstellt und eventuell auch wieder gelöscht wird, ein recht guter Ort ist).

Mir gefällt das Skript von JTH und der Ort der Konfigurationsdatei eindeutig besser als das Original.

[JTH]

Das funktioniert in der Tat einwandfrei. Vielen Dank!

Top, danke für die zweite Rückmeldung.

Ich hab noch ein bisschen weitergebastelt, das Skript im Beitrag oben ist bearbeitet

Macht es einen Unterschied, wenn man die Konfiguration nach /run/systemd/timesyncd.conf.d statt nach /etc/systemd/timesyncd.conf.d schreiben lässt?

Im laufenden System macht das keinen Unterschied, nein.

Nach einem Reboot sind die Dateien unter /etc allerdings weiterhin da, während /run erstmal leer ist. Die Dateien unter /run sind also temporär.

Ich denke, das ist sinnvoll, falls mal etwas nicht sauber heruntergefahren oder umkonfiguriert wird. Auf diesem Weg hat man in dem Fall nicht für alle Ewigkeit eine alte, überholte NTP-Konfig unter /etc herumliegen; nach einem Reboot ist alles immer in einem „sauberen“ Zustand. (Das passt auch dazu, dass DHCP ja eben auch keine statische Konfiguration darstellt, sondern sich ändern und erneuern kann.)

Ich hatte mich etwas über die eigenartige Darstellung des Arch-Skriptes in nano gewundert, weil die unter Hälfte komplett als Kommentar gerendert wurde. Allerdings kenne ich mich mit der Shell-Syntax nicht aus, deswegen war mir die Einrückung über Tabs z. B. nicht geläufig.

Ah, das war mir nicht aufgefallen, mag am jeweiligen Editor liegen. Ist aber auch ein gemeiner Fehler gewesen für so ein Skript, was man ausdrücklich kopieren und einfügen soll.

[JTH]

Hehe, anscheinend liest jemand aus dem Arch-Wiki hier mit. Das oben beschriebene Problem mit den Leerzeichen statt Tabs wurde in dem Artikel heut Nachmittag korrigiert

[Kolibri]

Danke für die Erläuterung zum Ablegen von Konfigurationen unter /run/. Das hört sich vernünftig an und ich habe das so übernommen.

Lustig, dass das so schnell seinen Weg ins Arch-Wiki gefunden hat. Gut so.