Einzelne (!) Kolleginnen können sich nicht mehr einloggen (linuxclient7)

sedding · 21. Oktober 2021 um 20:57

Hej, ich habe hier mal wieder ein ziemlich schräges Problem…

Es kamen in den letzten Tagen/Wochen einzelne Kolleginnen (inzwischen sind es 3), die nicht mehr bis zum Desktop des linuxmuster-linuxclients7 kommen. Nach der (korrekten) Eingabe von Benutzername und Passwort erscheint noch Verzeichnis "/home/kuerzel" wird erstellt, aber dann geht’s nicht mehr weiter. Der Bildschirm bleibt ubuntu-lila und fertig.

Wir hatten solche Symptome schon mal, als wir versucht haben, unseren alten adsso-client zu migrieren: Fragen zum neuen Anmeldescript für Linuxclients (linuxmuster-linuxclient7) - #107 von sedding
Den Tipp veyon zu deinstallieren, habe ich damals schon probiert - ohne Erfolg.

Damals wie heute stehen im Log viele Zeilen --- x11vnc loop: sleeping 2000 ms --- .
Soweit so schlecht.

Aber - und das ist das Schräge - das Problem tritt nur bei einzelnen Accounts auf. Als eine der drei betroffenen Kolleginnen mir das gezeigt hat, konnte ich mich am gleichen Rechner mit meinem eigenen AD-Account problemfrei anmelden (Strg+Alt+F1 brachte mich zurück zum Loginscreen). Die Betroffenen können sich dagegen an keinem Client anmelden… Scheint also irgendwie mit dem Account zusammenzuhängen?!? Am Image liegt es jedenfalls auch eher nicht. Das Problem besteht bei einer Kollegin nun schon seit Wochen - zwischendrin habe ich mehrere Images ausgerollt…

Hat irgendjemand eine Idee, woran das liegen könnte, oder wenigstens, wo ich mit der Recherche ansetzen kann?

Grüße
Michael

maxEG · 21. Oktober 2021 um 21:09

Hallo!
Genau das gleiche Problem bei genau einer Kollegin (Kürzel „dic“, Martin meinte, das könnte ggf. was damit zu tun haben?), gleiche Zeilen im Log… Sonst dort nichts auffälliges, die Laufwerke werden gemountet usw.
Angeblich schon seit Beginn des Schuljahres, sie ist nicht oft an unserer Schule. Moodle geht, Schulkonsole anmelden geht, nur der linuxclient nicht…
Beim letzten Versuch gestern (ich hatte /Einstellungen geleert, um das auszuschließen), kamen wir bis kurz nach dem lila Screen zu einem Mauszeiger, dann gab es einen freeze. Andere Nutzer können sich (außer beim freeze) problemlos anmelden… Es liegt wirklich am Benutzeraccount bzw. irgend einer Interaktion mit dem Client…
LG
Max

sedding · 21. Oktober 2021 um 21:31

Hmm. Also nicht nur ein Einzelproblem meiner Installation…

Bei den Kürzeln der betroffenen Kolleginnen kann ich kein Muster erkennen.
Eine Kollegin ist ziemlich häufig im Computerraum. SIe konnte den Zeitraum, ab dem es nicht mehr funktioniert hat, auf wenige Tage festmachen. In ihrem Serverhome ist - soweit ich das sehe - nichts im betreffenden Zeitraum passiert.

Mist. Ich erkenne insgesamt kein Muster (Außer, dass es alles Kolleginnen sind… )

Grüße
Michael

maxEG · 21. Oktober 2021 um 21:34

hm, das wird es sein…
Bei meiner Kollegin hat der Login noch nie funktioniert…
Ich denke, ich werde ihr einen neues Konto verpassen, das ist das Einfachste.

LG
Max

sedding · 21. Oktober 2021 um 21:47

Hej Max,

Das habe ich bei der ersten auch gedacht
Der haben wir schnell ein weiteres „dummy“-Konto angelegt, damit sie arbeiten kann.

Aber das löst das Problem ja nicht wirklich… Wie gesagt, bei mir sind es inzwischen schon 3 Personen, von denen ich weiß, dass sie sich nicht mehr einloggen können… eine Dunkelziffer könnte es ja auch noch geben…

Wirst Du ihr ein komplett neues Konto geben - also mit anderem Benutzernamen?
Grüße
Michael

maxEG · 21. Oktober 2021 um 21:59

Hallo Michael,
ja, ich bin vor ein paar Jahren auf Komplettnamen statt Kürzel umgestiegen, da sich viele Kollegen im Lehrerzimmer nicht abgemeldet hatten und oft nicht wusste, wer das jetzt genau ist. Wir haben echt schräge Ähnlichkeiten und die Kürzel sind dann absolut unintuitiv.
Also: Alle alten sind kurz, die neueren lang…
LG
Max

alois · 22. Oktober 2021 um 06:09

Mal wieder ins Blaue. Kann es sein, dass es sich bei den Kürzeln um reservierte Wörter handelt, wie z. B. „man“ oder „con“?

Gruß Alois

Michael · 22. Oktober 2021 um 07:27

Seid ihr sicher, dass das kein Problem mit dem Passwort sein kann?
… vielleicht hängt es mit dem mounten der Laufwerke zusammen … irgendein verbotenes Sonderzeichen evtl.?

sedding · 22. Oktober 2021 um 07:59

Hej Michael,
Das ist es m.E. leider nicht. Ich habe gerade das Passwort auf etwas einfaches (Groß/Kleinbuchstaben+ Ziffer) geändert und das Problem ist immer noch da.

War auch unwahrscheinlich. Die Kollegin, welche den Zeitpunkt des ersten Auftretens relativ genau sagen konnte, meinte sie hätte ihr Passwort nicht verändert.

Hmmm.
Grüße
Michael

dorian · 22. Oktober 2021 um 08:19

Hi @sedding

Probier mal bitte den Login auf einer Textkonsole oder per ssh. Dann müsstest du sehen, wo er hängen bleibt.

VG, Dorian

sedding · 22. Oktober 2021 um 08:30

Hej Dorian,
ich würde, wenn ich könnte:

Grüße
Michael

dorian · 22. Oktober 2021 um 11:12

Wie ist es per ssh? Geht das auch nicht?

sedding · 24. Oktober 2021 um 13:13

Hej @dorian ,

Wenn ich auf dem betreffenden Client die ssh-Authentifizierung per Passwort für die entsprechenden Userin erlaube, komme ich per ssh drauf.

Die Ausgabe ist wirklich aussagekräftiger! Das Problem hängt offensichtlich mit einem Drucker zusammen…

Relevante Auszüge der Konsolenausgabe:

...
[INFO] ==> Successfully parsed a drive policy! ==
[INFO] == Parsing a printer policy! ==
[DEBUG] Testing filter: {'name': 'brother-hl2070n', 'bool': 'AND', 'userContext': '1', 'type': 'FilterGroup'}
[DEBUG] Testing filter: {'name': 'brother-hl2070n', 'bool': 'OR', 'userContext': '0', 'type': 'FilterGroup'}
...
[DEBUG] Testing filter: {'name': 'lz-drucker', 'bool': 'AND', 'userContext': '1', 'type': 'FilterGroup'}
[DEBUG] Testing filter: {'name': 'lz-drucker', 'bool': 'OR', 'userContext': '0', 'type': 'FilterGroup'}

[INFO] Found printers:
[INFO] * LZ-DRUCKER		| ipp://SERVER/printers/LZ-DRUCKER	| [{'name': 'lz-drucker', 'bool': 'AND', 'userContext': '1', 'type': 'FilterGroup'}, {'name': 'lz-drucker', 'bool': 'OR', 'userContext': '0', 'type': 'FilterGroup'}]
[DEBUG] Installing Printer LZ-DRUCKER on ipp://SERVER/printers/LZ-DRUCKER
[DEBUG] * running 'lpadmin -p LZ-DRUCKER -E -v ipp://SERVER/printers/LZ-DRUCKER -m everywhere -u allow:lem'

Dann geht’s nicht mehr weiter. Nach STRG+C kommt die zugehörige Fehlermeldung (und die Anmeldung läuft weiter durch.

* Error installing printer LZ-DRUCKER on ipp://SERVER/printers/LZ-DRUCKER!
[FATAL] * Error installing printer LZ-DRUCKER on ipp://SERVER/printers/LZ-DRUCKER!

OK. Also ein Drucker/Cups-Problem… Soweit kapiere ich es.
Aber wieso tritt das auf?
Und wie komme ich (resp. die Kollegin) da wieder raus?

Viele Grüße
Michael

dorian · 24. Oktober 2021 um 13:36

Hi Michael,

Hmm interessant …
Schwierig zu sagen, was das das Problem ist, die Fehlermeldung ist nicht so aussagekräftig. Führ den Befehl doch mal auf der Konsole aus:

Scheinbar hängt der sich einfach auf, die Frage ist nur weshalb das passiert…

VG, Dorian

sedding · 24. Oktober 2021 um 14:00

Hej,
ja, interessant.
wenn ich den Befehl auf der Konsole ausführe, sieht das so aus:

lem@r118-imagenuc:~$ lpadmin -p LZ-DRUCKER -E -v ipp://SERVER/printers/LZ-DRUCKER -m everywhere -u allow:lem
Passwort für lem auf 10.16.1.1?  *************
Passwort für lem auf 10.16.1.1?  *************
     [...  Habe hier das AD-Passwort des users probiert
           und dann mit STRG+C abgebrochen.]
lpadmin: Nicht berechtigt

Das ist ja schon cups auf dem Server,der da nach dem Passwort fragt…? Dann kann es ja nicht das AD-Passwort des users sein…? Kann das überhaupt gehen?

Zum Vergleich übrigens: Bei ssh-Login mit einem Account ohne das Problem sehe ich den lpadmin-Befehl nicht in der Konsolenausgabe.
Nach [INFO] Found printers: kommt direkt: INFO] ==> Successfully parsed a printer policy! ==

Wird lpadmin bei „problemfreien“ Accounts gar nicht ausgeführt, oder läuft der einfach fehlerfrei durch…?

Weitere Ideen, wie ich testen kann…?
@maxEG ist da bei dir das gleiche Problem?

Grüße
Michael

sedding · 24. Oktober 2021 um 14:03

Was ich auch nicht verstehe:
Wir haben da 6 Drucker, die (jeweils mit zwei Zeilen) unter [DEBUG] Testing filter aufgeführt werden.
Warum gibt es das Problem mit dem lpadmin-Befehl nur mit einem Drucker?

Grüße
Michael

dorian · 24. Oktober 2021 um 15:16

Hi Michael,

Ich hatte das auch mal. Das war ein Problem mit dem Cups server. Ich habe einfach den Drucker gelöscht und neu erstellt (auf dem Server), dann ging es wieder.

VG, Dorian

sedding · 24. Oktober 2021 um 16:55

Hej,
hab’s getestet. Das hat leider nichts gebracht.

Drucker auf dem Server-CUPS deinstalliert
Zur Sicherheit ein systemctl restart cups.
Loginversuch mit betroffenem Login: Läuft zwar ohne Hänger durch, aber die Fehlermeldungen sind immer noch da.
Drucker wieder installiert
Loginversuch mit betroffenem Login: Hängt wieder wie zuvor.

Beim Löschen und Wiederanlegen ist mir aufgefallen: Wir steuern die Drucker ja über socket:// an (wie hier beschrieben).
Das linuxmuster-linuxclient-Skript machen ja auf jeden Fall eine ipp://-Verbindung. Ist das ein Problem?

Nur eine Auffälligkeit… Erklärt ja alles nicht, warum die Anmeldung nur bei einzelnen KuK nicht funktioniert…
Grüße
Michael

maxEG · 24. Oktober 2021 um 19:58

Hallo!
Ich konnte es noch nicht probieren, die Kollegin mit dem Account ist sehr selten da und ihr Passwort hab ich nicht ausgeliehen.
Warum macht der Linuxclient überhaupt Drucker, wenn er doch den Cups vom server nutzt? Ich habe das jedenfalls unter /etc/cups/client.conf: ServerName 10.16.1.1 so eingestellt… Nix mit GPO und so (keine Zeit, kein Windows).
@sedding wie hast Du das mit dem ssh hinbekommen? Dann muss ich nicht lange suchen…
LG
Max

sedding · 24. Oktober 2021 um 20:08

Als root kommt man über pubkey auf den Client.
Also vom Server aus ssh root@clientname-oder-ip
Dann dort die /etc/ssh/sshd_config editieren.

Auf die schnelle taten’s bei mir zwei Einstellungen:

AllowUsers root@10.16.1.1 linuxadmin@10.16.1.1 weitereuser@10.16.1.1
PasswordAuthentication yes

ssh neu starten und gut.

schnelle Grüße
Michael