Anmeldeproblem Linuxclient v7 nach Update des Clients

Hallo,
wir haben bei unserem Linuxclient ein kleines Update gemacht (etwas Software nachinstalliert) und das Image hochgeladen (alles aus der Schulkonsole raus per GUI).
Jetzt geht die Anmeldung nicht mehr.

Ich erinnere mich, dass man ggf. eine macctt Datei o.ä. löschen muss?

Bisher hatte das bei uns (mehr als 1 Jahr lang) immer gut funktioniert, deswegen bin ich nun total ratlos.

Die Clients bekommen ihre IP und die korrekte Systemzeit per Linbo, so viel kann ich sehen.

Sorry für die unpräzise Frage, ich weiß nicht, wo ich ansetzen soll.
Gruß,
Andreas

HI Andreas,

Nach meiner Erfahrung löst ein linuxmuster-cloop-turnkey mit anschließendem neuen Image das Problem.
(Als linuxadmin ausführen)

VG, Dorian

Hallo Andreas,

Ich erinnere mich, dass man ggf. eine macctt Datei o.ä. löschen muss?

nein.
Man darf nur nicht den Client, mit dem zuletzt der Domänenbeitritt
gemacht wurde, aus der devices.csv löschen oder ihn umbenennen.

LG

Holger

Sehr gut - auf dem Client, mit sudo ? Danach das Image aus Linbo heraus hochladen? Danke!

Das hat es bei mir immer behoben :slight_smile:
(Image erstellen nicht vergessen ;))

1 Like

Ich muss jetzt wirklich nochmal ganz ganz dumm fragen - wo liegt dieses Skript? Auf dem Server oder auf dem Client, falls auf dem Client, wo? Sorry, ich mache sonst immer alles über die GUI, bin gerade völlig lost.

Das liegt auf den Client. Du musst dich dort nur als linuxadmin anmelden und in der Konsole sudo linuxmuster-cloop-turnkey ausführen.

VG, Dorian

Auf unserem Client gibt es den Befehl nicht. Wann wurde der eingeführt, was muss ich ggf. nachinstallieren?
Auf unserem Client (wir waren ganz früh dabei mit V7) gibt es nur linuxmuster-client-adsso-setup und linuxmuster-distupgrade mit dem Anfang „linuxmuster“.

Hi.
Ohne 100%ig sicher zu sein: Ich glaube, dass dieses Problem mit einem der letzten Samba-Updates reingekommen ist. Ich habe auf dem Focal Fossa Client zumindest das gleiche Problem: Letzte laufende Version war ein Image vom 28. Januar – irgendwann danach kam ein größeres Update. Danach lief hier die Anmeldung nicht mehr.

Das blöde ist, dass man das uU gar nicht merkt, wenn es das Userprofil auf dem Cient bereits oder noch gibt – denn dann konnte ich mich problemlos anmelden (und kann es evtl nur merken, wenn ich darauf achte, ob Home_auf_Server und Tausch_auf_Server ordnungsgemäß eingebunden wurden?!)

Viele Grüße,
Michael

Das sollte es auch tun.

Um das vorzubeugen, passe ich immer vor dem Erstellen eines Images auf, dass es keine gecachten Benutzer mehr gibt, bzw. lösche sie ggf.

VG, Dorian

Ich habe mir angewöhnt, immer bevor ich ein Image erstelle, linuxmuster-cloop-turnkey auszuführen. Mache ich es nicht, zerschlägt es mir die Anmeldung auch regelmäßig, aber wenn man das vorm Erstellen immer macht, klappt es eigentlich immer.

VG, Dorian

1 Like

(Das sollte vielleicht auch in die Doku, oder?)

Ja, allerdings wüsste ich dann auch gerne, wo ich den neueren turnkey-Befehl herbekomme (linuxmuster-distupgrade ? ), denn das adsso macht ja nochmal eine komplette Domänenaufnahme, was umständlich ist.
Besser wäre es natürlich, der Client würde das automatisch machen beim Image erstellen, aber ich vermute mal, dass (weil linbo ja letztlich ein anderes System ist) das nicht geht.

Ich denke, das sollte es tun :slight_smile:
EDIT: der turnkey Befehl macht aber auch immer eine neue Domänenaufnahme

Ich habe hier:

[root@vm-fossa:~]$ apt search linuxmuster-
Sortierung... Fertig
Volltextsuche... Fertig
linuxmuster-client-adsso/now 0.9-3bionic all  [Installiert,lokal]
  linuxmuster.net client configuration scripts for ad sso

Und Du?

Ich habe das Problem, dass ich eingeschneit zu Hause sitze und das, wenn überhaupt, nur anhand meiner Testumgebung testen kann. Ein Kollege ist in der Schule, der hat aber noch anderes zu tun.
Das, was in meiner Testumgebung fehlt, ist aber der turnkey-befehl.

Nachtrag – ich habe das Update auf der VM gerade nochmal angeworden … es ist so, dass da u.a. die Pakete

Holen:159 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-proxy amd64 2.2.3-3ubuntu0.3 [34,6 kB]
Holen:160 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-ldap amd64 2.2.3-3ubuntu0.3 [31,1 kB]
Holen:161 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-krb5 amd64 2.2.3-3ubuntu0.3 [13,6 kB]
Holen:162 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-ipa amd64 2.2.3-3ubuntu0.3 [211 kB]
Holen:163 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-common amd64 2.2.3-3ubuntu0.3 [1.029 kB]
Holen:164 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-krb5-common amd64 2.2.3-3ubuntu0.3 [75,9 kB]
Holen:165 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd amd64 2.2.3-3ubuntu0.3 [4.228 B]
Holen:166 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-ad amd64 2.2.3-3ubuntu0.3 [116 kB]
Holen:167 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 sssd-ad-common amd64 2.2.3-3ubuntu0.3 [67,7 kB]

aktualisiert werden … daher denke ich, dass die anschließenden Anmeldeprobleme von diesen Updates kommen könnten! Oben hatte ich samba geschrieben … ich meinte aber diese Pakete…

… also ich rate mal weiter: Bei der Installation der Pakete wird gemeldet:

Neue Version der Konfigurationsdatei /etc/apparmor.d/usr.sbin.sssd wird installiert ...
Warning: found usr.sbin.sssd in /etc/apparmor.d/force-complain, forcing complain mode
Warnung aus /etc/apparmor.d/usr.sbin.sssd (/etc/apparmor.d/usr.sbin.sssd Zeile 59): Warning failed to crea
te cache: usr.sbin.sssd

Kann’s das sein?

Hallo,

Ja, allerdings wüsste ich dann auch gerne, wo ich den neueren
turnkey-Befehl herbekomme

der ist schon drauf.
Einfach im Terminal
sudo linuxmuster-client-turnkey
ausführen.

Ich habe hier:

[root@vm-fossa:~]$ apt search linuxmuster- Sortierung… Fertig
Volltextsuche… Fertig linuxmuster-client-adsso/now 0.9-3bionic all
[Installiert,lokal] linuxmuster.net client configuration scripts for ad sso|

da ist turnkey dabei.

LG

Holger

habe ich gerade auch nochmal nachgesehen – hier der Beweis:
Screenshot_20210211_163110
Die Scripte liegen unter /usr/sbin auf dem Client!