Am 13. Mai 2020 10:42:12 MESZ schrieb Sven Velt <wampire@lusc.de>:
Moin!
Tom wrote:
habe auf einem Rechner freePBX (basierend auf centOS 7) am laufen. Der
Rechner hat eine Echtzeituhr.
Oh! Unabhängig von Deiner Frage würde mich noch (in einem extra Thread)
interessieren, was Du mit FreePBX machst. Ich such da nämlich auch noch
'ne Lösung für VoIP ;)
So wie ich Dich verstehe, ist das wirklich Hardware und keine VM, ok.
Wo finde ich Infos, um die Uhrzeit der RTC via NTP als Server auch für
anderen 'Geräten' im Netzwerk zur Verfügung zu stellen?
Das sind zwei Baustellen.
1. Real Time vs. Software-Clock
Eigentliche alle klassischen PCs haben eine batterie-gepufferte "real
time clock" (RTC). Diese Uhr wird im Wesentlichen dazu genutzt, dass
beim Booten die "Software/OS"-Uhr auf einen (einigermaßen) richtigen
Wert gesetzt werden kann. Und dies wird bereits vom BIOS gemacht und
kann(!) vom OS nochmal gemacht werden.
Beim Raspberry Pi (der hat keine RTC) ist die Uhrzeit beim Booten
erstmal 1970-01-01 00:00:00 UTC. Die gängigen Distributionen speichern
daher beim Shutdown die Uhrzeit in einer Datei, welche dann beim Booten
wieder gelesen wird, d.h. bei einem Reboot gehen normalerweise nur ein
paar Sekunden "verloren" - "fake-hwclock" aus dem Package "fake-hwclock"
(Debian/Raspbian).
So ähnlich schreiben PCs ihre Software-Clock entweder regelmäßig oder
beim Herunterfahren in die RTC und bringen sie somit auf den "neuesten"
Stand - das Command heißt "hwclock".
2. NTP - als Dienst/Protokoll
(x)ntp(d) bzw. dessen Vorgänger war AFAIK der erste Daemon, der eine
Zeitsynchronisation über das Netzwerk ermöglichte. Die Idee: Mindestens
ein Rechner hat die richtige Zeit (oder lokal als "richtig" definierte
Zeit) und alle anderen richten sich nach dieser Zeit aus.
Inzwischen gibt es neben dem klassischen "ntp" noch "chrony", "SecNTP",
"OpenNTPd", viele weitere und "systemd-timesyncd" (über den könnte ich
noch länger was schreiben 😝), von denen die ersten vier im
Wesentlichen ein ähnliches Feature-Set haben.
Ach ja, das Netz läuft 'autonom' und hat keine Verbindung zum Internet.
Schade, denn für "normale Menschen" (nein, ich bin keiner 🤓), reicht
die Genauigkeit DICKE aus. Meine Default-Server sind:
IPv4 und IPv6:
- ntp-GPS.n-ix.net
- ntp1.m-online.net
- ntp2.m-online.net
Nur IPv4:
- gps-1.m-online.net
- ntp1.meinberg.de
- ntp2.meinberg.de
und dazu noch die lokalen Server des RZ-Anbieters.
Zusätzlich würde ich die Zeit gerne via GPS (USB-Stick VK-172)
synchornisieren. Wo gibt es dazu Infos?
Dann brauchst Du den "gpsd" dazu, für die Debian'er: installiert Euch
auch gleich "gpsd-clients". Unter Debian hab ich folgendes konfiguriert:
,----[ /etc/default/gpsd ]-
| START_DAEMON="true"
| USBAUTO="true"
| DEVICES="/dev/gps0"
| GPSD_OPTIONS="-n"
`----
was im Endeffekt zu folgendem laufendem Prozess führt:
,----
| /usr/sbin/gpsd -n -P /run/gpsd/gpsd.pid /dev/gps0
`----
Unter CentOS muss man das wohl unter /etc/sysconfig/gpsd setzen.
Ggf. kann es bei Dir auch ein anderer Port als /dev/gps0 sein, z.B.
/dev/ttyACM0. Zusätzlich kann auch noch ein /dev/pps* auftauchen. Mit
meinem USB-Stick funktioniert es aber nicht und der müsste den gleichen
Chip haben, wie Dein genannter USB-Stick.
Wichtig: gpsmon muss Dir jetzt Deine Position und natürlich auch die
Uhrzeit anzeigen können.
Wenn das funktioniert, geht's an "/etc/ntp.conf":
,----[ /etc/ntp.conf ]-
| # GPS Serial data reference (NTP0)
| server 127.127.28.0 minpoll 4 maxpoll 4
| fudge 127.127.28.0 time1 +0.0630 refid GPS
`----
Das ist der Eintrag, der auch bei Dir funktionieren sollte. Er nutzt
Treiber 28 "SHM - shared memory"
(http://doc.ntp.org/4.2.6p5/drivers/driver28.html). Bei neueren
ntpd-Versionen wird Treiber 46 empfohlen ("GPSD_JSON").
Diese Konstruktion läuft bei mir schon sehr lange, ABER:
Der Eintrag "time1 +0.0630" bedeutet, dass die Zeit vom GPS-USB-Stick
*konstant* 63ms neben der korrekten Uhrzeit liegt. Blöderweise ist das
auch nicht konstant, sondern ändert sich mit allen möglichen Parametern
immer wieder. Wie man das rausbekommt? Man hängt einen weiteren GPS-
(oder DCF77-)Receiver seriell (nicht USB-seriell!) an den Rechner und
lässt es parallel laufen. Und vergleicht. Und wartet. Und vergleicht...
Und dann sieht's hoffentlich ungefähr so aus:
,----[ ntpq -c peer ]-
| remote refid st t when poll reach delay offset jitter
| ==============================================================================
| +GPSD_JSON(0) .GPSD. 0 l 55 64 377 0.000 -6.356 2.454
| *SHM(0) .GPS. 0 l 5 16 377 0.000 5.470 2.287
`----
Das wurde jetzt länger als gedacht. Aber nunja, wer Lust drauf hat, so
ein USB-Stick kostet keine 10€ und ist ein lustiges Bastelprojekt.
Ach ja, Raspberry Pi: Ihr macht Euch keine Freude, wenn ihr den
USB-Stick an einem RPi 1-3 per USB ansteckt. Da sind dann die
Laufzeitunterschiede zu groß, dass es sogar mal sein kann, dass der ntpd
gar keinen Sync mehr bekommt. Mit dem 4er sollte es besser sein, weil
USB anders angebunden ist, ich hab es noch nicht probiert. Oder für 1-3
kauft Euch ein GPS-Modul, welches man via GPIO anschließen kann. Dann
hat man aber immer noch die schlechte Anbindung des LAN-Interfaces.
Bye
Sven