Raspberry als Timeserver unter Stretch - wie einrichten?

  • Ich möchte für einige Geräte, die sich nur im Intranet bewegen sollen, die Zeit zur Verfügung stellen.

    Die Anleitungen, die ich dazu finde, verwenden alle ntp, ntpd bzw ntpdata. Nur wird das ja seit Raspbian Stretch nicht mehr verwendet, ntp ist nicht installiert und entsprechend findet sich auch die Datei ntp.conf nicht. Dagegen verwendet Stretch den systemd-timesyncd Service, um die Zeit zu aktualisieren.

    Nun könnte ich einfach den alten Anleitungen entsprechend ntp installieren und einrichten. Allerdings wird davon abgeraten, systemd-timesyncd und ntp parallel zu betreiben, klingt auch irgendwie logisch, der eine stellt die Uhr so, der andere so, geringe Zeitdifferenzen im sub-sec Bereich sorgen dafür, dass die Dienste ständige Gangungenauigkeiten feststellen und entsprechend häufig nach der Zeit fragen.

    Dummerweise arbeitet systemd-timesyncd offenbar nur als Client, ein Betrieb als Timeserver ist nicht möglich. Wie bekomme ich den Raspberry dazu, eine Zeit als Timeserver im Intranet zur Verfügung zu stellen? Muss ich dazu doch ntp installieren? Und muss ich dann systemd-timesyncd stilllegen, was möglicherweise anderen systemd-Services wie dem Logging nicht so gefällt?

  • Raspberry als Timeserver unter Stretch - wie einrichten?? Schau mal ob du hier fündig wirst!

  • Servus,

    Allerdings wird davon abgeraten, systemd-timesyncd und ntp parallel zu betreiben, klingt auch irgendwie logisch, der eine stellt die Uhr so, der andere so, geringe Zeitdifferenzen

    wo siehst Du da ein Problem?

    Wie RTFM bereits richtig anmerkte benötigst Du eh eine RTC ... somit ist der timesync-Client auf diesem Pi überflüssig und kann stillgelegt werden.

    Also ... RTC besorgen (Achtung! Nicht die DS13xx verwenden. Die sind zu ungenau. DS3231 oder DS3234) und einrichten, service stillegen und ntpd installieren udn aktivieren.

    cu,

    -ds-

  • Wenn in Deinem Intranet kein anderer Timeserver verfügbar ist...

    Der Raspi darf ins Internet und holt sich dort die Zeit, so wie PC und Router auch. Nur einige Geräte, hier explizit IP Kameras, dürfen nicht.

    Und leider ist der Router zu doof einen Timeserver anzubieten oder gezielt Port 123 für die Kameras freizugeben, und ein Austausch des Routers ist nicht möglich.

  • Hier wird die Einrichtung beschrieben:

    https://linuxconfig.org/how-to-setup-n…9-stretch-linux

    Hatte ich auch schon gefunden, aber da wird mit keinem Wort auf den systemd-timesyncd Service eingegangen und ob es da eventuell Probleme gibt. Andererseits habe ich an mehreren Stellen gefunden, dass man systemd-timesyncd nicht parallel zu ntp laufen lassen soll.

    Was ich bräuchte wäre systemd-timesyncd als Client der die Zeit holt und ntp als reinen Server, der die Zeit weitergibt, aber nicht selber holt. Und zu dieser Konfiguration finde ich nichts. Weil halt auch die Suche nach ntp + timeserver immer ntp in Verbindung mit dem Zugriff auf externe Timeserver bringt.

  • Da ich ja erklärter "Ablehner" von systemd bin:

    Warum machst du dir Gedanken über irgendwelche Koexistenzen zw. "Altem" und "Neuem" Zeug, wenn das "Alte" problemlos läuft und das "Neue" nur eingeschränkte Funktionalität aufweist?

    Installier den Zeitserver/Client so, wie es seit Äonen in der Linux-Welt gemacht wird und gut.

    (In der Zeit, die der Thread jetzt schon da ist und die vermutlich immer noch eine Lösung suchst, hättest du schon >50 Zeitserver aufsetzten können).

  • Was ich bräuchte wäre systemd-timesyncd als Client der die Zeit holt und ntp als reinen Server, der die Zeit weitergibt, aber nicht selber holt.

    Wenn Du einen Zeitserver betreibst, brauchst Du keinen weiteren Client, der die Zeit holt.

    Der Zeitserver braucht erstmal ein Zeitsignal, das er aus verschiedensten Quellen beziehen kann. Ob Atomuhr, Funkuhr, GPS, RTC, oder übergeordnetem Timeserver, der erhaltene Zeitstempel wird immer in den Kerneltimer eingetragen und korrigiert/bestimmt damit die Systemzeit, die der Zeitserver an seine Clients ausliefert.

    Also Denkfehler. Das betrifft wahrscheinlich auch Deine Ansicht, dass sich eine Webcam nicht so konfigurieren lässt, dass sie - mit Ausnahme eines Timeservers - keinen Zugang ins und vom Internet bekommt.


    Servus !!

    RTFM = Read The Factory Manual, oder so

  • Wenn Du einen Zeitserver betreibst, brauchst Du keinen weiteren Client, der die Zeit holt.

    Habe ich hier auch gemacht, zu Experimentierzwecken beziehe ich die Zeit über mehrere NTP-Server.

    Der erste zapft GPS an, liegt bei einer Genauigkeit von ca. +- 100μs (war schonmal besser),

    als Backup hat er

    a) einen NTP-Server der sich die Zeit über DCF77 (ca. +-1000μs) holt

    b) eine RTC, die eigentlich nur beim Starten gebraucht wird

    c) Zeitserver aus dem Internet-Pool "de.pool.ntp.org"

    Der DCF77-Server ist ein RPi aus der allerersten Generation,

    man kann sonst nicht mehr viel damit anfangen (256M Ram) aber das macht er zuverlässig seit mehreren Jahren (2013?)

    Alle meine Rechner hängen mittlerweile an diesen (GPS-)Tropf mit dem Backup auf den DCF77-Server.

    MfG

    Jürgen

  • Wenn Du einen Zeitserver betreibst, brauchst Du keinen weiteren Client, der die Zeit holt.

    Der systemd-timesyncd kann aber nur als Client arbeiten. Und den systemd-timesyncd werde ich nicht abschalten, nur weil jemand eine systemd-Allergie hat.

    Es wird ja wohl einen Grund geben, warum timesyncd direkt in systemd integriert wurde, und ich hab keine Lust, mir einen Arsch voll Probleme ranzuziehen, weil ich von System benötigte Dienste abschalte und dann andere Sachen nicht richtig funktionieren.

    Das betrifft wahrscheinlich auch Deine Ansicht, dass sich eine Webcam nicht so konfigurieren lässt, dass sie - mit Ausnahme eines Timeservers - keinen Zugang ins und vom Internet bekommt.

    Die Webcam hat keinen Zugang ins Internet, weil der Router aller Ports (TCP und UDP) dichtmacht. Der Router gibt nicht her, nur UDP123 aufzumachen, dazu ist er zu dumm. Und nur TCP zu sperren bringt nichts, weil diese Webcams es offenbar auch schaffen, über UDP zu streamen.

    Dann hat die Webcam halt Pech gehabt und steht bei 1970.

  • Der systemd-timesyncd kann aber nur als Client arbeiten. Und den systemd-timesyncd werde ich nicht abschalten, ...

    Wie ist jetzt (d. h. mit aktivem systemd-timesyncd) die Ausgabe von:

    Code
    sudo netstat -tulpena | grep -i 123

    ?

    BTW: Man könnte evtl. auch inetd als Zeitserver benutzen, wenn es Probleme zwischen ntpd und systemd-timesyncd gibt.

    EDIT:

    inetd kann nur "RFC 868 time protocol", d. h. lauscht auf dem Port 37.

    Code
    :~$ rdate -4pu 192.168.178.43
    Mon Oct  1 12:49:03 CEST 2018

    Da sollte man wissen, ob die Webcam das auch kann.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (1. Oktober 2018 um 12:50)

  • Es wird ja wohl einen Grund geben, warum timesyncd direkt in systemd integriert wurde

    Der Grund (für die Pi-Distribution) ist derselbe, wie für Windows-Home. Ein eigener Timesync Server wird vom normalen Pi Anwender nicht gebraucht und deshalb holt sich der Pi seine Systemzeit zunächst aus seinen eigenen Resourcen, wenn eine Netzwerkverbinung besteht, von einem (definierten) NTP Server.

    timesyncd ist übrigens "nur" ein systemd.service. Es wird u.A. von timedatectl gesteuert.

    Siehe <man timedatectl> <man systemd-timesyncd.service >

    Dass Dein Router alle (ausgehenden) Ports sperrt, glaube ich nicht. Sonst wären für die Pis ja auch kein Timeserver aus dem Internet erreichbar.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Dann hat die Webcam halt Pech gehabt und steht bei 1970.

    BTW: Du kannst einen deiner PIs auch zum weiterleiten der WEBcam-Zeitanfrage zu einem Zeitserver im Internet, benutzen. Z. B.:

    Code
    sudo sysctl -w net.ipv4.ip_forward=1
    sudo iptables -t nat -I PREROUTING 1 -p udp -i <Interface> --dport 123 -j DNAT --to-destination 130.133.1.10:123
    sudo iptables -t nat -I POSTROUTING 1 -o <Interface> -j MASQUERADE
    sudo tcpdump -vvveni <Interface> host 130.133.1.10
    rdate -4npu <IP-Adresse-PI>
    sudo iptables -nvx -L -t nat

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Dass Dein Router alle (ausgehenden) Ports sperrt, glaube ich nicht. Sonst wären für die Pis ja auch kein Timeserver aus dem Internet erreichbar.

    Die Filterregel ist so eingestellt, dass alle TCP und UDP Ports für die Kamera(s) mit fester IP blockiert werden. Und die Kamera hat seitdem auch keine neue Zeit bekommen, und der Zugriff auf die Kamera von ausserhalb geht nicht mehr. Da muss ich mal davon ausgehen, dass der Router hier tut, was er soll.

    Ja, der Speedport Hybrid ist Schrott, aber es ist halt der einzige Router, der DSL Hybrid kann. Zum Beispiel muss ich IP fest vergeben, weil er bei DHCP zwar schön IPs zuordnet, aber mitunter den Hostname vergisst. Dann kann ich die Kamera über ihre IP erreichen, aber nicht über den Hostname. Oder die Kamera wird als nicht vorhanden angezeigt, obwohl der Stream gerade läuft.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!