Am 13. Mai 2020 10:42:12 MESZ schrieb Sven Velt <wampire@???>: >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@???
>--
>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!
>
(text/plain)