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
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
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.?
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
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
Hej Dorian,
ich würde, wenn ich könnte:
Grüße
Michael
Wie ist es per ssh? Geht das auch nicht?
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
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
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
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
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
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
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
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
Mit lpadmin werden einfach die Cups drucker am client eingerichtet. Deshalb steht ja bei der IP auch die vom Server.
Kann man auch so machen, ist halt für manche zu unflexibel.
VG, Dorian
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…
Mannomann. Was für ne Geburt…
Danke @dorian für die Hilfe.
Grüße
Michael
2 „Gefällt mir“
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
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
1 „Gefällt mir“
Hallo Martin,
- Lösung: Einfach in der Printers.xml GPO disabled=1 setzen (siehe linuxmuster-linuxclient7/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/gpo.py at 19e41e02aae7409baec47a1a5f8a9caaae414ea8 · linuxmuster/linuxmuster-linuxclient7 · GitHub)
- Lösung: Die Printers.xml GPO löschen (siehe linuxmuster-linuxclient7/usr/lib/python3/dist-packages/linuxmusterLinuxclient7/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.
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