Probleme mit der Systemzeit im Zusammenhang mit LINBO und dem lmn-bionic-cloop

Clientpflege linbo
15

Thorsten mach das Problem doch nicht komplizierter als es ist.

Windows geht einfach davon aus, dass die Uhrzeit in der RTC in der lokalen Zeit abelegt ist. Ob das richtig oder falsch ist, darüber kann man sich streiten, auch wenn du das anders siehst.

Die meisten Systeme machen das schon richtig und erwarten UTC.

Mit ‚‚timedatectl set-timezone‘‘ setzt du auch nur den Offset im Schulserver. Intern wird weiterhin UTC verwendet. Diesen Wert holt sich Linbo nun ab und trägt ihn gegenwärtig in die RTC ein.
Das funktioniert für Windows optimal, Linux erwartet das nicht direkt. Wenn man nun 2 Betriebssysteme untersützen möchte, muss man eines von beiden anpassen.

Ich hoffe du hast die Problematik nun umfassen können. Ich glaube niemand hier betreibt sein Cluster mit Linbo Zeitsynchronisierten Diensten.

Der Vorschlag Linbo einfach +1 oder +2 Anzeigen zu lassen ist allerdings unschön. Besser wäre es wenn Linbo einfach in der Start.conf mitgegeben werden könnte ob die Zeit in die RTC in UTC oder in localtime geschrieben werden soll.
Am besten sollte die Uhrzeit in Linbo dann auch anzeigen UTC o. UTC+2 etc. pp.

Gruß,
Andreas

16

Hallo Till!

Ist das nicht genau das, was ich sagte: UTC auf allen Rechnern und angezeigt wird die localtime (das meinte ich mit +1h bzw. +2). Egal ob Linbo, Win, oder Linux.
Aber das muss doch gar nicht in die start.conf. Was sieht und interessiert den User wenn er vor der Kiste sitzt? Auch wenn der Linbo Bildschirm nur ein paar Sekunden im Normalfall zu sehen ist, genau die lokale Zeit. (usability) Also eher die timezone für Linbo ablegen.

Das mit der +1 und +2 war nicht gut formuliert. Besonders auffällig wenn hoffentlich bald die Sommerzeit aufgegeben wird. Sollte es dann zu dem Flickenteppich (wegen vor und nicht zurück oder nicht vor) kommen, dann wäre das Thema mittels timezone erledigt.

Falls die lmn-Installation dann noch in einer anderen Zeitzone läuft, wäre das auch egal. Denke dabei an die Anfrage aus Kanada von einer Schule die uns im Support erreichte.

Lieben Gruß

Thorsten

17

Das hatte ich gemacht und habe prompt die Vertrauensstellung der Win10-Clients verloren. Daraufhin habe ich meine Frage gepostet. Inzwischen habe ich den LMN-Server wieder auf UTC und dafür den Win10 UTC-Registry-Patch eingespielt. Nun kann ich mich wieder einloggen und die Zeiten stimmen ebenfalls unter bionic bzw. Win10.
Das Linbo -2h anzeigt ist unschön aber auch nicht dramatisch.

LG
Ralf

18

Das Problem ist was dein Clientsystem erwartet. Ich persönlich habe noch nicht getestet Windows die UTC Zeit erwarten zu lassen und weiß nicht welche Wechselwirkungen das haben kann.

In einer Umgebung mit ausschließlich Windows Client PCs (was einen großen Teil der mir bekannten LMN Installationen abdeckt) würde ich mich darüber hinaus wohler fühlen wenn die Uhrzeit direkt so abgelegt wird wie Sie das Betriebssystem erwartet.

19

Hi!

Linbo benutzt im Moment dieselbe Zeitzone wie der Server. Wenn das anders gemacht werden soll, bitte einen Issue erstellen.

VG, Thomas

1 „Gefällt mir“
20

Hallo,

schon bei meinem virtuellen Ubuntuclient habe ich die Beobachtung gemacht, dass er ab und an im bootsplash hängen bleibt. Heute habe ich nun das Image an einem realen Rechner ausprobiert und feststellen müssen, dass der Fehler hier permanent auftritt. Ich vermute, dass er mit dem oben zitierten Workaround zusammen hängt: Lösche ich den entsprechenden Eintrag in der rc.local, dann funktioniert es, allerdings hat der Client dann eine um 2 Stunden falsche Zeit, zumindest über einen unbestimmten Zeitraum hinweg.
Also muss eine andere Lösung her. Ich habe mir folgenden thread angeschaut:

https://ask.linuxmuster.net/t/ntp-service-status-inactive-dead/

bin aber nicht schlau geworden, was ich nun letztendlich tun soll.

Viele Grüße

Wilfried

21

Hallo Wilfried!

Der Vollständigkeitshalber: Welcher NTP-Client ist auf dem System installiert?

Beste Grüße

Thorsten

22

Nachtrag bzw. Frage:

Dual-Boot oder nur Linux-Client?
Kennst Du schon: https://wiki.archlinux.org/index.php/System_time

23

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

24

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

25

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

26

Hallo Wilfried,

poste mal deine /etc/chrony/chrony.conf

LG

Thorsten

27

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

28

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. :confused:

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

29

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

30

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

31

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

32

Nochmal: Linbo setzt die BIOS Zeit auf genau das, was auf dem Server eingestellt ist.

VG, Thomas

33

Hallo Thomas!

Auch auf die Gefahr hin das ich nerve, ich sage vorab schon einmal Entschuldigung dafür! :slight_smile:

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

34

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: no

Das 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.