Bei mir bekommt der Server seine Zeit von der Firewall. Bei dir offensichtlich nicht. Eigentlich sollte das egal sein. Hauptsache sie haben beide die gleiche Zeit…
Hier im Forum gabs mal viel zum Thema NTP …
Ich muss leider grad weg. Ich schau später nochmal nach…
„ping firewall“ liefert auch die richtige IP: 10.16.1.254
Den NTP Thread habe ich etwas weiter oben schon verlinkt. Vielleicht sollte der Ubuntu Client auch auf ntp umgestellt werden??
Interessanterweise habe ich gerade den Befehl nochmal getestet … und siehe da: Jetzt steht da:
root@vm-fossa:~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*server.linuxmu 10.16.1.254 5 u 14 64 1 0.437 0.029 0.413
Ich habe alle Tickets mit kdestroy gelöscht und mich dann neu angemeldet. Jetzt ist Home_auf_Server da – aber das Ticket zeigt trotzdem weiterhin 1970 an!!!
Aber es scheint genauso zu sein, wie du die ganze Zeit vermutet hast: das liegt am Zeitserver bzw daran, dass beim Systemstart nicht schnell genug synchronisiert wird!
… ganz unabhängig von diesem Fehler kommt mir das System Kerberos-Ticket <-> Zeitserver <-> Anmeldung ziemlich fragil vor?! Ich verstehe auch nicht, warum überhaupt ein Ticket erstellt werden kann/darf, wenn es an der falschen Uhrzeit liegen sollte?! Dann wäre es meiner Meinung nach besser, wenn die Anmeldung vollständig abgewiesen werden würde und nicht dieses „halb/halb“!?!?
Hallo Michael,
entschuldigung, das hätte ich sagen sollen. Du solltest die Befehle als root auf dem Server eingeben. Die Zeit sollte per ntp vom Server bereitgestellt werden. Ob das so ist, erkennt man an der Ausgabe von systemctl.
Falls statt ntp der system-timesyncd aktiv ist, schaltet man mit systemctl enable ntp.service und mit systemctl disable systemd-timesyncd.service den ntp ein und den system-timesyncd aus.
was die systemzeit angeht scheint alles in Ordnung zu sein.
Ich muss zugeben, dass ich im Augenblick ein bisschen ratlos bin.
Wenn mir noch was einfällt, melde ich mich nochmal.
Gruß,
Mathias
Ich denke, dass du oben schon Recht gehabt haben könntest … der Zeit-Abgleich mit dem Server geschieht beim Booten vielleicht nicht schnell genug?? Wenn ich warte, wird ja von ntpq -p auch der server gefunden; vorher aber nicht.
Vielleicht wäre es auch eine Option, den Client ebenfalls von timesyncd auf ntp umstellen?
weis nicht. Bei mir läuft’s eigentlich fast ohne Probleme. Manchmal kommt es vor, dass ein Benutzer den Rechner weckt und sich sofort anmeldet. Da kam es auch mal vor, dass Home_auf_Server nicht da war.
Dann musste man sich halt ab und wieder anmelden und dann war alles wieder da.
Gruß,
Mathias
Das sieht nach dem gleichen Problem aus, oder? Ich bin weiterhin nicht sicher, was es mit dem seltsamen Zeitstempel von 1970 auf sich hat. Wenn ich mit kinit ein neues Ticket erzeuge, stimmt die Zeit jedenfalls!
Hallo.
Leider muss ich das Problem nochmal nach oben holen. Ich habe heute zwei Clients (einen PC, einen Laptop, also jedenfalls keine VMs mehr) mit dem focal fossa (Ubuntu 20.04) Image bestückt.
Das lief reibungslos – bis auf die weiterhin fehlenden Home_auf_Server und Tausch_auf_Server Icons. Es ist also weiterhin so, dass die Anmeldung funktioniert, dann aber klist ein Ticket von 1970 anzeigt.
Wenn ich mit kinit ein neues Kerberos-Ticket erzeuge, mich dann ab- und wieder anmelde, sind die o.g. Ordner da. Das Problem ist also nur durch etwas Warten bis zur ersten Anmeldung leider nicht gelöst.
Gibt’s noch andere Ideen?
Hallo Michael,
bei mir tritt das Problem zum Glück nicht auf. Allerdings habe ich auf meinem Windows Testsystemen RTC = UTC eingestellt.
Mehr fällt mir leider nicht ein.
Gruß,
Mathias
Hallo Mathias.
Windows hat hier keine Probleme … es geht ausschließlich um den Ubuntu-Client.
Ich habe mittlerweile ein paar Log-Files entdeckt, die evtl Aufschluss geben könnten – und zwar unter cd /var/log/sssd/ auf dem Focal Fossa Client.
Dort habe ich z.B.
cat sssd.log
Thu Jan 14 09:25:11 2021) [sssd] [service_signal_done] (0x0010): Unable to signal service [1432158311]: Unknown service
aber auch
cat ldap_child.log
(Thu Jan 14 11:43:39 2021) [[sssd[ldap_child[31687]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
Ich bin nicht sicher, ob das mit diesem Problem zusammenhängt – aber es sieht danach aus, oder?
Notfalls werde ich auf dem focal-Client nochmal
die /etc/krb5.keytab löschen
auf dem Server die .macct Datei entfernen und
… ja und dann? Wo ist der Unterschied zwischen linuxmuster-cloop-turnkey und linuxmuster-client-adsso-setup ?
Nachtrag und vorübergehende „Lösung“ (?) – es scheint tatsächlich ein Zeit(server)problem bzw ein Problem mit UTC/RTC zu sein!
Nun habe ich in das Script
/etc/linuxmuster-client/login.d/00_userinfo.sh
ganz am Anfang diesen Eintrag ergänzt: ntpdate -s 10.16.1.1
(also vor der Anmeldung nochmal einen Zeit-Sync mit dem lmn-Server erzwungen)
Seitdem sind die Ordner Home_auf_Server und Tausch_auf_Server wieder da – auch wenn dennoch weiterhin das Ticket (klist) ein Datum von 1970 zeigt!
Ist das bei Euch auch so?
Falls ein Entwickler mitliest: Ist das ein Würgaraound oder kann/sollte man das nicht sowieso in das Script einbauen, um am Client ganz sicher die richtige Zeit zu haben?
gerade wo ich in mein Arbeitsbericht „Dualboot“ schreibe, viel mir wieder ein: „da war doch noch was“ und bin dann hier gelandet…
siehe auch : Tippfehler in Dokumentation "linux-client-current-method"
Nachdem wir eine bisher funktionierende Linux Installation wieder auf Dualboot gemeinsam mit Windows umgestellt hatten, funktionierte der Login an den Linuxen - wie du ganz oben schreibst - nicht mehr.
Fragen:
Wenn ich dich richtig verstehe, sollte das mittlerweile grundsatzlich funktionieren - richtig?
Was hälst du bei unserem Problem für die bessere Lösung?
die von dir beschriebenen Scripte laufen zu lassen?
=> genau das.
Dann probiere ich das genau so und sag Bescheid, ob’s funktioniert hat,
wenn du das nicht meinst, bräuchte ich noch mal dei Info, welches Skript du genau meinst.
Zumindest lese ich aus deinem Thread, dass der Multiboot unter LMLv7 grundsätzlich funktioniert, das beruhigt schon mal.