Böbbele schrieb
PS: Du selber musst natürlich Mitglied der Gruppe "lp" sein! Außerdem unter /etc/cups/cupd.conf die Gruppe lp mit eintragen (in der unbearbeiteten Konfiguration steht nur sys und root drin).
Warum wollt ihr denn immer normale User in irgendwelche Gruppen reinpacken? Ich versteh das nicht.... Kein User muß in lp sein um über CUPS drucken zu können.
cupsd selbst läuft unter der UID 0 (=root), kann also *IMMER* auf alle notwendigen Devices zugreifen...
Kein User (der nur über CUPS drucken will) muß *direkt* auf die /dev/lp* oder /dev/usb/lp* oder sonstwas zugreifen können. Im schlimmsten Fall (gerade zusätzlich mit dem word-writeable Modus 0666) reißt ihr euch Scheunentore auf...
Nochmal: Der cupsd läuft unter der UID von root, "darf" also "alles". Um den cupsd zu konfigurieren (über localhost:631) muß man sich mit einem Account authentifizieren der in der cupsd.conf festgelegt ist (Per Default: Mitglieder der Grupen root und sys). In 99% der Fälle auf Desktopsystemen gibt es keinen Bedarf für Printer-Administratoren, also gibt man auf nachfrage root+rootkennwort ein...
Nur wenn der cupsd unter einer "unprivilegierten" UID laufen würde (Debian macht das AFAIK) ,dann muß dieser Cupsd-User ggf. in Gruppen wie lp Mitglied sein. Aber kein normaler User der über Cups drucken will...
Die Masse der privat verwendeten Drucker sind heuet GDI/PCL/sonstige-Sprache verstehende USB-Drucker, die teils herstellerspezifische "treiber/Schichten" brauchen oder nur damit zufriedenstellend drucken.
Der größte "Fallstrick"(wie Canons,Brother,Samsung, HP, ....) ist IMHO: manche dieser Drucker brauchen das Kernelmodul usblp, manche eben nicht. Mit oder ohne werden sie entweder bei der Einrichtung nicht gefunden oder funktionieren(drucken) nicht...
Beispiel mein Samsung ML-2010: Ich kann als Treiber splix verwenden oder foomatic. Ich schalte den Drucker ein, usblp wird dadurch als Modul geladen. Danach ergibt sich:
# dmesg
usb 1-3.1: new full-speed USB device number 6 using ehci_hcd
usblp0: USB Bidirectional printer dev 6 if 0 alt 0 proto 2 vid 0x04E8 pid 0x326C
usbcore: registered new interface driver usblp
# ll /dev/lp*
ls: Zugriff auf /dev/lp* nicht möglich: Datei oder Verzeichnis nicht gefunden
# ll /dev/usb/lp*
crw-rw---- 1 root lp 180, 0 27. Mär 12:00 /dev/usb/lp0
Ohne irgendwelche eigenen udev-Regeln ist dieses Device hier root:lp 0660. cupsd (als root laufend) hätte damit keinerlei Probleme...
Trotzdem wird der Drucker unter
http://localhost:631 nicht gefunden wenn ich über Verwaltung->Drucker hinzufügen gehe. Vorher werde ich per Dialog nach name+Paßwort eines cups-bekannten Printeradmins gefragt, per default verwende ich hier den Rootaccount. trotzdem taucht der Drucker unter "Lokale Drucker" nicht auf. Alle anderen verfügbaren Optionen wären für Netzwerkdrucker gedacht.
Jetzt entlade ich das usblp Modul:
# rmmod usblp
# dmesg
usbcore: deregistering interface driver usblp
usblp0: removed
(Das geht hier zumindest ohne Abhängigkeitsproblem, bei anderen ggf. erst durch explizites Blacklisten+Reboot
# ll /dev/lp*
ls: Zugriff auf /dev/lp* nicht möglich: Datei oder Verzeichnis nicht gefunden
# ll /dev/usb/lp*
ls: Zugriff auf /dev/usb/lp* nicht möglich: Datei oder Verzeichnis nicht gefunden
(Keine lp* Devices mehr, werden auch nicht zwangsläufig gebraucht!!!)
In der Cups-Admin
http://localhost:631 gehe ich nun wieder auf verwaltung->Drucker hinzufügen und voilá: Unter Lokaler Drucker taucht mein Samsung ML-2010 auf, den ich nun über Splix oder foomatic weiter konfigurieren kann.
Jetzt (ohne usblp) funktioniert auch das Drucken einer Testseite für den bereits eingerichteten Samsung, bzw. das Drucken für jeden User hier (über Druckdialoge der DEs, Programme) oder auch ganz profan über:
lp /etc/groups
Der Drucker, die "Schnittstelle" ist: usb://Samsung/ML-2010?serial=3A21BKALA02863F (kein lp0 o.ä.). Root (der cupsd) darf auf jedes notwendige reale oder virtuelle Device zugreifen. Die User "drucken" über Kommunikation mit dem cupsd auf localhost:631....
Wie gesagt: einige Modelle brauchen usblp, einige definitiv nicht. Einige brauchen herstellerspezifische Treiber, bei einigen reichen auch die über footmatic...
Die Default Seitenbeschreibungssprache unter Linux ist weiterhin Postscript. Wer noch einen dieser Drucker hat, der *könnte* nun eine Postsript-Datei (tiger.ps z.B.) direkt an ein /dev/lp senden:
cat tiger.ps > /dev/lp0
und (abseits daß ein PS-Drucker noch mit einem Header initialisiert werden muß) es würde gedruckt werden. Nur für diese Methode bräuchte ein User Zugriff auf das Device, die Schnittstelle selbst. Bei den heutigen Wald-und-Wiesendrucker würde nur Müll rauskommen - abgesehen davon, daß damals und heute das Drucken auch meistens über Druckdaemons (LPD oder Cups) abgewickelt wurde.
Also: Ein Nichteinrichten-Können oder Nicht-Druckenkönnen hat bei einem Default-CUPSd nichts mit Rechten auf Devices zu tun!
Entscheidend ist: ist usblp für den Drucker nun "gut" oder "böse"! Und: habe ich (herstellerspezifisch oder über das foomatic-paket) einen funktionierenden Treiber (und somit eine PPD, damit über Ghostscript die Postscriptausgabe in die jeweils verwendete Druckersprache übersetzt wird).
Alle anderen "Verrenkungen" sind IMHO nicht nötig (hal oder chmod), ein:
Böbbele schrieb
Um die Verlinkung hinzubekommen und die Rechte dauerhaft zu ändern musst du folgende udev-Regel erstellen:
KERNEL=="lp[0-9]", SYMLINK+="lp0", MODE:="0666", GROUP="lp"
Ist sowieso "Blödsinn"<g> da wenn schon 666, dann kann ich mir auch die Gruppe schenken....
Bei Problemen mit cups sollte man immer den Loglevel kurzzeitig hochsetzen, meist findet man so den Übeltäter warum ein eingerichteter Drucker nicht mehr druckt oder ggf. auch warum und ob ein neuer Drucker nicht gefunden würde... Rechte an Devices werden das aber IMHO nie sein....