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 -- Leukämie → http://de.wikipedia.org/wiki/Leuk%C3%A4mie Heilung → http://de.wikipedia.org/wiki/Knochenmark#Knochenmarkspende Typisierung → https://akb.de/online-registrierung/ https://zkrd.de/de/adressen/ Fragen? → sven@velt.de -- Mailing-Liste der Linux User Schwabach (LUSC) e.V. Vor und beim Posten bitte => http://lusc.de/List-Netiquette <= und => http://lusc.de/List-Howto <= beachten. Danke!