Benutzerzugriff auf Files in der Print Queue

Hallo alle zusammen,

also ich bin mit meinem Latein am Ende ;-)

Also ich habe hier ein SuSE 9.1 als Server laufen mit einem aktuellen Samba und Cups als Drucksystem ...

Windowsuser drucken so : Client -> Samba -> Cups -> Netzwerk-Drucker

Linuxuser drucken so : Client -> Cups -> Netzwerkdrucker

Das klappt auch alles, .... oder eben nur fast alles ...

Die Windows-User "sehen" ihren Druckjob nur ganz kurz in der Windows-Queue und dann ist er "weg" ;-)

Wenn mit dem Drucker also alles OK ist, gibt es kein Problem ... nur wenn der User seinen Job dann selber wieder abbrechen will, kommt er nicht mehr dran.

Linux User, können über die Druckerverwaltung oder KJobViewer gehen, müssen allerdings dort noch einmal Ihr Passwort eingeben um ihre eigenen Jobs zu löschen oder anzuhalten ...

In der cupsd.conf habe ich hierfür folgende Einträge gemacht :


Der Rest ist für alle benötigten IPs im Netz freigegeben, also kann es meiner Meinung nach nicht an Cups liegen ...

In der smb.conf seht z.B sowas :

Ich glaube mich erinnern zu können das es "früher" unter Windows möglich war seine Jobs aus der Queue zu löschen oder anzuhalten ...

Ich kann aber nicht genau sagen welche Versionen von Samba bzw. Cups dies noch konnten ..

Kann mir jemand einen Wink in die richtige Richtung geben ?

So long

ThomasF

Hallo Thomas,
hast du mal den Parameter

lprm command

Zum Vergrößern anklicken....

für den Drucker in der smb.conf versucht?
Gruß
Stefan

Ja, habe ich ...

Auch mit dem lpq command hab ich schon experimentiert z.B :

lpq command = lpstat -o %p

und ähnliches ... aber bisher ohne Erfolg *grummel*

Allerdings sagt testparm auch das bei aktiviertem Cups die Printer commands nicht funktionieren, daher wundert mich das nicht .

Merkwürdig finde ich allerdings das ich bei einem speziellen Drucker (HP 9000) die Jobs sehe wenn ich eine [printers] Sektion in der smb.conf nutze.
Dann aber nur unter \\Server\Drucker und "nicht" wenn ich den Drucker unter Systemsteuerung -> Drucker auswähle bzw. mit dem kleinen Druckersymbol in der Taskleiste ...

Auf dem besagten HP 4Si sehe ich in der Übersicht der Drucker unter \\Server\Drucker das ein Dokument oder mehrere in der Queue hängen aber in der Queue selber sieht man diese dann wieder nicht ...

Es ist echt zum Verzweifeln, ich denke eigentlich das diese Funktion zu den Basics gehört, oder nicht ?

Gibt es denn hier bei dem das funktioniert ?

Ich habe hier samba-3.0.14a-0.1 und cups-1.1.20-108.22 unter SUSE 9.1 ?!?

So long

ThomasF

testparm hat da recht. Ich habe auch noch nie die Drucker im Samba eingetragen ich gehe immer nur über cups. Das einzige was ich in der smb.conf habe ist die Freigabe print$ für die Drucketreiber. Ich habe so bei einm Kunden (dort läuft samba 3.0.14) ca. 20 Drucker eingerichtet und es klappt alle auch jobs löschen. Ich habe die Druckerparameter in der smb.conf aber in dem Abschnitt [global] so gesetzt. Dann mault auch testparm nicht.

print command = /usr/bin/lp -d '%p' %s; rm %s
lpq command = /usr/bin/lpstat -o '%p'
lprm command = /usr/bin/cancel '%p-%j'
lppause command = lp -i '%p-%j' -H hold
lpresume command = lp -i '%p-%j' -H resume
queuepause command = /usr/bin/disable '%p'
queueresume command = /usr/bin/enable '%p'

Zum Vergrößern anklicken....

Ok,
danke schon mal für die Info

Ich werde das direkt morgen früh dann mal testen ...

Ich hatte auf dem Heimweg noch die Idee in der smb.conf anstatt cups lpr einzutragen und dann die lpr commands zu setzen, da Cups ja die alten lpr Befehle anbietet ...

Aber so ein Kunstgriff sollte im Normalfall einfach nicht nötig sein müssen ;-)

Wenn es mit den Befehlen in der global Sektion klappt ist die Sache dann wohl gegessen ...

Thx und so long

Thomas

Hmm, guten Morgen stka,

kannst Du bitte bei Dir mal schauen ob Du die commands in der smb.conf vor oder hinter dem Eintrag printing = cups stehen hast ?

Bei mir meckert testparm zumindest das print command an wenn dieses "nach" dem printing = cups steht .. wenn es davor steht hat der Eintrag gar keine Wirkung, wie man mit testparm überprüfen kann.

Die anderen Einträge wie lpq command tauchen zwar in testparm auf erzeugen aber wenn sie aktiv sind in der cups logdatei Fehler ...

Ich schreibe jetzt meine smb.conf aus der beiliegenden smb.conf.SuSE nochmal neu, vielleicht habe ich ja noch was übersehen ....

Wie sieht es bei Dir den mit der cupsd.conf aus, welche Bereiche außer /admin hast Du noch speziell angepasst ?


So long

ThomasF

Hallo Thomas,
hier mal die gesamte [global] Section

[global]
unix charset = ISO8859-15
workgroup = KANIADOM
passdb backend = ldapsam:ldap://fs1.kania-lokal.de
printcap name = /etc/printcap
logon script = kania.bat
logon path = \\%N\profiles\%U
logon drive = H:
domain logons = Yes
os level = 99
domain master = Yes
ldap server = 127.0.0.1
ldap port = 389
ldap admin dn = cn=manager,dc=kania-lokal,dc=de
ldap passwd sync = Yes
ldap suffix = dc=kania-lokal,dc=de
ldap ssl = no
admin users = @Domainadmins
printer admin = @Domainadmins
create mask = 0660
directory mask = 0770
printing = cups
print command = /usr/bin/lp -d '%p' %s; rm %s
lpq command = /usr/bin/lpstat -o '%p'
lprm command = /usr/bin/cancel '%p-%j'
lppause command = lp -i '%p-%j' -H hold
lpresume command = lp -i '%p-%j' -H resume
queuepause command = /usr/bin/disable '%p'
queueresume command = /usr/bin/enable '%p'

Zum Vergrößern anklicken....

In der cupsd.conf habe ich nur Rechte für /printers und /admin vergeben, sonst für nichts.
Der Druckjob ist ja nur eine Datei im Dateisystem, die Datei gehört immer dem Ersteller. Im Spoolverzeichnis sollten alle Benutzer immer alle Rechte haben (o=rwt). Das Programm zur Verwaltung der Druckjobs greift immer auf das Spoolverzeichnis als der Benutzer zu der den Job los geschickt hat, dadurch kann jeder Benutzer seine Jobs löschen. Den Abschnitt /jobs in der cupsd.conf benötigst du meines Wissens nach nur, wenn du bestimmte Benutzer hast, die alle Jobs verwalten sollen. Ich habe den Bereich noch nie angepasst.
Ich hoffe das hilft die weiter
Gruß
Stefan

Arrrg,

ich bekomme hier echt noch eine Krise ...

Schau doch mal auf einem Rechner mit Deiner Config in die /var/log/cups/error_log ...

Bei mir taucht dann z.B so was auf :

Wenn ich die Commands nicht drin habe ist das zumindest von der Cupsseite fehlerfrei .

Wenn ich das richtig sehe sehe ich unter Windows die Jobs auch noch solange sie im Spool Verzeichnis von Samba liegen.
Wenn Sie dann aber an Cups übergeben werden sind sie von Windows aus nicht mehr zu erreichen ...

Im Spool-Verzeichnis von Cups gibt es auf Dateiebene auch keine User mehr, sondern nur den User lp dem alles gehört ...

Ich habe jetzt schon die smb.conf komplett neu erstellt und auch die cupsd.conf aus der default.conf neu gebaut ...

Wie sieht denn Deine Sektion in Cups für / , /printers und /admin aus ?

Die /jobs brauche ich überrigens schon, wenn ich unter Linux Jobs in der Queue als User löschen möchte ...

Naja, dann probiere ich noch ein wenig rum ...

So long

Thomas

Hallo Thomas,
diese Fehlermeldung habe ich meiner error_log Datei nicht gefunden und ich habe bis Dez. 2004 zurück gesucht. Du hast Recht, wenn die Aufträge bei samba raus sind, kannst du sie unter Windows nicht mehr beeinflussen, ist bei mir auch so. Ab dem Zeitpunkt herrscht cups über den Druckjob, Aufträge lassen sich dann nurnoch über das Web-Frontend von Cups löschen. Das ganze geht so schnell das der Druckauftrag nur einmal kurz im Duckmanager unter Windows sichtbar ist.
Bei den Bereichen / /printers steht bei mir als Berechtigung "@LOCAL" für die gesamte Domäne. Bei /admin nur zwei ausgewählte IP-Adressen

ich habe jetzt mal ein bisschen mit der cupsd.conf gespielt wenn ich

<Location /jobs>
AuthType BasicDigest
AuthClass Group
AuthGroupName users
#AuthType Basic
#AuthClass User
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 127.0.0.2
Allow From @LOCAL
</Location>

Zum Vergrößern anklicken....

Eintrage und dann die Benutzer mit "lppasswd -a -g users" anlege, kann jeder Benutzer seine Druckaufträge löschen.
Ich musst e jetzt auch erst mal etwas testen und in den conf-Dateien verändern, aber deinen Fehler bekommen ich nie was immer ich auch mache.
Gruß
Stefan

Hi Stefan,

danke für die Infos, aber jetzt bin ich wieder da wo ich angefangen habe *g*

Bis in die Samba Queue konnte ich auch schon am Anfang, wie gesagt der Job taucht nur ganz kurz auf ...

Bringt ja nicht wirklich was, denn wenn der Drucker kaputt ist komme ich an den Job nicht mehr dran, bis auf das Cups-Webfontend.

Das hat auch schon ohne eine Änderung in der smb.conf geklappt !

Deshalb ja meine Vermutung das Deine Command Einträge in der smb.conf gar nicht wirklich aktiv sind ... ein lpstat -o %p würde nämlich von der Logik die Jobs in der Cups-Queue zeigen, was bei mir aber den oben genanten Fehler bringt ...

Bringt testparm bei Dir wirklich die geänderten commands ? Welche cups Version nutzt Du denn ?

Eintrage und dann die Benutzer mit "lppasswd -a -g users" anlege, kann jeder Benutzer seine Druckaufträge löschen.

Zum Vergrößern anklicken....

Wer kann dann die Aufträge löschen, die Windowsuser ?
Selber wenn wäre das unschön, denn alle User sind ja in LDAP drin ;-)
Und dann noch mal die Passwörter anlegen ?!?

Das mit /jobs klappt bei mir für die Linuxuser mit :
AuthType Basic
AuthClass User

Ich versuchs jetzt einfach mal mit dem Kunstgriff über das bsd Drucksystem

So long

Thomas

Hi Thomas,
das ist das Ergebins von testparm

fs1:~ # testparm
Load smb config files from /usr/local/samba/lib/smb.conf
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[NETLOGON]"
Processing section "[daten]"
Processing section "[filme]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC
Press enter to see a dump of your service definitions

# Global parameters
[global]
unix charset = ISO8859-15
workgroup = KANIADOM
passdb backend = ldapsam:ldap://fs1.kania-lokal.de
printcap name = /etc/printcap
logon script = kania.bat
logon path = \\%N\profiles\%U
logon drive = H:
domain logons = Yes
os level = 99
domain master = Yes
ldap server = 127.0.0.1
ldap port = 389
ldap admin dn = cn=manager,dc=kania-lokal,dc=de
ldap passwd sync = Yes
ldap suffix = dc=kania-lokal,dc=de
ldap ssl = no
admin users = @Domainadmins
printer admin = @Domainadmins
create mask = 0660
directory mask = 0770
printing = cups
print command = /usr/bin/lp -d '%p' %s; rm %s
lpq command = /usr/bin/lpstat -o '%p'
lprm command = /usr/bin/cancel '%p-%j'
lppause command = lp -i '%p-%j' -H hold
lpresume command = lp -i '%p-%j' -H resume
queuepause command = /usr/bin/disable '%p'
queueresume command = /usr/bin/enable '%p'

Zum Vergrößern anklicken....

Hier mal alle relevanten Pakete zu cups die bei mir installiert sind.

fs1:~ # rpm -qa | grep cups
cups-drivers-stp-1.1.19-52
cups-1.1.19-100
cups-client-1.1.19-100
cups-drivers-1.1.19-52
cups-libs-1.1.19-100

Zum Vergrößern anklicken....

mit den Passwörtern hast du recht. Dann must du jeden Benutzer extra anlegen. Bei mir dürfen nicht alle Benutzer Job's löschen, deshalb dieser Weg. Das mit

AuthType Basic
AuthClass User

Zum Vergrößern anklicken....

ist dann schon richtig.
Ich glaube schon fast du wirst nicht drumherum kommen deinen Benutzern das Web-Frontend zu erkären ;-). Da dir der samba wohl einen Strich durch die Rechnung macht.
Wenn ich mir das so recht überlege, bin ich aber der Meinung das man unter samba bis 3.0.8 das ganze noch so funktionierte wie du es haben willst. Kann mich aber auch täuschen.
Gruß

Stefan

Hallo Stefan,

ja Du hast Recht aber ich weiß nicht genau bis zu welcher Samba Version es noch funktioniert hat oder ob es doch an der cups Version liegt ...

Aber ich habe so etwas wie einen halben Workaround gefunden

Ich hatte eine Doku gefunden in der geschrieben wurde man solle die Rechte an /dev/lp* ändern. Cups legt diese wohl an auch wenn man über ipp auf Netzwerkdrucker druckt. Bei drei Druckern gibt es bei mir z.B lp0, lp1 und lp2.
Ich habe die Rechte auf 666 geändert ... und siehe da man kann auf dem Samba Share [printers] (\\Server\Drucker (in der Netzwerkumgebung) )
auf den einzelnen Druckern die Jobs sehen und mit den richtigen Rechten in der cupsd.conf auch seine eigenen jobs löschen ...

Die Sache hat nur einen Hacken, die Config für Cups muß in etwa so aussehen :


Samba übertragt dann Cups die richtigen Infos oder regelt selber den Zugriff das jeder User nur seine eigenen Jobs löschen kann ...

Linux User brauchen dort aber :

AuthType Basic
AuthClass User

KJobViewer fragt dann vor den Zugriff nach Usernamen und Passwort ..

Ich habe mir die Doku von Cups noch nicht ganz durchgelesen, aber ich bräuchte jetzt die Möglichkeit Zugriffe auf /jobs so zu regeln das localhost keine Auth benötigt und Rechern (IPs) aus den Netz nur mit Auth zugreifen können ?!?

Kennst Du die Syntax auf Anhieb ?

Naja jedenfalls ist diese Lösung für die Windowsuser einfacher als das Webfontend ... eine Verknüpfung auf den Desktop ...
Aber vielleicht hat die nächste Version von Samba auch wieder eine einfachere Lösung ;-)

So long

Thomas

Hihi,

jetzt wird es wirklich lustig ...

Auf manchen Rechern (Win-Clients ) geht es und auf anderen nicht ..

Die Kerio Firewall (Jetzt bitte keine Diskusion über PF ;-) ) meldet z.B :


Und auf Clients auf denen manche Dienste deaktiviert sind geht es auch nicht ... habe aber noch nicht rausgefunden welcher Dienst jetzt genau dafür verantwortlich ist ...

Naja weiter geht die Suche

So long

ThomasF

Habe alle Win Client's die selbe BS Version und den selben Stand der SP? Vielleicht liegt da irgendwo der Hund begraben.

Die Kerio Firewall (Jetzt bitte keine Diskusion über PF ) meldet z.B :

Zum Vergrößern anklicken....

Immer noch besser als nix. ;-)

Hi,

eigentlich nicht, hier sind alle W2K mit SP4...

Aber auf einem Rechner habe ich z.B das Script von http://www.dingens.org/ laufen lassen, das "gefährliche Dienste beendet und deaktiviert ...

Und selbst das starten der Dienste bringt irgendwie keinen Erfolg ...

Aber man lernt halt jeden Tag etwas dazu ;-)

So long

Thomas

So jetzt aber ...

Ich habe Cups downgegradet auf die Version die auf der DVD ist ohne Online Update : cups-1.1.20-103 ...

Und siehe da es klappt alles wieder so wie ich es gewohnt bin, selbst mit dem Symbol in der Taskleiste von Windows kommt man wieder an die Jobs ran

Nun ja mit den Problemen dieser Version kann ich erstmal leben ;-)

So long

ThomasF

Manche Dinge ändern sich nicht unbedingt zu ihrem besten ;-)
Gruß
Stefan