Druckermoderation

UCS@school
#1

Hallo,

wir haben ein Problem mit der in UCS@School angebotenen Druckermoderation in der UMC.

Unser System Master-Slave-Umgebung besteht aus Master UCS4.0.4 errata 397 mit UCS@school 4.0 R2 v6 und mehrere Schulstandorte mit jeweils 1 DC-Slave 4.0.4 errata397 und UCS@School 4.0 R2 v6 mit Samba4 für EDU und GOV.
Die EDU-DC-Slave sind u.a. auch als Druckserver für die Schule eingerichtet.
Als Drucker wurde der pdf-Drucker - auf den alle Zugriff haben - und Netzwerkdrucker - nur Lehrer haben Zugriff - installiert.

Unsere Clients sind zu 99% Kubuntu 14.04 mit Domänenanmeldung und den EDU-DC-Slave als Druckserver eingerichtet - cups-browsed.conf.

Wenn der Schüler ga-schueler sein Dokument mit dem pdf-Drucker druckt, wird das pdf in /var/spool/cups-pdf/ga-schueler als job_xxx-ga-schueler.pdf abgelegt und in der UMC->Drucker moderieren (Anmeldung als ga-lehrer) FALSCH gelistet:
Benutzer ga-schueler, Druckauftrag ga-schueler …

Nach Änderung der cups-pdf.conf auf dem DC-Slave -> TitlePref 1 gesetzt - wird der Druckauftrag richtig abgespeichert job_xxx-testdoku.pdf und in der UMC richtig angezeigt.

Wenn der Lehrer für diesen Druckauftrag ‘testdoku’ vom ga-schueler in der UMC einen Drucker(restricted Drucker) auswählt, schlägt dieser fehl - Druckauftrag bleibt im spool.

Laut management-console-module-printermoderation.log wird der Druckbefehl wie folgt ausgeführt:

lpr -P >Druckerwarteschlange> -U ga-schueler -J testdoku -r /var/spool/cups-pdf/ga-schueler/job_xxx-testdoku.pdf -H >Druckserver DC-Slave

Der ga-schueler hat aber keinen Zugriff auf diese Druckerwarteschlange.
Führe ich den lpr-Befehl auf der Konsole mit -U ga-lehrer aus, wird der Auftrag gedruckt.

Mir scheint, dass in der UMC bei Drucker moderieren -> Druckauftrag auswählen -> Button Drucken -> Drucker auswählen -> Drucken der in der UMC angemeldete User nicht dem lpr-Befehl übergeben wird.

Wo liegt der Fehler???

Gruss
Detlef Stang

#2

