Liegt es vielleicht daran die OPNsense meldet diese Fehler:
als Zeitserver ist de.pool.ntp.org eingetragen.
LG Pascal
LG Pascal
Hallo Pascal,
welche Zeitzone zeigen Server und Linbo-Client mit date an? Muss
eigentlich gleich sein. update-linbofs packt /etc/localtime des Servers
in linbofs ein, von dem her …
VG, Thomas
root@server:/# date
Sa 15. Feb 18:43:42 CET 2020
root@server:/# linbo-ssh 10.16.4.5
~ # date
Sat Feb 15 17:43:52 UTC 2020
~ #
also soll ich auf dem server update-linbofs laufen lassen und dann den rechner neustarten.
Muss ich dann mit einem Stick die Rechner neu mit linbo versorgen?
Lg Pascal
Habe update-linbofs ausgeführt dann einen Rechner neu gestartet er hat auch 2 mal neugestartet aber keine veränderung der Zeit
Lg Pascal
Hallo Thomas,
ich habe noch ein anderes Problem entdeckt ich glaube die der Server bekommt nicht die richtige Zeit wenn ich mit ntpd -nq -p 10.16.1.1 die zeit vom Linbo synce kommt diese ausgabe + CET und UTC sind falsch die aktuelle Uhreit ist 22:17 Uhr
~ # ntpd -nq -p 10.16.1.1
ntpd: reply from 10.16.1.1: peer is unsynced
ntpd: reply from 10.16.1.1: peer is unsynced
ntpd: reply from 10.16.1.1: peer is unsynced
ntpd: reply from 10.16.1.1: peer is unsynced
ntpd: reply from 10.16.1.1: peer is unsynced
ntpd: reply from 10.16.1.1: peer is unsynced
Alarm clock
~ # date
Sat Feb 15 21:17:40 UTC 2020
~ # TZ=CET date
Sat Feb 15 21:17:57 CET 2020
~ #
oder was bedeutet peer ist unsynced?
Lg Pascal
Hallo Pascal,
die Zeitzone auf Server und Linbo-Client sollte identisch sein. Keine
Ahnung, warum das bei dir nicht so ist.
Überprüf mal folgendes auf dem Server:
❯ ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Okt 4 06:14 /etc/localtime ->
/usr/share/zoneinfo/Europe/Berlin
Dann lass dir mal die md5-Summe von /usr/share/zoneinfo/Europe/Berlin
ausgeben:
md5sum /usr/share/zoneinfo/Europe/Berlin
2d53644b5272b0826ad62a3317a66bb9 /usr/share/zoneinfo/Europe/Berlin
Auf dem Linbo-Client dasselbe mit /etc/localtime:
md5sum /etc/localtime
2d53644b5272b0826ad62a3317a66bb9 /etc/localtime
Die Summen sollten übereinstimmen.
Falls nicht, kannst du auf dem Server mit update-linbofs neue
Linbo-Bootfiles erzeugen und danach den Linbo-Client neu starten.
Aber eigentlich wird das ja bei der Paketinstallation gemacht.
Bzgl. peer unsynced, checke mal ob der Server die Zeit erfolgreich von
der Firewall beziehen kann.
VG, Thomas
1 „Gefällt mir“
Hallo Thomas,
root@server:~# ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Feb 15 22:03 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin
root@server:~# md5sum /usr/share/zoneinfo/Europe/Berlin
2d53644b5272b0826ad62a3317a66bb9 /usr/share/zoneinfo/Europe/Berlin
root@server:~# linbo-ssh 10.16.4.7
~ # ls -l /etc/localtime
ls: /etc/localtime: No such file or directory
~ # md5sum /etc/localtime
md5sum: can't open '/etc/localtime': No such file or directory
~ #
Den Pfad gibt es auf dem linbo Client nicht ?
Ich habe mal den Server die Zeit mit der FW neu syncen lassen und im der Firewall den Zeitserver auf LAN und auf WAN gestellt der war vorher nur auf LAN das ist die Ausgabe:
root@server:~# ntpd -nq 10.16.1.254
16 Feb 12:28:45 ntpd[18340]: ntpd 4.2.8p10@1.3728-o (1): Starting
16 Feb 12:28:45 ntpd[18340]: Command line: ntpd -nq 10.16.1.254
16 Feb 12:28:45 ntpd[18340]: proto: precision = 0.100 usec (-23)
16 Feb 12:28:45 ntpd[18340]: Listen and drop on 0 v6wildcard [::]:123
16 Feb 12:28:45 ntpd[18340]: Listen and drop on 1 v4wildcard 0.0.0.0:123
16 Feb 12:28:45 ntpd[18340]: Listen normally on 2 lo 127.0.0.1:123
16 Feb 12:28:45 ntpd[18340]: Listen normally on 3 eth0 10.16.1.1:123
16 Feb 12:28:45 ntpd[18340]: Listen normally on 4 lo [::1]:123
16 Feb 12:28:45 ntpd[18340]: Listen normally on 5 eth0 [fe80::215:5dff:feb2:191e%2]:123
16 Feb 12:28:45 ntpd[18340]: Listening on routing socket on fd #22 for interface updates
16 Feb 12:28:48 ntpd[18340]: Soliciting pool server 194.102.255.19
16 Feb 12:28:49 ntpd[18340]: Soliciting pool server 162.159.200.1
16 Feb 12:28:50 ntpd[18340]: Soliciting pool server 78.96.7.25
16 Feb 12:28:51 ntpd[18340]: Soliciting pool server 162.159.200.123
16 Feb 12:28:52 ntpd[18340]: ntpd: time slew +0.000261 s
ntpd: time slew +0.000261s
root@server:~# date
So 16. Feb 12:28:57 CET 2020
root@server:~# TZ=UTC date
So 16. Feb 11:29:12 UTC 2020
root@server:~#
Dann habe ich nochmal update-linbofs ausgeführt und einen linbo client neu gestartet und siehe da:
root@server:~# linbo-ssh 10.16.4.5
~ # date
Sun Feb 16 11:44:23 UTC 2020
~ # reboot
Connection to 10.16.4.5 closed by remote host.
Connection to 10.16.4.5 closed.
root@server:~# linbo-ssh 10.16.4.5
~ # date
Sun Feb 16 12:46:53 CET 2020
~ #
aufeinmal geht es jetzt gibt es auch den Pfad /etc/localtime und die checksumme stimmt auch komisch warum ich zwei mal update-linbofs laufen lassen musste.
Lg Pascal
Hier stimmt die Zeit von LINBO und Server überein – dennoch stelle ich fest, dass der LINBO-Start lange dauert. Hier zwei Screenshots, die die Stellen zeigen, wo es lange dauert, bis es weitergeht:
Da dauert es sicher 20 Sekunden. Und anschließend bei der Meldung: Syncinc time ... dauert es auch nochmal ein paar Sekunden, bis es weitergeht. Ist das bei euch auch so?
Hallo Michael 
ja bei mir dauert es auch sehr lange.
Lg Pascal
Hallo Pascal,
die Frage „ist das bei Euch aus so“ kam von Michael.
Gruß
Alois
Hallo,
das habe ich auch gemacht: die md5summen stimmen überein.
Trotzdem steht der letzte Mist am Client als Zeit im BIOS.
z.B. Heute Morgen um 7:30 Uhr sagte linbo es sei 14:46
Ich hab das nun genauer untersucht:
der Server hat 10.16.1.254 als ntp eingetragen und holt auch brav die
Zeit von der OPNsense.
Der Client hingegen beendet ein:
ntpd -nq -p 10.16.1.1
nur mit der Meldung
Alarm Clock
sonst nichts: Zeit bleibt auch grottenfalsch.
Wenn ich am Client aber
ntpd -nq -p 10.16.1.254
mache, dann kommt neben
Alarm Clock
noch die Meldung, dass die Zeit gesetzt wurde: was auch stimmt.
Deswegen meine Frage: wie kann ich dem Server sagen, dass er bitte ntp
Anfragen aus Grün beantwortet?
LG
Holger
Hallo Holger,
musst da da nicht einfach den Port 123 für ntp freigeben?
Gruß
Alois
ja so musste ich das auch einstellen damit der Zeit-Sync vom Server auf die Firewall klappt.
ich habe das deswegen für das gesamte lan eingetragen weil ich die FW in Windows auch nochmal als Zeitserver drinne habe.
Lg Pascal
… nur als Tipp: Unter OPNSense gibt es unter Firewall --> Regeln --> Fließend (floating rules) auch die Möglichkeit, so einen Port gleich für alle Schnittstellen (und nicht nur für grün/LAN) freizugeben.
Läuft der ntp service? Wenn er läuft, beantwortet er auch Anfragen.
VG, Thomas
Moinsen!
Linbo 2.3.57 forkt den time sync in den Hintergrund, sodass dadurch keine Startverzögerung mehr auftritt. Bitte mal testen.
VG, Thomas
Hallo!
Ich möchte mal darauf aufmerksam machen, dass für …
… Clients der Server (AD) der Zeitserver ist.
… der Server holt sich seine Zeit von der Firewall.
… die Firewall holt sie sich von einem externen Zeitserver.
So ist der Standardaufbau bei der v7.
Beste Grüße
Thorsten
Hallo Thomas,
Deswegen meine Frage: wie kann ich dem Server sagen, dass er bitte ntp Anfragen aus Grün beantwortet?Läuft der ntp service? Wenn er läuft, beantwortet er auch Anfragen.
ja, der läuft: das hatte ich vorher schon getestet:
systemctl status ntp.service
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor
preset: enab
Active: inactive (dead)
Docs: man:ntpd(8)
… hoppla: jetzt ist der mir doch glatt gestorben … na dann starte ich
ihn mal und beobachte…
LG
Holger
Hallo ihr drei,
ihr habt meinen Post nicht richtig gelesen: es geht nicht um die
OPNsense: es ging um den Server.
Der ist (wie Thorsten weiter unten schreibt) der Zeitserver für das Netz
und bekommt selbst die Zeit von der OPNsense.
Das geht auch.
… anscheinend war bei mir nur der ntp auf dem server gestorben.
Ein
systemctl start ntp.service
hat ihn wieder gestartet …und jetzt merke ich auch was ihr meint mit
"linbo braucht 15sekunden beim timesync: das ging bei mir mit totem ntp
auf dem Server schneller …
Jetzt mach ich also mal 2.3.57 drauf und dann mal schauen 
LG
Holger
Hallo Thomas,
Linbo 2.3.57 forkt den time sync in den Hintergrund, sodass dadurch
keine Startverzögerung mehr auftritt. Bitte mal testen.
bin dran.
2.3.57 ist nun in der Schule installiert und wird die nächsten 2 Tage
getestet: ich melde dann zurück, ob es irgend wo klemmt (ist aber lange
her, dass ein linboupdate mehr Probleme als den einmaligen neustart beim
ersten start verursacht hätte).
Erst mal kann ich sagen: der boot geht wieder schenller und systemzeit
unter linbo und Zeitzone stimmen.
LG
Holger