Probleme mit Dualboot und Kerberos-Tickets

Das meldet hier eine Liste von lauter ntp-Servern, wohingegen mit dem Zusatz „firewall“ nur dies erscheint:

root@vm-fossa:~# ntpq -p firewall
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+uruz.org        235.106.237.243  3 u  123  512  377   23.348    2.617   0.452
*time.cloudflare 10.48.8.4        3 u  497  512  377   22.215   -0.383   0.692

Hallo Michael,
da bin ich wieder.

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…

Gruß,
Mathias

„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“!?!? :thinking:

So, da bin ich wieder…
Was sagen denn systemctl status systemd-timesyncd.service und systemctl status ntp.service ?

Da ich da nichts geändert habe, ist die Ausgabe vermutlich genauso wie bei dir?
Ich gucke aber gleich nochmal genauer nach

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.

Bitte alles als root auf dem Server ausführten.

Gruß,
Mathias

Hallo Mathias,
ach ja – klar, wenn man darüber nachdenkt :slight_smile:

Also ich hatte am Server schon vor längerer Zeit ein paar NTP-Einstellungen vorgenommen (so wie im o.g. Thread vorgeschlagen).

Ich erhalte jetzt:


[root@server:~]$ systemctl status systemd-timesyncd.service

● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-timesyncd.service(8)

Läuft also nicht.
und:

[root@server:~]$ systemctl status ntp.service

● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-12-30 09:53:53 CET; 1 weeks 0 days ago
     Docs: man:ntpd(8)
  Process: 979 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 1003 (ntpd)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/ntp.service
           └─1003 /usr/sbin/ntpd -p /var/run/ntpd.pid -4 -g -u 113:117

Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[994]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -4 -g -u 113:117
Dez 30 09:53:53 server.linuxmuster.meine-domain.de systemd[1]: Started Network Time Service.
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: proto: precision = 0.140 usec (-23)
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: getconfig: Couldn't open </etc/ntp.conf.admin>
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: MS-SNTP signd operations currently block ntpd degrading service to all clients.
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: restrict: ignoring line 25, mask '::' unusable.
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: Listen and drop on 0 v4wildcard 0.0.0.0:123
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: Listen normally on 1 lo 127.0.0.1:123
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: Listen normally on 2 ens18 10.16.1.1:123
Dez 30 09:53:53 server.linuxmuster.meine-domain.de ntpd[1003]: Listening on routing socket on fd #19 for interface updates

NTP läuft … ich hatte es bisher so verstanden, dass es für den Client egal ist, ob auf dem Server ntp oder timesyncd läuft?

Hallo Michael,

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?

Danke und viele Grüße,
Michael

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 ?

Viele Grüße,
Michael

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?

Viele Grüße,
Michael

Hallo Michael!

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?

Grüße,
gerd

Hallo Gerd,
wir haben mittlerweile auf das neue Anmeldescript umgestellt. Damit läuft es bei uns fehlerfrei.
Hilft das weiter??
Viele Grüße
Michael

boah bist du schnell, danke,

Wenn das bedeutet: wie oben gefragt:

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

Grüße,
gp

Genau das meinte ich. Es ist neuerdings in der Doku und ersetzt das alte adsso-Script.
VG
Michael