Hat keiner einen Vorschlag. :-((

#3

Moin,

ich nutze die Druckermoderation selber zwar nicht, habe mir eben aber mal kurz den Quellcode dazu angesehen (Datei »/usr/share/pyshared/univention/management/console/modules/printermoderation/init.py« aus dem Paket »ucs-school-umc-printermoderation«). In der Funktion »printit« ist ziemlich klar ersichtlich, was da passiert:

[ul][li]Das Hash »request.options« enthält einen Key »username«. Dieser ist laut Kommentar zur Funktion der Besitzer des Printjobs, bei Ihnen also »ga-schueler«.[/li]
[li]Dem lpr-Befehl wird als Argument zu »-U« der Wert von »request.options[‘username’]« übergeben, also der Besitzer des Printjobs.[/li][/ul]

Meine Interpretation ist hier, dass die Intention ist, dass ein Druckjob von einem Lehrer freigegeben werden muss. Wird er freigegeben, so soll der Druckjob aber weiterhin unter dem Benutzer des Schülers im Drucksystem verbleiben, damit u.a. das Accounting überhaupt funktionieren kann.

Was Sie aber wollen, beißt sich vermutlich mit den technischen Möglichkeiten. Wenn hier anstelle des Benutzers »ga-schueler« der gerade angemeldete UMC-User, also der Lehrer, benutzt wird, so würde der Druckjob anschließend als Besitzer den Lehrer haben, und die dabei verursachten Druckseiten würden dem Lehreraccount zugeschlagen.

Mir ist nicht bekannt, dass das CUPS eine Trennung von »Benutzer zur Authorisierung des Requests« und »Besitzer des Jobs & Verursacher der Druckkosten« überhaupt unterstützt. Daher denke ich nicht, dass das, was Sie wollen, umsetzbar ist.

Sie können natürlich trotzdem in der Forge einen Feature-Request hierfür eröffnen.

Gruß,
mosu

#4

Hallo,

vielen dank erstmal.
Soweit habe ich noch nicht in den Quellcode geforscht.
Das hört sich alles plausibel an, ABER:

In UCS 2.4 hat dies alles so funktioniert, ist also nicht neu.
Wir haben noch parallel die letzten Schulen an einem alten UCS2.4 Master-Slave-System, seit 2010 in Betrieb, laufen.

Die Schule, die es jetzt betrifft haben wir vor Kurzem in unser neues UCS4.0.4 Master-Slave-System - mit Neuinstallation DC-Slave, Clients auf Kubuntu14.04 usw. - migriert/ausgerollt. Die Schule möchte natürlich die Funktionen, die ihnen die letzten Jahre zur Verfügung standen, im neuen UCS4.0-System wiederfinden. Leider ist dem nicht so.

Ich habe mal auf die Schnelle den alten Server reaktiviert, am alten Master angebunden und das Szenario zur Sicherheit durchgespielt.
Im Anhang habe ich mal dies per Screenshot dargestellt - Druckermoderation_UCS24.pdf (224 KB).

Leider habe ich im alten UCS2.4-DC-Slave noch nicht die Stelle gefunden, die den Druckbefehl ausführt bzw. geloggt wird.

Dies ist also kein neues Feature.

Gruss
Detlef Stang

#5

Damals unter UCS 2.4 mußte man sich ja auch noch nicht gegenüber CUPS Authenfizieren. Ich kenne mich mit UCS@School nicht aus, aber was ist die Ausgabe von

ucr get cups/automaticrestrict
ucr get cups/restrictedprinters
#6

Hi,

da zurzeit alle Drucker freigegeben sind - nichts.

Ich habe 1 Drucker unter Drucker -> Druckername (BH106-Lexmark) ->Zugriffskontrolle -> Zugriff für ausgewählte Benutzer/Gruppen verweigern. -> Zugelassene/abgewiesene Gruppen -> schueler-xxx aktiviert.
Auf den Clients wird dieser nicht mehr angezeigt.

Variable
cups/automaticrestrict:
cups/restrictedprinters: BH106-Lexmark

#7

Ich würde dann mal folgendes testen:

ucr set cups/automaticrestrict='no' cups/restrictedprinters=''
/etc/init.d/cups restart
#8

Damit funktioniert die Druckermoderation, weil es keine ‘restricted’ Drucker gibt, die Schüler auf alle Drucker Zugriff haben und benutzen können :-((
Sie können auch direkt vom Client auf diese Drucker drucken und auch jeden x-beliebigen Drucker wählen, der in einem anderen Raum steht.

#9

Also zumindest unter einem normalen UCS kann man ja ACLs für Drucker anlegen. Seit UCS 3.irgendwas werden diese Drucker dann automatisch in die UCR-Variable cups/restrictedprinters aufgenommen. Dies bewirkt, daß für die Drucker eine Authenfizierung erforderlich ist, was speziell an Linux-Clients Probleme machen kann. Ich kann mir vorstellen, daß dein Problem auch daher kommt.

Unter UCS 2.4 gab es keine Authenfizierung für Drucker, so daß natürlich Spoofing theoretisch möglich war. Ich weiß nicht wie das in UCS@school im Detail funktioniert, aber so wie ich das verstehe soll der Lehrer genau das tun: Die Identität des Schülers übernehmen.

#10

Die Linux-Clients machen das, was sie sollen. Sie benutzen den DC-Slave als Druckserver, bei restricted Druckern werden diese auch nicht angezeigt. Es soll nur der PDF-Drucker verwendet werden, pdf’s werden auch auf dem DC-Slave ‘erzeugt’ und an der richtigen Stelle gespeichert und werden in der Druckermoderation auch richtig gelistet.

Die Druckermoderation soll wie im UCS@school Handbuch für Lehrer http://docs.software-univention.de/ucsschool-lehrer-handbuch-4.0R2.html#lehrerdoku:druckermod funktionieren.
Die Drucker wurden lt. UCS@school Handbuch für Administratoren http://docs.software-univention.de/ucsschool-handbuch-4.0R2.html#school:setup:cli:printers angelegt und natürlich noch die Treiber eingerichtet.
Von Zugriffskontrolle und deren Auswirkung auf die Benutzung der Druckermoderation ist dort leider keine Rede.

#11

Hallo,

hier die abschliessende Antwort zu dem genannten Problem:
Das Problem war auch bei Univention bekannt, wurde bearbeitet und ist mit UCS@school-Update 4.1 R2 v7 gelöst.

forge.univention.org/bugzilla/s … i?id=41374
docs.software-univention.de/chan … moderation

Gruss
Detlef Stang

Mastodon