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
Hi Zusammen,
Ich hab nochmal überlegt und ich denke, folgendes ist die beste Lösung:
Wenn man Drucker nicht wie vorgesehen jnstallieren will, sollte man sie in der Geräteverwaltung als „ip-only“ eintragen.
Dann gibt es keine GPO und das Problem tritt nicht auf.
VG, Dorian
Hallo,
die Anmeldung am Linuxclient sollte auch bei falscher Konfiguration auf keinen Fall zu einem Freeze führen, sondern evtl. nur zu fehlender Druckerkonfiguration. Deshalb sollte das Anmelde-Script - soweit es geht - flexibel sein und auf viele mögliche Konfigurationen reagieren können. Nicht jeder Systembetreuer an Schulen hat den Überblick über alle Einstellungen an seinem System.
An den Schulen gibts inzwischen auch viele verschiedene Typen von Clients: in Computerräumen, in Klassenzimmern, Lehrerzimmer, Laptopwägen, Verleihgeräte, Messcomputer, Kiosk-PCs, Video-PCs, …
Da kann natürlich auch der Fall auftreten, dass man bei manchen GPOs möchte und bei manchen eben nicht.
Grüße
Martin
2 „Gefällt mir“
Hi Martin,
Das ist klar. Aber das wird deine PR ja fixen.
Eine falsche Konfiguration sollte in jedem Fall auch zu einer Fehlermeldung führen, sonst ist es schwer zu debuggen, wenn die Konfiguration nicht (wie in deinem Fall) absichtlich fehlerhaft ist.
Dann darf man diese Clients im AD nicht in Druckergruppen einschreiben.
VG, Dorian
Hej,
Das habe ich nun mal so laufen gehabt, aber die Printers.xml wird wohl doch öfter neu gesetzt, als ich dachte. Ich ging davon aus, dass das nur bei linuxmuster-import-devices neu geschrieben wird…(?)
Habe jetzt deshalb diesen Weg begangen:
Nur kurz als Korrektur: die Sophomorix-Rolle heißt iponly - ohne Bindestrich.
Grüße
Michael
Ok. Die Lösung mit den Druckern als iponly hat nur eine Viertelstunde gehalten. Dann kamen die ersten, die sagten, es seien keine Drucker mehr verfügbar.
Ich bin nun wieder zurück auf dieser „Lösung“:
Grüße
Michael