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

Clientpflege linbo
61

Ok … in Zukunft.
Kam nur ne Warnung auf der Seite, ob man nicht lieber „edit macht“, als sich selbst zu antworten …

62

Hallo Holger,

Es bedeutet, dass Linbo nach wie vor die Zeit auf dem Client wie die Serverzeit setzt aber nicht mehr mit der hwclock synchronisiert. Wurde hier ja so mehrfach vorgeschlagen.

VG, Thomas

63

Hallo Thomas,

dass linbo beim Starten die lokale BIOS Zeit auf UTC setzt

Es bedeutet, dass Linbo nach wie vor die Zeit auf dem Client wie die
Serverzeit setzt aber nicht mehr mit der hwclock synchronisiert. Wurde
hier ja so mehrfach vorgeschlagen.

gut, dann ist das halt so.
Ich fand es super, dass linbo die hwclock gesetzt hat, weil so jedes
Betriebsystem einen definierten Zustand vorfand.
Nehmen wir an, die BIOS Batterie ist leer, was garnicht so selten ist,
weil in Schulen oft STromausschalter verbaut sind.
Dann startet der Rechner mit einer Fantasiezeit … das kommt immer mal vor.
Wenn linbo die hwclock setzt, dann kann man sich am Client anmelden:
sofort, weil er die RTC ausliest und dei Systemzeit sofort stimmt.
Macht linbo das nicht kommt das Betriebsystem hoch und doodelt eine
Weile rum (wenn man Glück hat) und setzt die Systemzeit irgendwann
vielleicht richtig …
Dann kann man sich anmelden: alle Versuche vorher schlagen fehl mit
einer undeutlichen Fehlermeldung.
Ich fand den einzigen Pferdefuß von „linbo setzt die RTC“, dass man
Windows beibringen mußte nicht localtime in RTC zu erwarten, sondern
UTC: das ist ein Regeintrag.

Den muss man aber sowiso machen, wenn man windows und linux auf einem
Client betreiben will sonst ist man bei jedem „umbooten“ 2 Stunden „daneben“

Egal: jetzt weiß ich es: dann kann ich das supporten :slight_smile:

VIele Grüße

Holger

64

Fand ich auch, aber anscheinend kommen manche Anwender*innen nicht damit zurecht.

VG, Thomas

65

Hallo Thomas!

Warum nicht so wie ich es hier in github vorgeschlagen habe?

Alle wären zufrieden.

Beste Grüße

Thorsten

66

Hallo Thorsten,

Wenn du mir sagst, wie das gehen soll. Linbo holt sich vom Server die Infos bzgl. Zeit und Zeitzone. Wie soll es entscheiden was für das eine und was für das andere OS einzustellen ist?

VG, Thomas

67

Hallo Thomas,

ich bin davon ausgegangen, dass Linbo vor dem Starten eines der BS dessen start.conf auswertet. Wenn dem so nicht ist, dann geht das natürlich so nicht.

Beste Grüße

Thorsten

68

Das tut es, aber in der start.conf steht AFAIK keine Info über die lokale Zeitzone drin.

VG, Thomas

69

zur Info - Folgendes hatte ich im Sinn, als ich bei github den Vorschlag mit dem Workaround (RTC setzen entfernen) und mit „OS-based-switching (later)“ gemacht habe:

  • die .conf bekommt einen (optionalen) Eintrag RTC=(auto|utc|localtime) mit dem default-Wert auto
  • die linbo_cmd liest schon den Namen/Typ des OS; damit hat man die Information, ob das ein Windows ist oder nicht
  • je nach Wert des RTC-Eintrags passiert beim Start folgendes:
    • UTC: die Zeit wird vom Server abgerufen und die RTC gesetzt: hwclock --utc --systohc
    • localtime: die Zeit und die Zeitzone wird vom Server abgerufen und die localtime gesetzt: hwclock --localtime --systohc
    • auto oder fehlender Eintrag RTC: Wenn es ein Windows ist, wird wie im Fall localtime gehandelt, sonst wie im Fall UTC.

Das Ganze könnte sukzessive implementiert werden:

  1. die Fallunterscheidung (in linbo_cmd)
  2. die Möglichkeit den Wert in der UI zu setzen

Damit hätte man glaube ich alles erschlagen, was vorkommen könnte. Dabei setze ich voraus, dass der Server und die Firewall die korrekte Zeitzone haben.

Viele Grüße
Fabian

edit: zweiten Spiegelpunkt präzisiert; Bemerkung: Firewall und Server haben die korrekte Zeitzone.

2 „Gefällt mir“
70

Ok, der Linbo-Client hat dieselbe /etc/localtime wie der Server.

Frage:
Was bewirken

  1. hwclock --utc --systohc
  2. hwclock --localtime --systohc

auf dem Linbo-Client wenn z.B.

  1. localtime=Europe/Berlin
  2. localtime=UTC

ist?

Im Falle von localtime=UTC bewirken beide hwclock-Befehle genau dasselbe. Und jetzt?

VG, Thomas

71

Ich finde das setzen der RTC auch charmant, auch wenn es seine Nachteile hat.

Den Fall den du hier beschreibst, wo localtime=UTC ist und der gleiche Wert gesetzt wird ist doch richtig.

Wenn das meine Zeitzone ist ist es auch egal ob ich a oder b verwende da es wirkungsgleich ist. Allerdings steht in der start.conf nicht nachvollziehbar drin ob es ein Linux oder ein Windows ist.

Ich würde einfach definieren

  • kein Eintrag / auto --> Default, UTC wird in die HC geschrieben.
  • RTC=localtime --> Lokale Zeit wird in die HC geschrieben
1 „Gefällt mir“
72

Ja, aber dann brauch ich doch den ganzen Bohei mit start.conf Optionen nicht! Das ist ja dann genau so wie es zuvor schon war. Die Messlatte für eine Änderung der start.conf ist hoch, da dann drei Pakete betroffen sind. Da muss man genau schauen, ob sich der Aufwand lohnt.
Ich würde da erstmal eine Machbarkeitsstudie sehen wollen, ob das in der Praxis mit verschiedenen Betriebssystemen auch so geschmeidig funktioniert, wie es hier angenommen wird, bevor man dafür weitere Entwicklerressourcen einsetzt.
Ich fand die ursprüngliche Lösung den Linbo-Client genauso wie den Server zu konfigurieren am effektivsten. Man kann sich stabil darauf verlassen, dass alle Clients mit Zeit & Zeitzone identisch mit dem Server sind. Ggf. muss man das Client-BS einmal anpassen, damit die richtige Zeitzone verwendet wird. Man kann auch die Zeitzone auf dem Server ändern, wenn einen das Fell juckt.

VG, Thomas

2 „Gefällt mir“
73

Grundsätzlich stimme ich dir zu. Die Zeitzonen sollten identisch und korrekt sein; ein Client-BS müsste dann angepasst werden.

Ausgangsproblem: Firewall, Server und Client laufen auf localtime=Europe/Berlin und sollen das auch.

  • Das funktionierte für Windows-Clients, aber nicht für Linuxclients, weil hwclock aus busybox (anders als das unter Linux) die lokale Zeit in die RTC schreibt. Die Linuxclients lesen die dann aus und addieren erneut 2 Stunden. Da timesyncd nicht bei Systemstart synchonisiert, sondern nach einer Zufallszeit, funktioniert das SSO nicht.
  • Davon Linux mit Lokalzeit als RTC zu betreiben wird abgeraten. Also kannsollte man Linux nicht anpassen.
  • Also Windows anpassen: Dafür, dass hwclock aus busybox immer UTC in die RTC schreibt, hatte ich den pull-request eingereicht; man hätte dann aber Windows 10 per Registry auf UTC setzen müssen (das ließe sich in der global.reg ergänzen - im Allgemeinen als QWORD und für x32 als DWORD, auskommentiert; zusätzlich ein Kasten mit rotem Rand in der Doku :stuck_out_tongue_winking_eye:).
    Unter Windows 10 soll das angeblich endlich funktionieren…

Die Diskussion hatte sich in Richtung einer Fallunterscheidung bewegt, also war mein Vorschlag auf das setzen der RTC zu verzichten (bis entweder eine Fallunterscheidung implementiert ist, oder bestätigt werden kann, dass Windows 10 mit UTC ohne Probleme läuft).

Viele Grüße
Fabian

74

Ich kann die hier geschilderten Probleme einfach nicht nachvollziehen.
Ich habe hier auch den Server auf Timezone Europe/Berlin konfiguriert.
Auf dem Standard-Bionic-Client von Holger habe ich mit dpkg-reconfigure tzdata die Timezone auf Europe/Berlin eingestellt. Mehr nicht. Der Client startet immer mit der richtigen Zeit, keinerlei Anmelde- und/oder SSO-Probleme.
Genauso der Win10-Client. Hier ohne weitere Anpassung immer mit der korrekten Zeit, keinerlei Anmeldeprobleme.
Und das auch mit der Linbo-Vorgänger-Version, die noch hwclock --systohc ausgeführt hat.
Tut mir leid, ich verstehe es nicht.

VG, Thomas

75

Hallo Thomas,

so wie ich das sehe war das einzige Problem, dass Windows localtime in
RTC erwartet hat und dann erstmal 2 Stunden daneben war: dann klappt die
Anmeldung zwar, aber nicht SSO.
Das habe ich durch einen Registryeintrag behoben.

Ich fände es am sinnvlollsten wenn wir linbo wieder die RTC auf UTC
setzen lassen und den Registryeintrag für Windows in den global regpatch
rein nehmen.
Dann hätten beim booten immer alle die richtige Zeit :slight_smile:

Vor allem dürfen wir wohl annehmen, dass inzwischen alle Windowsnutzer
Win10 verwenden und keien alte Windowsvereion mehr, die bei UTC in der
RTC rumspacken.

Viele Grüße

Holger

76

Dann muss entweder dein hwclock --systohc etwas anderes schreiben oder timesyncd liest und schreibt anders…

Ich habe gerade noch einmal per wireguard nachgeschaut:

  • Server/Firewall laufen in der korrekten TZ mit korrekter Systemzeit
  • Client unter Linbo schreibt mit der Vorgängerversion Localtime in die RTC (Zeit ist korrekt; TZ auch):
    • hwclock --systohc; hwclock liefert
      Mon Jun 15 22:12:35 2020 0.000000 seconds
    • hwclock --systohc --utc; hwclock liefert
      Mon Jun 15 20:13:21 2020 0.000000 seconds

Für den Linux-Client bewirkt dies mit hwclock --systohc

Local time: Di 2020-06-16 00:24:43 CEST
Universal time: Mo 2020-06-15 22:24:43 UTC
RTC time: Mo 2020-06-15 22:24:43
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
systemd-timesyncd.service active: yes
RTC in local TZ: no

und mit hwclock --systohc --utc

Local time: Mo 2020-06-15 22:17:15 CEST
Universal time: Mo 2020-06-15 20:17:15 UTC
RTC time: Mo 2020-06-15 20:17:15
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
systemd-timesyncd.service active: yes
RTC in local TZ: no

Sind deine Linux-Clients eventuell Dual-Boot-Clients (mit Windows)? Ich habe mal irgendwo gelesen, dass einige Ubuntu-Versionen automatisch RTC in local TZ: yes setzen, wenn sie eine NTFS-Partition finden…

Viele Grüße
Fabian

77

Nein, kein Dual-Boot. Hab es gerade nochmal auf dem Bionic-Client mit dem aktuellen Linbo (ohne hwclock --systohc) nachvollzogen. Alle Maschinen und Clients mit TZ Europe/Berlin, Anmeldung und Proxy-SSO alles tippitoppi. Also, ich weiß nicht …

78

Und jetzt noch der Win10-Client mit aktuellem Linbo: TZ Europe/Berlin, kein zusätzlicher Regpatch, Anmeldung & Proxy-SSO Ok.

79

Gewagte Annahme! :wink:

80

sehe ich auch so. Vielleicht trifft das für die Anwender der Version 7 zu (aber auch da habe ich Zweifel), aber sicher nicht für die 6.2er.

Gruß

Alois