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 + Startvon 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?
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 ) – daher gebe ich die Frage direkt an Dich zurück: Wie hast du’s eingestellt?
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
… 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!
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…
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
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“!?!?
) – daher gebe ich die Frage direkt an Dich zurück: Wie hast du’s eingestellt? 
