Probleme mit Dualboot und Kerberos-Tickets

Alles klar…
Wenn du in Linbo bist. Stimmt da die Zeit (sprich UTC)?

LINBO-Start meldet ein Offset von -1,1 Sekunden … danach habe ich:


… demnach zeigt LINBO bei mir die lokale Zeit und nicht die UTC an. Ist das ein Problem?

Das ist die lokale Zeit und nicht UTC.
Das heißt, der Client hat erst mal die falsche Zeit. Wenn er sich dann mit dem Server synchronisiert hat, was ein Bisschen dauert, kann man sich wieder anmelden.
Aber es dauert halt ein bisschen…

… ist das nun eine Linbo-Einstellung oder kann es sein, dass es auf bare metal direkt richtig läuft?

Das ist eine Server-Einstellung… Ich schau mal nach, wie ich das umgestellt habe…

Auf dem Server hatte ich das schon mal so eingestellt wie Gerd (@gpeter) es vorgestellt hatte … da gab es mal einen Thread bzgl ntpdate. Hier wird die Uhzeit von der OPNSense geholt (so wie es imho sein soll?)
Mein Server meint dazu:

[root@server:~]$ timedatectl 
                      Local time: Di 2021-01-05 13:58:18 CET
                  Universal time: Di 2021-01-05 12:58:18 UTC
                        RTC time: Di 2021-01-05 12:58:19
                       Time zone: Europe/Berlin (CET, +0100)
       System clock synchronized: yes
systemd-timesyncd.service active: no
                 RTC in local TZ: no

Führe mal update-linbofs auf dem Server aus und starte danach den Client synchronisiert.

Gerade beides gemacht – Home_auf_Server ist nicht mehr da! Das Ticket ist also wieder ungültig bzw hat die falsche Zeit …

was sagt denn ntpq -p bzw ntpq -p firewall ?

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