ich nutze das lmn-bionic-cloop und hatte das Problem, dass die Netzlaufwerke nicht eingebunden wurden; In den Log-Dateien stand ein Authentifizierungsproblem von CIFS, das mit einem Problem von Kerberos SSO zusammenhing.
Genau hinschauen zeigte: Die Systemzeit war 2 Stunden voraus. Nachdem die Zeit angepasst war, funktionierte endlich alles
Leider besteht die Ursache des Problems weiterhin:
timesyncd schreibt nach einem sync die UTC-Zeit in die RTC
nach einem Neustart hat Linbo die korrekte CEST-Systemzeit (mit date ausgelesen) ,
aber hwclock zeigt, dass die RTC wurde auch auf die Systemzeit (und nicht auf UTC, wie üblich)
wenn nun Ubuntu gestartet wird, ist die Systemzeit (CEST) zwei Stunden zu weit in der Zukunft - Ubuntu arbeitet hier also korrekt (),
da die RTC auf der falschen zeit stand ()
Schreibt Linbo tatsächlich einen falschen Wert in die RTC oder muss im Client ein ntp-sync erzwungen werden (das passiert automatisch erst nach 32 bis 2048 Senkunden; zu spät für einen möglichen Login)?
Hallo,
mit der vorgeschlagenen Option im bionic-cloop funktioniert das.
Alternativ könnte man die Datei als postsync entsprechend ablegen und anwenden.
So stimmt dann auf jeden Fall die Uhrzeit beim Client und Anmeldung und Netzlaufwerke sind nach der Anmeldung auch vorhanden.
danke zunächst für die vielen Hinweise! Ich habe mal linuxmuster-linbo geklont und in den Quelltext geschaut.
Wilfried und Chris : einen der beiden Vorschläge werde ich vorläufig umsetzen, bis das eigentliche Problem behoben ist. Danke!
Thorsten, Michael und Chris: NTP-Server laufen auf der Firewall und auf dem Server. Man kann die Zeit auch abfragen und es kommt die korrekte Zeit zurück (gerade per wireguard und sntp getestet; auch noch einmal vom Server aus per ntpq -p und vom Client aus in Linbo per ntpd -n -q -p). Daran liegt es nicht.
Wie oben geschrieben, wird durch timesyncd unter Ubuntu die korrekte RTC gesetzt (in UTC) - das lässt sich auch mit hwclock prüfen.
Nach einem Neustart bootet Linbo und setzt in Zeile 623 der init.sh die falsche Zeit in die RTC: ( ntpd -n -q -p "$server" && hwclock --systohc ) &
Wenn man sich mit linbo-ssh einloggt, liefert date die korrekte Zeit und Zeitzone (CEST), aber hwclock -w schreibt diese Zeit falsch als UTC in die RTC. Ergänzt man -u als Parameter von hwclock, wird die korrekte Zeit in die RTC geschrieben.
da der Paramter -u würde Probleme mit Windows machen würde, habe ich hier beim pull-request drei Lösungsansätze vorgestellt. Ich bleibe am pull-request dran und sehe das Problem damit als gelöst an.
Etwas Offtopic: Wer entscheidet über Änderungen und trifft grundsätzliche Design-Entscheidungen? Wie läuft das ab?
Etwas Offtopic: Wer entscheidet über Änderungen und trifft
grundsätzliche Design-Entscheidungen? Wie läuft das ab?
die Entwickler diskutieren das und entschieden dann zusammen.
Dabei werden natürlich Einwärfe von anderen auch gerne gehört und
fließen in die Entscheidung mit ein.
Was muss ich nun konkret wo einstellen? Meine Konfiguration nach Installation der Proxmox-Appliances für LMN7 (von netzint.de) war wie folgt
OPNsense: synct die Zeit von pool.ntp.org - steht auf UTC und geht damit 2h nach
LMN-Server: steht ebenfalls auf UTC und geht 2h nach
linbo: UTC, geht 2h nach
bionic-client: steht auf CEST und Uhrzeit ist korrekt
Windows-client: ging 2h nach (nach Registry-Patch wird die Zeit korrekt angezeigt).
Was muss ich nun wie/wo einstellen/verändern? Die Client-Systeme haben nun die korrekte Uhrzeit. Lediglich Linbo zeigt -2h an.
Danke vorab und Grüße
Ralf
Sauber wäre es im LMN Server die deutsche Zeit einzustellen (systemctl --set-timezone oder sowas).
Allerdings wurde im aktuellen Linbo Paket die Zeitzuweisung passend für Windows gefixt, bedeutet in die Systemuhr wird die lokale Zeit geschrieben.
Man kann sich jetzt streiten was hier sinnvoller ist. Läuft der Schulserver weiter mit UTC wird auch Linbo auf den Clients UTC eintragen.
Die Vorteile davon sind:
Software kann sich darauf verlassen, dass die Uhrzeit immer konstant vorwärtsläuft, niemals rückwärts (was ja bei einer Umstellung von Sommer- auf Winterzeit passieren würde). Denn letzteres kann interessante Fehler bei Datenbanken oder anderer Software verursachen, die parallele Zugriffe auf Daten haben und diese irgendwie sinnvoll nach Reihenfolge (meist die Uhrzeit) abarbeiten.
Inzwischen sind die meisten Softwarehersteller da aber clever genug, die Systemlaufzeit als Referenz zu nehmen - die kann sich nur vorwärts bewegen.
In Umgebungen, wo du Cluster betreibst und Daten auf verschiedene Maschinen verteilst, ist es allerdings unabdingbar wichtig, dass alle Systeme eine exakt gleiche Zeit haben, da dies die einzige Referenz ist, welche Daten wo zuerst da waren.
Da könnten dir springende Uhrzeiten richtig Ärger mit Datenverlust und stehen gebliebenen Replikationen verursachen.
Kurz: Du willst keine springenden Zeiten haben, weder nach vorne noch zurück. Sowas macht nur Ärger."
Also um den Streit zu vermeiden bevor er ausbricht: @Thomas: Könnte Linbo, was ja irgendwie auch nur ein BS ist, nicht einfach die Zeitanzeige im Linbo-Bildschirm +1h bzw. +2h anzeigen. Dann fällt einem Unbedarftem der interne Zeitunterschied gar nicht auf.Freut sich aber über die „korrekte“ Uhrzeit.
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.
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.
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.
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.
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:
