20.04.er-Client - Anmeldung klappt nicht

lessi · 25. Juli 2020 um 10:24

Hallo Stephan,

habe auch einen 20.04er-Client am Laufen bzw. richte noch einiges ein und brauche auch noch Tests auf realer Hardware (bisher bloß VM), vielleicht kann man sich ja über ein paar Tricks&Tipps austauschen.

Hast du einen LeoClient oder vergleichbares am Laufen?
Was hast du mit dem Standby/Sperren-Knöpfen gemacht?

Grüße,
Stefan

zefanja · 30. Juli 2020 um 07:25

Hallo Stefan,

Nein.

vG Stephan

lessi · 30. Juli 2020 um 10:08

Hallo,

ich habe heute erstmals unser pädagogisches Netz auf den linuxmuster7 gelegt und stehe jetzt vor einer ganzen Reihe unschöner Probleme:

Wenn ich am Client übers Netzwerk Linbo boote, holt er sich eine korrekte IP aus dem 10.0.255.x-Netz (bisher bei uns 10.32.1.x), aber als Server nennt er den alten 10.32.1.1 statt den neuen 10.0.0.1, außerdem hat er die alte Rechnergruppe drin, das neue Passwort für den Imaging-Karteireiter nimmt er nicht an. Es funktioniert erst, wenn ich die Festplatte mit gparted lösche und neu starte. Aber ich will auf keinen Fall alle 200 Clients erst formatieren müssen…!
Beim Booten des gesyncten Clients startet das Grub-Bootmenü, dann musste ich nochmal eine Taste drücken, dann meldete Ubuntu kurz, dass es eine UUID nicht findet (ich dachte, die hätte ich alle durch sdax ersetzt, da muss sich aber offenbar noch was gehalten haben), dann startet Ubuntu aber doch…
Ich kann mich als User anmelden, aber offenbar nur, weil ich mich vor Erstellen des Images auch schon mal testweise angemeldet hatte, ein zweiter User kann sich nicht anmelden.
Wenn ich mich als User anmelde, komme ich nicht auf unsere DMZ-Server. Nur wenn ich die Client-IP im OPNsense unter NoProxy hinzufüge, komm ich auf die Server (in der Statusanzeige oben wechselt dann auch das Fragezeichen zum normalen Verbindungszeichen). Andere Internetserver funktionieren zwar, allerdings muss ich mich separat authentifizieren, SSO tut offenbar nicht, habe ich beim Erstellen des 20.04-Clients auch nie eingerichtet, ich habe keine Anleitung dazu gefunden…?

Das sind erstmal die schlimmsten Probleme, hat jemand Tipps…?

Grüße,
Stefan

zefanja · 30. Juli 2020 um 10:25

Hallo Stefan,

hier ein paar Ideen:

Hast SSO auf der Firewall eingerichtet? Falls nicht, musst du die Proxy Umgebungsvariable deaktivieren. Es gibt da einen Bug in linuxmuster-client-adsso: Disabling the proxy in linuxmuster-client-adsso.conf · Issue #21 · linuxmuster/linuxmuster-client-adsso · GitHub

Hast du alle Schritte hier befolgt: Benutzung::01 Installation · linuxmuster/linuxmuster-client-adsso Wiki · GitHub ? Wichtig ist der Reboot und Image erstellen direkt nach der Aufnahme.

Allgemein gibt es auch das Skript linuxmuster-image-prep was praktisch ist vor der Imageerstellung (räumt /homes auf etc.)

Geht das Netz überhaupt 10.0.255.x? Müsste es nicht 10.0.254.x sein? Evtl. hast du hier zwei DHCP Server, die antworten (je nachdem wer schneller ist). Tritt das Problem auch auf, wenn du den lmn6.2 Server mal ausschaltest?

Falls du noch UUIDs hast, schau mal hier: Linuxclient from Scratch: Notwendige und hilfreiche Anpassungen - #11 von garblixa (bzw. auch den ganzen Thread). Ich musste auch erst etwas basteln, bevor wirklich alle UUIDs wegwaren.

vG Stephan

lessi · 30. Juli 2020 um 12:31

Hallo Stephan,

Schau ich noch nach, gerade Baustelle #2…

Hatte ich mal erledigt, aber danach noch am Client weitergebastelt. Habe turnkey jetzt nochmal aufgerufen (jetzt fehlte ihm plötzlich der openssh-server - hat sich da was geändert? Habe den jedenfalls auch noch nachinstalliert, turnkey lief dann ohne Fehler durch), dann den Rechner gleich neu gestartet, Image erstellt, Image auf Client gesynct, weiterhin keine Anmeldung als User… Auf meinem ursprünglichen virtuellen Client, von dem ich das Image erstellt habe, geht die Anmeldung als neuer User aber…

Kannte ich noch nicht, habe es ausgeführt, meldet dann aber, es sei noch ein User angemeldet - außer dem linuxadmin ist aber keiner angemeldet…

Nö, da steht echt 10.0.255.11. Kein zweiter DHCP, nach dem löschen der SSD funktioniert Linbo ja dann auch korrekt, liegt also an der alten Linbo-Installation auf der Festplatte (obwohl ich Netzwerkboot mache).

Die Schritte und Reihenfolge habe ich befolgt, ich schau aber noch mal, wo die UUID steckt…

Grüße,
Stefan

zefanja · 30. Juli 2020 um 13:22

Kopiere mal den SSH-Key (public) vom root user auf dem Server nach /root/.ssh/authorized_keys auf den Client (händisch oder per postsync). Dann kannst du dich per SSH vom Server aus auf den Client verbinden, um zu schauen, was bei der Anmeldung schief läuft: tail -f /var/log/auth.log.

Ja, kenne ich. Ich melde alle User ab, logge mich als root vom Server aus ein und führe dann den Befehl aus.

baumhof · 30. Juli 2020 um 13:31

Hallo,

Wenn ich am Client übers Netzwerk Linbo boote, holt er sich eine
korrekte IP aus dem 10.0.255.x-Netz (bisher bei uns 10.32.1.x), aber
als Server nennt er den alten 10.32.1.1 statt den neuen 10.0.0.1,
außerdem hat er die alte Rechnergruppe drin, das neue Passwort für
den Imaging-Karteireiter nimmt er nicht an. Es funktioniert erst,
wenn ich die Festplatte mit gparted lösche und neu starte. Aber ich
will auf keinen Fall alle 200 Clients erst formatieren müssen…!

linbo erkennt, dass der Client schon linboisiert ist und modelt die
vorhandene start.conf mit der des servers zusammen: dabei ergibt es Salat…
Bei mir war das letztes Jahr nach der Migration nur an einer
Hardwareklasse so: hab ganz schön lange den Fehler gesucht.

Abhilfe schaffte: einmal Festplatte leeren.
… sorry.

Vielleicht geht es mit autoformat in linbo …
Der kann dann zwar nicht syncen, weil er den Server nicht findet, aber
dann kannst du ihn je einfach neustarten lassen…

Beim Booten des gesyncten Clients startet das Grub-Bootmenü, dann
musste ich nochmal eine Taste drücken, dann meldete Ubuntu kurz,
dass es eine UUID nicht findet (ich dachte, die hätte ich alle durch
sdax ersetzt, da muss sich aber offenbar noch was gehalten haben),
dann startet Ubuntu aber doch…

da geht es wahrscheinlich um die UUID der swap Partition: schau mal am
Client in die /etc/fstab
Wäre es die rootpartition, würde er nicht booten.

LG

Holger

lessi · 30. Juli 2020 um 15:22

Hallo Stephan, hallo Holger,

der Frust sitzt gerade ziemlich tief, weil wir den ganzen Tag in der Schule waren und null vorankommen… Das Problem scheint mir tieferliegend zu sein, aber von vorne:

Das Linbo-Partitionierungsproblem dürfte sich mit Linbo 2.3.65 und dem neuen Wipe ja hoffentlich lösen, probiere ich aus, wenn ich wieder in der Schule bin.
Ich habe mein Ubuntu2004-Image nochmal neu mit update-grub und update-initramfs bearbeitet, ändert nichts. Ich habe am neu gesyncten Client mal turnkey ausprobiert, läuft durch, aber keine Useranmeldung. Am virtuellen Client, an dem ich das Cloop erstellt habe, lässt sich ein neuer „User1“ problemlos anmelden. Wenn ich dann davon wieder ein Cloop erstelle, einen nicht-virtuellen Client damit synce, kann ich mich mit „User1“ anmelden. „User2“ geht aber nicht.
Ich habe das mint-Cloop sowie das ubuntu-vanilla-Cloop ausprobiert (Masterclient erstellt, turnkey, neues Image, neuen Client mit neuem Image syncen), bei beiden funktioniert keine Useranmeldung (natürlich bis auf den lokalen linuxadmin).
Ich habe die Uhrzeit bei einem Client unter Ubuntu2004 mal angeschaut, sie weicht um 2 Minuten vom Server ab (Server: 15:15:00, Client 17:13:02). Ich habe die Zeit manuell angepasst (+/- 5 Sekunden, also den Client auf 17:15:05 oder so), kein Login möglich.

Probiere ich morgen mal aus.

Die gemeldete UUID ist aber die von sda1 (habe ich zum Nachschauen in der fstab auskommentiert stehen lassen…). Bootet trotzdem, Login als linuxadmin möglich, aber die Fehlermeldung steht halt einige Sekunden lang auf dem Schirm.

Gefrustete Grüße,
Stefan

baumhof · 30. Juli 2020 um 18:17

Hallo Stefan,

kontrollier auch mal, ob der Rechnernamen korrekt gepatched wird.
Also im gebooteten Client in die /etc/hostname
reinschauen.

Welche IPs haben den deine „echten“ Clients?

LG

Holger

zefanja · 31. Juli 2020 um 00:36

Was gibt sudo grub-mkconfig | grep -i uuid auf dem Client aus?

Uhrzeit ist kritisch. Sie muss unbedingt mit der des Servers übereinstimmen. Wie Holger schon sagte, schau mal ob der Hostname richtig ist. Ansonsten sollte die auth.log den Fehler zeigen.

vG Stephan

lessi · 31. Juli 2020 um 07:42

Hallo,

es wird nicht besser…

/etc/hostname: r21902 - passt
ip address: 10.0.219.2 - passt
Uhrzeit: synchron mit linuxmuster-server

auth.log:
Jul 31 08:37:07 r21902 lightdm: pam_unix(lightdm:auth): check pass; user unknown Jul 31 08:37:07 r21902 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= Jul 31 08:37:07 r21902 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=musterma Jul 31 08:37:07 r21902 lightdm: pam_sss(lightdm:auth): received for user musterma: 10 (User not known to the underlying authentication> J
(auf dem virt. Client, auf dem ich das Cloop erstellt habe, klappt beim gleichen User die Anmeldung mit pam_sss)

Auf dem gesyncten Client habe ich auch mal, wie im Thread Linuxmuster-client-adsso-setup: Probleme mit mount geschrieben, die pem-Datein in /var/lib/samba/private/tls gelöscht und turnkey aufgerufen, da kommt dann aber nach der global-admin-Passworteingabe nur ne Fehlermeldung, wenn die pem-Datei drin war, meldete er success, wobei das komisch aussieht:
cp: Aufruf von stat für '/var/lib/samba/sysvol/lss-rt.de/tls/cacert.pem' nicht möglich: Datei oder Verzeichnis nicht gefunden umount: /var/lib/samba/sysvol: nicht eingehängt. Success

Ich habe auch mal auf dem Server in der ubuntu2004.cloop.macct die Zeilen

replace: supplementalCredentials
supplementalCredentials:: ... langer Key ...

gelöscht, ändert aber nichts nach dem Syncen des Clients.

Dann noch zur neuen Linbo-Version 2.3.65:
Wenn ich einen alten Client, der noch unter linuxmuster6.2 partitioniert wurde, starte (vom Netzwerk, Boot von Festplatte und UEFI komplett deaktiviert), dann startet er zwar linbo 2.3.65, gibt als Server-IP aber unser altes 10.32.1.1 an (der alte Server ist natürlich nicht mehr am Netz), lädt - obwohl der Rechner noch gar nicht aufgenommen ist - die alten start.conf-Vorgaben, bei der Eingabe des aktuellen global-admin-Passwortes bleibt er für ein paar Minuten hängen, danach fängt er sich wieder, hat das Passwort aber nicht genommen. Dann bringt mir der Wipe natürlich auch nix, erstens komm ich gar nicht zum Partitionieren, zweitens hat er ja die falschen Partitionierungsdaten!

Grüße,
Stefan

Edit:
Noch eine Ergänzung:
In der /var/log/sssd/ldap_child.log steht (ziemlich häufig):
(Fri Jul 31 09:12:02 2020) [[sssd[ldap_child[7178]]]] [lc_verify_keytab_ex] (0x0010): Principal [R00203$@LSS-RT.DE] not found in keytab [MEMORY:/etc/krb5.keytab] (Fri Jul 31 09:12:02 2020) [[sssd[ldap_child[7178]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Unable to verify principal is present in the keytab. Unable to create GSSAPI-encrypted LDAP connection.

zefanja · 31. Juli 2020 um 07:52

Das klingt alles sehr komisch. Diese Probleme gab es bei mir nicht. Ich konnte alte Clients starten und sie hatten alle die richtigen Daten (Server IP, neue start.conf etc.).

Ist dein alter Server wirklich vom Netz? Ich meine runtergefahren / ausgeschaltet? Wir hatten bei uns mal einen Fall, wo einige Lehrkräfte IPs aus einem ganz anderen Netzwerkbereich bekamen für’s WLAN. Es haben einfach 2 DHCP Server geantwortet (der richtige für den entsprechenden Netzwerkbereich und der LMN Server). Ich konnte mir das nicht erklären, habe also alle Kabel eins nach dem anderen vom Switch entfernt, um die Ursache zu finden. Schuld war am Ende ein bonded Netzwerkinterface am Virtualisierungshost.

vG Stephan

lessi · 31. Juli 2020 um 08:07

Hallo Stephan,

jep, VM ist runtergefahren, der kann definitiv nicht mehr reinfunken.

Die Server-IP ist das merkwürdige, neue start.conf kann er ja noch nicht haben, weil noch gar nicht aufgenommen, eigentlich sollte also alles leer sein, stattdessen führt er aber die alte Gruppe auf, die auf dem neuen Server gar nicht mehr existiert.

Grüße,
Stefan

baumhof · 31. Juli 2020 um 08:43

Hallo Stefan,

Die Server-IP ist das merkwürdige, neue start.conf kann er ja noch nicht
haben, weil noch gar nicht aufgenommen, eigentlich sollte also alles
leer sein, stattdessen führt er aber die alte Gruppe auf, die auf dem
neuen Server gar nicht mehr existiert.

dann nimm doch mal die Clients auf indem du die alte workstations
kopierst (wurde das nicht bei der Migration gemacht?) und die fehlenden
Spalten ergänzt.

Danach
linuxmuster-import-devices

LG

Holger

lessi · 31. Juli 2020 um 10:48

Hallo Holger,

Wir wollten absichtlich keine Migration, sondern alles neu aufnehmen, um „Karteileichen“ weg zu haben und weil wir sowieso auch einiges umräumen. Klar kann ich mir die MACs jetzt zusammensuchen (bei den Druckern komm ich da ja nicht drum rum…) oder die Clients alle „von Hand“ mit einer neuen Partitionierungstabelle versehen, aber das ist ja eigentlich nicht Sinn der Sache und ich verstehe nicht, warum beim Netzwerkboot irgendwelche alten Sachen von der Festplatte eingelesen werden müssen. Was ist denn der Nutzen davon? War das schon immer so und ich hatte bisher nur Glück?

Aber mein viel größeres Problem, weil ohne Workaround, ist die nicht funktionierende Anmeldung am Client.

Grüße,
Stefan

baumhof · 31. Juli 2020 um 11:20

Hallo Stefan,

Aber mein viel größeres Problem, weil ohne Workaround, ist die nicht
funktionierende Anmeldung am Client.

wo können sich den die Benutzer anmelden, die sich am Client nicht
anmelden können?
WebUI?

Wurden die Nutzer migriert? Oder neu erstellt?

LG

Holger

lessi · 31. Juli 2020 um 12:29

Hallo Holger,

Alles neu erstellt, nix migriert.

Sie können sich an dem (als VM auf Proxmox laufenden) Client anmelden, auf dem ich das cloop erstellt habe.
Sie können sich an der WebUI anmelden.
Sie können sich nicht an einem frisch gesyncten Klassenzimmer-PC anmelden.

Grüße,
Stefan

baumhof · 31. Juli 2020 um 12:42

Hallo Stefan,

wo können sich den die Benutzer anmelden, die sich am Client nicht
anmelden können?
WebUI?
Sie können sich an dem (als VM auf Proxmox laufenden) Client anmelden,
auf dem ich das cloop erstellt habe.
Sie können sich an der WebUI anmelden.
Sie können sich nicht an einem frisch gesyncten Klassenzimmer-PC anmelden.

das hab ich so noch nie erlebt.
Könnte es sein, dass die Netzwerkverbindung der echten Clients nicht steht?

LG

Holger

roesslerrr · 31. Juli 2020 um 13:24

Hallo Stefan!
Der Rechner, an dem du dich anmelden willst, ist aber schon aufgenommen?
Gruß - Rainer

lessi · 31. Juli 2020 um 13:25

Hallo Holger,

naja, sie haben die richtige IP und der linuxadmin kommt ins Internet…

Grüße,
Stefan