Hallo Wilfried!
Der Vollständigkeitshalber: Welcher NTP-Client ist auf dem System installiert?
Beste Grüße
Thorsten
Nachtrag bzw. Frage:
Dual-Boot oder nur Linux-Client?
Kennst Du schon: https://wiki.archlinux.org/index.php/System_time
Hallo Thorsten,
es geht nur um den Linux-Client, und was den NTP-Client angeht, scheint von allem etwas dabei zu sein. Allerdings kann ich das Problem insgesamt etwas relativieren, weil die Zeit - mal früher, mal später - korrigiert wird.
Ich habe mal die Situation vor der Korrektur überprüft und habe folgende Ausgaben bekommen:
root@r241-virtual2:/home/linuxadmin# service ntp status
● ntp.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
root@r241-virtual2:/home/linuxadmin# systemctl status chrony
● chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: e
Active: active (running) since Fri 2020-06-05 13:05:03 CEST; 2min 9s ago
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 1162 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (code=
Process: 1135 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OP
Main PID: 1160 (chronyd)
Tasks: 1 (limit: 4681)
CGroup: /system.slice/chrony.service
└─1160 /usr/sbin/chronyd
Jun 05 13:05:03 r241-virtual2 systemd[1]: Starting chrony, an NTP client/server.
root@r241-virtual2:/home/linuxadmin# timedatectl status
Local time: Fr 2020-06-05 13:13:19 CEST
Universal time: Fr 2020-06-05 11:13:19 UTC
RTC time: Fr 2020-06-05 11:13:19
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
systemd-timesyncd.service active: yes
RTC in local TZ: no
Irgendwann korrigiert chrony die Zeit:
Jun 5 11:35:14 r241-virtual2 systemd[1]: Starting Time & Date Service...
Jun 5 11:35:14 r241-virtual2 dbus-daemon[975]: [system] Successfully activated service 'org.freedesktop.timedate1'
Jun 5 11:35:14 r241-virtual2 systemd[1]: Started Time & Date Service.
Jun 5 09:36:32 r241-virtual2 chronyd[1117]: Selected source 10.16.1.1
Jun 5 09:36:32 r241-virtual2 chronyd[1117]: System clock wrong by -7199.677617 seconds, adjustment started
Jun 5 09:36:32 r241-virtual2 chronyd[1117]: System clock was stepped by -7199.677617 seconds
oder
Jun 5 12:02:35 r241-virtual2 Scratch2.desktop[2774]: adobe-air: Done
Jun 5 10:03:30 r241-virtual2 chronyd[1113]: Selected source 10.16.1.1
Jun 5 10:03:30 r241-virtual2 chronyd[1113]: System clock wrong by -7200.914989 seconds, adjustment started
Jun 5 10:03:30 r241-virtual2 chronyd[1113]: System clock was stepped by -7200.914989 seconds
und dann sehen die Ausgaben so aus:
root@r241-virtual2:/home/linuxadmin# service ntp status
● ntp.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
root@r241-virtual2:/home/linuxadmin# systemctl status chrony
● chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-06-05 12:00:17 CEST; 1h 39min left
Docs: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Process: 1115 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
Process: 1088 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS (code=exited, status=0/SUCCESS)
Main PID: 1113 (chronyd)
Tasks: 1 (limit: 4681)
CGroup: /system.slice/chrony.service
└─1113 /usr/sbin/chronyd
Jun 05 12:00:16 r241-virtual2 systemd[1]: Starting chrony, an NTP client/server...
Jun 05 12:00:17 r241-virtual2 chronyd[1113]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYN
Jun 05 12:00:17 r241-virtual2 chronyd[1113]: Frequency 5.802 +/- 0.013 ppm read from /var/lib/chrony/chrony.drift
Jun 05 12:00:17 r241-virtual2 systemd[1]: Started chrony, an NTP client/server.
Jun 05 12:03:31 r241-virtual2 chronyd[1113]: Selected source 10.16.1.1
Jun 05 12:03:31 r241-virtual2 chronyd[1113]: System clock wrong by -7200.914989 seconds, adjustment started
Jun 05 10:03:30 r241-virtual2 chronyd[1113]: System clock was stepped by -7200.914989 seconds
root@r241-virtual2:/home/linuxadmin# timedatectl status
Local time: Fr 2020-06-05 10:23:04 CEST
Universal time: Fr 2020-06-05 08:23:04 UTC
RTC time: Fr 2020-06-05 08:23:05
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no
Da bei uns die meisten Rechner automatisch hochgefahren werden, wird das Problem nicht groß auffallen. Aber bei der Arbeit am Default-cloop kann es schon ärgerlich sein, wenn aufgrund des Zeitunterschiedes zu Beginn z. B. der Domänenbeitritt Schwierigkeiten macht.
Viele Grüße
Wilfried
Hallo,
das Problem ist doch größer als gedacht und sollte gelöst werden:
Meldet man sich als Netzwerkuser an, bevor der Zeitunterschied von chrony korrigiert worden ist, dann fehlen Home- und Tauschverzeichnisse.
Viele Grüße
Wilfried
Hallo Wilfried,
das Problem ist doch größer als gedacht und sollte gelöst werden:
Meldet man sich als Netzwerkuser an, bevor der Zeitunterschied von
chrony korrigiert worden ist, dann fehlen Home- und Tauschverzeichnisse.
ich denke das Problem tritt bei mir nicht auf, weil ich dafür gesorgt
habe, dass linbo die Systemzeit (BIOS Uhr) korrekt setzt.
Leider macht linbo das nicht immer,weil der Dienst (Zeitserver) auf dem
Server immer mal „wakelt“.
Schau mal in diese Tread:
LG
Holger
Hallo Wilfried,
poste mal deine /etc/chrony/chrony.conf
LG
Thorsten
Hallo Thorsten,
bitte:
# /etc/chrony/chrony.conf
#
# thomas@linuxmuster.net
# 20181017
#
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.
# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: #104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2
server server.linuxmuster.lan
# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys
# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift
# Uncomment the following line to turn logging on.
#log tracking measurements statistics
# Log files location.
logdir /var/log/chrony
# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync
# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3
@Holger: In linbo startet die Zeit auch ganz kurz falsch, wird aber sofort korrigiert.
Viele Grüße
Wilfried
Hallo Wilfried,
das ist das selbe Problem, das ich oben beschrieben habe. Linbo schreibt die Localtime in die RTC; für Windows ist das genau richtig, aber für Linux falsch. Da Linux die Zeit nicht direkt beim Systemstart aktualisiert, sondern nach einer zufälligen Zeit, funktioniert das SSO nicht, also keine Shares und keine Anmeldung am Proxy.
Solange das mit der Zeit nicht funktioniert, bleiben die Computer bei uns erstmal ungenutzt. 
Ich hatte einen pull-request mit einer Korrektur gemacht, glaube aber, dass aktuell noch geprüft werden soll, wie Win10 mit UTC läuft (funktioniert mit einem Reg-Patch). In unserem aktuellen 7er-System wird durch linbo noch die Localtime geschrieben.
Ich würde das zum Testen gerne auf UTC umstellen, weiß aber nicht, woher sich der Server die Linbo-Umgebung holt - ich vermute, dass die vorkompiliert ist; ich konnte die Datei auf dem Server nicht finden.
Vielleicht wäre es sinnvoll, wenn Linbo die Systemzeit nicht direkt beim System-Init in die RTC schreibt, sondern vor/beim Start eines Betriebssystems und die Zeit dann Systemabhängig setzt. Das könnte man auf dem Server über die Gruppen vorgeben.
Übergangsweise schlage ich vor, die Code-Zeile, die die RTC schreibt auszukommentieren und den Nutzer darauf hinzuweisen, dass sich das gestartete OS um die korrekte Zeit kümmern muss. Man muss dann nur bei Inbetriebnahme eines Computers auf die korrekte Zeit achten, aber danach hätte man sowohl für Win10, als auch für Linux immer die korrekte Zeit.
Viele Grüße
Fabian
Hallo Fabian,
das wundert mich: ich meine linbo schreibt UTC (wie es alle machen …
außer Windows) un ddie Einigung war, dass man windows per regeintrag auf
UTC umbiegt.
Genau so habe ich es bei mir in der SChule: linux macht das richtig,
windows hat einen Regeintrag bekommen und tut jetzt auch. linbo schreibt
utc: alles fein bei mir jetzt.
Schau mal hier:
LG
Holger
Moin!
Heißt das jetzt, dass es so wie es jetzt implementiert ist (Linbo-Client ruft hwclock --systohc auf), bleiben soll? Ich habe halt die Befürchtung, wenn ich das wieder rausnehme, melden sich zig andere, bei denen die Zeit nicht stimmt.
Das sollte jetzt mal endgültig festgelegt werden.
Ich habe es oben schon geschrieben, der Linbo-Client nutzt dieselbe timezone wie der Server. Ändert man die TZ auf dem Server und ruft anschließend update-linbofs auf, hat man auf dem Client auch die TZ geändert.
VG, Thomas
Hallo Thomas,
Einigung war, dass man windows per regeintrag auf UTC umbiegt.Heißt das jetzt, dass es so wie es jetzt implementiert ist (Linbo-Client
ruft hwclock --systohc auf), bleiben soll? Ich habe halt die
Befürchtung, wenn ich das wieder rausnehme, melden sich zig andere, bei
ich meine (meine private Meinung: ich bin kein Entwickler), dass die
Sache so läuft:
Server steht auf UTC
Linbo setzt die BIOS Zeit beim starten auf dem Client auf UTC
Windows wird per regpatch auf UTC umgemünzt.
Dann sollte das doch für alle stimmen, oder?
Oder hab ich da was nicht verstanden?
LG
Holger
Nochmal: Linbo setzt die BIOS Zeit auf genau das, was auf dem Server eingestellt ist.
VG, Thomas
Hallo Thomas!
Auch auf die Gefahr hin das ich nerve, ich sage vorab schon einmal Entschuldigung dafür! 
Ich finde die Idee von
sehr charmant. Damit ließe sich das für alle Zeit einfach lösen, wie ich finde. Kein Reg-Patch, oder sonst was, hier wird jeder bedient wie er es mag. (gemeint ist natürlich das BS; steht so auch in PullRequest )
nur meine 1/2 Cent
lieben Gruß und bleib gesund
Thorsten
Hallo zusammen,
Ich habe das nicht verstanden:
was heißt denn das genau?
root@server(Humboldt):~# timedatectl status
Local time: Mi 2020-06-10 22:05:33 CEST
Universal time: Mi 2020-06-10 20:05:33 UTC
RTC time: Mi 2020-06-10 20:05:32
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: noDas sagt mir doch: meine Hardware läuft in UTC, nicht in lokaler Zeit.
Also, wenn ich das wörtlich nehme, dann setzt LINBO auf meinem Client erstmal die BIOS-Zeit (RTC) auch auf UTC.
Für die LinuxClients wäre das jetzt bei mir Stand der Dinge perfekt: dem muss man nur beibringen, dass die RTC auf UTC steht, wie üblich und dass die Zeitzone 2h daneben liegt. Übrigens würde ich chrony und ntp auf den clients verbannen und überall die systemd - timesyncd Variante verwenden. Nur der Einheit und des supports hier wegen.
Für die WIndowsCLients gäbe es zwei Möglichkeiten:
oder (so steht es doch alternativ im github issue):
- wenn windows gestartet wird, dann patch LINBO die BIOS-Zeit (RTC) eben auf die localtime.
Vermutlich habe ich jetzt auch nur umformuliert, was @fkretzschmar und @MachtDochNix auch vorgeschlagen haben.
Für diese Alternative wäre ich auch.
Hallo Thomas,
nach dem Linbo-Update stimmt bei meinem virtuellen Client die Zeit von Beginn an. Danke für deine Arbeit.
Viele Grüße
Wilfried
Hi,
ich hab das in einen anderen Thread mit reingepackt … seit dem Einspielen von dem neuen Linbo komme ich auch mit Linux nicht mehr durch SSO ins Netz.
Der Befehl timedatectl status zeigt bei mir auf dem Server 3x die gleiche Zeit an, und die ist um 2 Stunden hinten.
Muss ich da die localtime um 2 vorstellen (siehen Bild Holger)? Wenn ja, wie, wo …
VG
Wolfgang
Hallo Wolfgang,
funktioniert jetzt alles bei mir - kein Trost für dich …
Hast du SSO in der OPENsense getestet?
Ich habe auf dem Linuxclient die Proxy-Einstellungen systemweit unter ‚Einstellungen > Netzwerk > Manuelle Proxy-Einstellungen‘ gemacht. Für realistische Tests muss dann auch der Client, sofern er zuvor eingetragen war, aus der ‚NoProyx-Gruppe‘ raus.
Viele Grüße
Wilfried
Hi,
nö - tröstet nicht 
Ich werde für Montag jetzt das „Notprogramm“ anlaufen lassen und alle Rechner erst mal in die noProxy Gruppe schieben. Da muss ich allerdings erst mal sehen, wo bzw. wann beim Linux-Client die Proxies gesetzt werden. Beim Windows-Client scheint es zu funktionieren - teste ich heute/morgen noch.
Ich bin sicher, dass es mit dem Zeitproblem zusammenhängt. Ich hab da einen Verdacht, muss das aber morgen noch checken …
VG
Wolfgang
Hi,
gibt es belastbare Aussagen über maximal erlaubte Zeitabweichungen?
Kerberos lässt bis zu 5min zu (?)
Mein Problem ist, dass mein Schulträger kein ntp durch die Firewall lässt, und ich das quasi „hintenrum“ irgendwie ins System bringen muss …
VG
Wolfgang