Probleme mit Dualboot und Kerberos-Tickets

Clientpflege Linuxclient
#1

Hallo.
Ich habe eine VM vorbereitet, auf der Dualboot ermöglicht werden soll. Also

  • Ubuntu auf /dev/vda1 und
  • Windows 10 auf /dev/vda4.

Win10 startet in der VM bisher nicht (erneut der schon diskutierte Fehler #0xc000000e) , doch eine User-Anmeldung unter Ubuntu war nach Neu + Start von Win10 nicht mehr möglich!
Daher musste ich wohl oder übel nochmal linuxmuster-cloop-turnkey laufen lassen, was auch erfolgreich durchlief. Eine Anmeldung als User klappt unter Ubuntu wieder – aber die Home-Laufwerke sind trotzdem nicht da!

Ein Blick in die Liste der Kerberos-Tickets zeigt aber nun:

<mein-login>@vm-fossa:/$ klist
Ticketzwischenspeicher: FILE:/tmp/krb5cc_1084201206_l7MgMr
Standard-Principal: <mein-login>@LINUXMUSTER.MEINE-DOMAIN.DE

Valid starting       Expires              Service principal
01.01.1970 01:00:00  01.01.1970 01:00:00  krbtgt/LINUXMUSTER.MEINE-DOMAIN.DE@LINUXMUSTER.MEINE-DOMAIN.DE

An diesem Kerberos-Ticket sind gleich zwei Dinge merkwürdig:

  • das Datum
  • der doppelte Eintrag der Domäne bei Service principal?

Wenn ich aber als angemeldeter User nochmal folgendes mache:

klist   (zeigt die Kerberos-Tickets an)
kinit   (erzeugt ein neues Kerberos Ticket)
/etc/linuxmuster-client/scripts/login.sh  (wiederholt den Vorgang beim Login)

ist Home_auf_Server wieder richtig vorhanden!

Danach nochmal abgemeldet und wieder angemeldet: Home_auf_Server bleibt erhalten (weil das Kerberos-Ticket ja auch noch gültig ist!)

Dann die VM nochmal komplett neu gestartet (/tmp und die Kerberos-Tickets werden dabei ja gelöscht): Das neue Ticket wird wieder mit dem seltsamen Datum von 1970 (Unix-Zeit 0?) ausgestellt – aber dieses Mal ist Home_auf_Server da!

Mit anderen Worten: Da läuft offenbar etwas nicht ganz richtig mit den Kerberos-Tickets. An der Client-Uhrzeit liegt es nicht. Die passt!
Was kann das sonst noch sein?

Viele Grüße,
Michael

Dualboot von Linux und Win in V7
#2

Hallo Michael,
mit wem synchronisiert der Linux-Client die Zeit?
Er sollte mit dem Server die Zeit synchronisieren.
Gruß,
Mathias

#3

Hallo Mathias,
es ist ja „dein Client“ bzw der von @zefanja (ubuntu2004, thailändisch benötige ich hier übrigens nicht und habe es wieder entfernt :wink: ) – daher gebe ich die Frage direkt an Dich zurück: Wie hast du’s eingestellt? :slight_smile:

VG,
Michael

#4

Muss ich nach schauen. Dazu muss ich erst noch meinen zweiten Proxmox hochfahren…
ich melde mich wieder.

Ach ja, hast du unter Windows RTC=UTC eingestellt? Linux benutzt nämlich UTC und Windows die lokale Zeit, was den Tickets den Gar ausmacht…
Gruß,
Mathias

#5

… wie gesagt: Win10 ist in der ganzen Zeit gar nicht hochgefahren. Da konnte ich gar nichts ändern, weil es gar nicht startet bzw direkt beim Start hängen bleibt (s.o.)

Hier steht nochmal, wie es unter Ubuntu läuft:

Ich erhalte:

 timedatectl
               Local time: Di 2021-01-05 13:37:06 CET
           Universal time: Di 2021-01-05 12:37:06 UTC
                 RTC time: Di 2021-01-05 12:37:07    
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes                       
              NTP service: active                    
          RTC in local TZ: no

Ich habe es gefunden – die Einstellung stimmt:

cat /etc/systemd/timesyncd.conf 

[...]
[Time]
NTP=10.16.1.1
[...]

und: systemctl status systemd-timesyncd --> ist aktiv!
#6

Hat dein Server die IP 10.16.1.1? Oder ist es 10.0.0.1 ?

#7

stimmt so … ich habe migriert mit do-it-like-babo

#8

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

#9

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

Screenshot_20210105_134759
Screenshot_20210105_134759706×295 22.3 KB

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

#10

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…

#11

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

#12

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

#13

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
#14

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

#15

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

#16

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

#17

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
#18

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

#19

„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!

#20

… 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: