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

[maxEG]

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]

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]

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]

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]

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]

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

Linuxclient `tty` deaktiviert? login: PAM failure

Hej, ich nochmal - mit einer Kleinigkeit. Aus Gründen wollte ich mir mal einen Loginprozess auf einer tty-Textkonsole anschauen. Stellt sich raus: An den tty-Textkonsolen kann ich mich gar nicht anmelden. Wenn man Enter drückt, blitzt nur kurz diese Meldung auf: login: PAM failure, aborting: Critical error - immediate abort und das war’s. Wurden die `tty’s im 20.04er Image (dem von @Holger verteilten) deaktiviert - oder ist das ein anderes Problem? Wenn deaktiviert - Wie kann ich…

Grüße
Michael

[dorian]

Wie ist es per ssh? Geht das auch nicht?

[sedding]

Hej @dorian ,

@dorian

Wie ist es per ssh? Geht das auch nicht?

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]

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:

@sedding

lpadmin -p LZ-DRUCKER -E -v ipp://SERVER/printers/LZ-DRUCKER -m everywhere -u allow:lem

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

VG, Dorian

[sedding]

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]

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]

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]

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

1. Drucker auf dem Server-CUPS deinstalliert
2. Zur Sicherheit ein systemctl restart cups.
3. Loginversuch mit betroffenem Login: Läuft zwar ohne Hänger durch, aber die Fehlermeldungen sind immer noch da.
4. Drucker wieder installiert
5. 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]

@sedding

Das linuxmuster-linuxclient-Skript machen ja auf jeden Fall eine ipp://-Verbindung. Ist das ein Problem?

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]

@maxEG

wie hast Du das mit dem ssh hinbekommen? Dann muss ich nicht lange suchen…

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

[dorian]

@maxEG

Warum macht der Linuxclient überhaupt Drucker, wenn er doch den Cups vom server nutzt?

Mit lpadmin werden einfach die Cups drucker am client eingerichtet. Deshalb steht ja bei der IP auch die vom Server.

@maxEG

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).

Kann man auch so machen, ist halt für manche zu unflexibel.

VG, Dorian

[sedding]

Hallo zusammen,
ich denke, ich konnte das Problem lösen. Die Zusammenfassung hier:

Danke @maxEG für deine Nachfrage, die hat mir zu denken gegeben…
Wir machen das ja auch ohne GPOs und deshalb habe ich schon gar nicht verstanden, was da schief läuft.
Zudem hat die eine betroffene Kollegin, die hier auch mitliest, mich darauf hingewiesen, dass ihr ein Druckerfehler aufgefallen war - beim letzten Mal, als sie sich anmelden konnte.

Eine vage Erinnerung und eine Suche hier im Forum brachte mich auf diesen Thread:

Das Killen und Neuanlagen der default-GPOs hat die Anmeldeprobleme behoben…

Fehler "error mounting share..." bei Project-Order

Hi Andreas, Nein, ich glaube nicht, das Problem löst das nur, wenn man nach dem Update zusätzlich noch sophomorix-school --gpo-kill default-school sophomorix-school --gpo-create default-school ausführt. @jeffbeck Stimmt das? VG, Dorian

Mannomann. Was für ne Geburt…

Danke @dorian für die Hilfe.

Grüße
Michael

[sedding]

Nachtrag:

Das ist natürlich nur Symptombehandlung… Wieso der Fehler auftrat, kann ich nicht sagen - und ich hoffe, dass das nicht zu oft vorkommt. Denn jedes Mal die GPOs killen (und dann die Drives.xml erneut editieren…), ist ja auch nicht Sinn der Sache.

Grüße
Michael

[martin.res]

Hallo zusammen,
bei uns an der Schule (bei maxEG) wird an den Linux-Clients nicht der lokale CUPS sondern der Server-CUPS direkt verwendet. Damit funktioniert aber dann das login-Script, das die im AD eingetragenen Drucker lokal installierten will (für die Kollegen, die per Schulkonsole einen Drucker aktiviert haben) nicht mehr, da der aufgerufene lpadmin-Befehl direkt am Server landet und dann eine Passwort-Eingabe erfordert … das login-Script und der ganze Bildschirm friert nun beim Anmelden ein.
Als Workaround habe ich das Login-Script für die Drucker angepasst
siehe: anwenderwiki:linuxclient:linuxclient7 [CommunityWiki]
@dorian: Könnte man das printers.py-Script nicht grundsätzlich mit einen timeout beim lpadmin-Befehl anpassen, da das Problem mit dem lpadmin-Befehl leider nicht mit einer exception verarbeitet werden kann?
Grüße
Martin

[dorian]

Hallo Martin,

3. Lösung: Einfach in der Printers.xml GPO disabled=1 setzen (siehe linuxmuster-linuxclient7/gpo.py at 19e41e02aae7409baec47a1a5f8a9caaae414ea8 · linuxmuster/linuxmuster-linuxclient7 · GitHub)
4. Lösung: Die Printers.xml GPO löschen (siehe linuxmuster-linuxclient7/gpo.py at 19e41e02aae7409baec47a1a5f8a9caaae414ea8 · linuxmuster/linuxmuster-linuxclient7 · GitHub)

Bitte nicht als „Lösung“ im Wiki schreiben, dass man Sourcecode verändern soll! Dieser wird bei jedem Update überschrieben.

@martin.res

Könnte man das printers.py-Script nicht grundsätzlich mit einen timeout beim lpadmin-Befehl anpassen, da das Problem mit dem lpadmin-Befehl leider nicht mit einer exception verarbeitet werden kann?

Könnte man. Ich bin zur Zeit leider mit dem refactoring und dem Port zu Qt6 der Linbo-Gui komplett ausgelastet. Aber wenn du möchtest, kannst du gerne eine PullRequest erstellen, ich schaue sie mir gerne an

VG, Dorian