Login
Login-Name Passwort


 
Newsletter
Do, 26. Mai 2005, 22:11

Problembehebung in CUPS und Turboprint

Wer kennt das nicht: »Mal eben etwas ausdrucken...«!

Bei den meisten Linux-Distributionen klappt dies (dank CUPS) mittlerweile zwar recht gut, aber erfahrungsgemäß gerade dann nicht, wenn schnell etwas Wichtiges ausgedruckt werden soll. Besonders, wenn einem dann die Zeit im Nacken sitzt, findet man den Fehler nicht so leicht.

In diesem Tipp beschreibe ich kurz die gängigsten Fehler, die beim Konfigurieren eines CUPS-Servers gemacht werden, wenn Client und Server auf ein und demselben PC installiert sind.

Erste Anlaufpunkte sind erfahrungsgemäß die Berechtigungen, die Benutzer und Clients auf die Bereiche (Locations) des CUPS-Servers haben. Diese Bereiche sind z.B. Basis (/), Verwaltung (/admin), Alle Klassen (/classes), Alle Drucker (/printers) und Druckaufträge (/jobs).

Oft stehen hier Zugriffsrechte wie "Allow from localhost" und "Deny from ALL". Meine Erfahrung ist, dass der CUPS-Server sehr oft Probleme macht, sobald eine Netzwerkkarte im Rechner aktiviert wird, die somit eine IP-Adresse bekommt. Besser läuft es mit der Einstellung "Allow from @LOCAL", die alle Anfragen von lokalen Netzwerkschnittstellen annimmt, alle Anfragen von außerhalb aber abweist. Somit ist eine Authentifizierung gegenüber dem CUPS-Server eigentlich nicht mehr notwendig und kann auf "None" gesetzt werden.

Achtung! Wer hier doch eine Authentifizierung wünscht, muss bei der Methode "Digest"(Zusammenfassung) darauf achten, dass er seine berechtigten Benutzer mit dem Befehl lppasswd der CUPS-eigenen Benutzerdatenbank hinzufügt. Die Methode "Basic" (Elementar) bedient sich der UNIX-Benutzerdatenbank (/etc/passwd). Als "AuthClass" (Klasse) steht zur Verfügung:

Anonymous
Es wird kein Benutzername und Password verlangt
User
Benutzername und Password werden verlangt. Gegen welche Benutzerdatenbank geprüft wird, legt man mit AuthType fest
System
Wie User, allerdings muss sich der Benutzer in der Gruppe sys befinden
Group
Wie User, allerdings muss sich der Benutzer in der Gruppe befinden, die mit Auth Group festgelegt wurde
Wer Turboprint oder Gimp Print einsetzt, sollte auch folgendes überprüfen:
  • Liegen die Filterprogramme an der richtigen Stelle?
  • Liegen die PPD Dateien an der richtigen Stelle?
Turboprint in der Version 1.90 z.B. setzt die Pfade bei der Installation so, dass mit seinen Treibern unter Debian Sarge nicht mehr gedruckt werden kann. Auf meinem System musste die system.cfg aus dem Tarball geändert werden, da sonst die PPD-Dateien nicht automatisch gefunden werden und zwar der Job in die Warteschlange gestellt wird, aber danach nichts mehr pasiert. Die Datei error_log faselt dann etwas davon, man solle den Debuglevel erhöhen, um weitere Informationen zu erhalten. Erst dann wird ersichtlich, dass die Filterprogramme *toturboprint nicht gefunden wurden. Abgebrochen wird der Druckauftrag jedoch interessanterweise nicht ;-)

Hier ein Beispiel für die Datei system.cfg:

TPBIN_BROWSER=konqueror
TPFILE_PRINTCAP=/etc/printcap
TPPATH_CONFIG=/etc/turboprint
TPPATH_SHARE=/usr/share/cups/model/turboprint
TPPATH_SPOOL=/var/spool/lpd
TPPATH_BIN=/usr/bin
TPPATH_FILTERS=/usr/lib/cups/filter
TPPATH_DOC=/usr/share/doc/turboprint
TPPATH_LOG=/var/log
TPPATH_TEMP=/tmp
TPPATH_MAN=/usr/share/man
TPPATH_CUPSDRIVER=/usr/share/cups/model
TPPATH_CUPSSETTINGS=/etc/cups/ppd
TPPATH_CUPSFILTER=/usr/lib/cups/filter
TPPATH_CUPSFILTER64=/usr/lib64/cups/filter
TPOWN_SPOOLDIR=lp
TPMOD_SPOOLDIR=0755
TPOWN_SPOOLFILE=lp
TPMOD_SPOOLFILE=0640

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten