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

Clientpflege linbo
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

81

Hallo,

Gewagte Annahme! :wink:

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.

ich hab da schon an die 7 gedacht und nicht an die 6.2
Und ich denke tatsächlich dass wenige ihre Windows 7 INstallationen in
die lmn7 retten sondern den Umzug als Anlass nehmen die Umstellung doch
mal zu machen …

LG

Holger

82

Hallo Thomas,

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

welche Zeit hat der Client den im BIOS?
Interessant wäre auch, ob es direkt nach dem booten geht: also wenn
windows noch keien Zeit hatte einen Timesync zu machen.

LG

Holger

83

Manche setzen sicher auch noch XP ein. Darauf würde aber auch niemand Rücksicht nehmen der auch nur ein bisschen progressiv arbeiten möchte.
Auf nicht supportete Systeme muss man nur bedingt Rücksicht nehmen.

84

Hallo Thomas/alle,

das entfernen von hwclock --systohc aus linbo sorgt dafür, dass das sowohl „nur Win10“-, als auch „nur Linux“-Systeme funktionieren (tut es bei uns übrigens auch). Das war die Idee hinter dem Vorschlag den Befehl zu entfernen.

Hardware-Uhr (RTC) setzen

Die Hardware-Uhr (RTC) muss durch das Hauptbetriebssystem auf die korrekte Zeit gesetzt werden, damit das Betriebssystem von Anfang an die korrekte Systemzeit hat und das Single-Sign-On funktioniert, z.B.

  • im Hauptbetriebssystem (bei Linux muss man einmalig mit dem Login warten, bis die Zeit stimmt)
  • im BIOS (Achtung: Windows erwartet üblicherweise Lokalzeit; Linux UTC)
  • mit Linbo: vom Server aus mit dem Befehl linbo-sh <hostname> einloggen und dann mit dem Befehl hwclock --systohc (für Lokalzeit) oder hwclock --systohc --utc (für UTC)

Problemfälle

In folgenden Fällen können Clients Probleme machen (ich hoffe, ich habe nichts vergessen):

  • neu zu installierende Computer,bei denen die RTC noch nicht stimmt.
    Lösung: Hardware-Uhr setzen (s.o.)
  • bei Mainboard-Pufferbatterien ohne ausreichend Spannung sowie spannungsfreiem Netzteil; dadurch wird die Zeit nicht gespeichert.
    Lösung: Batterie ersetzen und Hardware-Uhr setzen (s.o.)
  • bei Dual-Boot-Systemen, genau dann, wenn das eine System Localtime in die RTC schreibt und das andere System UTC (z.B. Ubuntu und Windows 10).
    Lösung: bei einem Betriebssystem muss die Systemzeitbasis umgestellt werden:
    • Windows anpassen: mit regedit ein QWORD (32bit DWORD) erstellen HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal mit dem Wert 1
    • Linux anpassen (nicht empfohlen): timedatectl set-local-rtc 1

Viele Grüße
Fabian

1 „Gefällt mir“
85

Hallo Wolfgang,

was sage dazu Eure Apple Nutzer? Apple Geräte wollen zu Apple Zeitservern!

Gruß

Alois

86

Hi,
tja … lang lebe die Intransparenz … . Ich erfahre (politisch) keine Details
über das Netz wo ich durch muss … aber unsere Apple-Geräte hängen
an einem MDM, das mein Kollege verwaltet (politisch eine Ebene höher).
Es kann sein, dass der Schulträger das MDM mit der richtigen Zeit versorgt und die Geräte das darüber machen.
Außerdem verwenden diese Geräte unser „Recherche-WLAN“ und das geht 1:1 ins Internet - ob in dem ntp auch geblockt ist, kann ich aktuell nicht sagen.
Generell hat der Schulträger aber einen NTP-Server bereitgestellt, der aber wiederum (Firewall?) nicht alle Netze versorgt. Das Verwaltungsnetz darf wohl, das Unterrichtsnetz aber nicht.
… Nein, das macht keinen Spaß :frowning:

VG
Wolfgang