SDB:CUPS in aller Kürze

aus openSUSE, der freien Wissensdatenbank

Dieser Artikel richtet sich an erfahrene Linux-Benutzer. Es gibt hier keine ausführlichen Erklärungen. Alle wichtigen Punkte zu CUPS werden kurz und bündig dargestellt.

Überblick über das CUPS Drucksystem

Ein genereller Überblick findet sich in folgendem Text der CUPS Dokumentation: "An Overview of the Common UNIX Printing System", die via http://localhost:631/help/overview.html oder via [file:///usr/share/doc/packages/cups/overview.html file:///usr/share/doc/packages/cups/overview.html] zur Verfügung steht.

Die CUPS Home-Page ist: http://www.cups.org/

Ablauf wie ein Druckjob verarbeitet wird

1) Dieser Schritt passiert sowohl auf Client- als auch auf Server-Systemen. Ein Client ist ein Rechner, auf dem nur dieser Schritt passiert. Auf einem Client-Rechner ist keine Warteschlange angelegt. Ein Kommandozeilentool oder ein Anwendungsprogramm erzeugt einen Druckauftrag und übergibt ihn an den Spooler: Anwendungsprogramme rufen entweder ein Kommandozeilentool auf (z.B. Mozilla) oder verwenden die CUPS Bibliotheksfunktionen direkt (z.B. kprinter). Ein Druckauftrag besteht aus Informationen für den Spooler und den zu druckenden Daten und optionalen Informationen für den Filter.

Beispielsweise bei einem Kommandozeilentool:

lp -d queue -t title -o option1=value1 -o option2=value2 file1 file2

"queue" und "title" sind Informationen für den Spooler. "option1=value1" und "option2=value2" sind Informationen für den Filter. "file1" und "file2" sind die zu druckenden Daten.

Die folgenden Schritte passieren nur auf einem CUPS Server. Ein Rechner, auf dem die folgenden Schritte passieren, ist ein Server. Ein Rechner, auf dem eine Warteschlange angelegt ist, ist ein Server.

Spooler (der cupsd):

2) Speichern des Druckjobs im Spool-Verzeichnis:

2a) Speichern der Information für den Spooler und den Filter in /var/spool/cups/c<job-number>

2b) Speichern der Daten aus den zu druckenden Dateien in /var/spool/cups/d<job-number-file-number>

3) Filtern der zu druckenden Daten und die druckerspezifischen Daten an den Drucker senden:

3a) Starten des Filtersystems:

3a1) Bestimmen, welche Filter benötigt werden, um die druckerspezifischen Daten zu erzeugen und Aufbau der sog. "Filterkette" bzw. "Filter-Pipe".

3a2) Starten der Programme der Filterkette mit passend gesetzten Parametern.

3b) Starten des "Backends", um die druckerspezifischen Daten von der Filter-Pipe an den Drucker weiterzuleiten.

4) Beenden des Druckjobs:

4a) Warten, bis das Backend fertig ist.

4b) Löschen der betreffenden Dateien aus dem Spool-Verzeichnis.

Der Spooler

Was der Spooler macht:

Der Hauptzweck des Spooler-Systems ist, Daten vom Sender zum Empfänger zu bewegen.

1. Daten entgegennehmen (aber nur von zulässigen Sendern).
2. Daten zwischenspeichern (bis der Empfänger bereit ist, sie entgegenzunehmen).
3. Daten an zulässige Empfänger senden (und ggf. vorher passende Filter zwischenschalten).
4. Bereitstellen und Bereithalten von Informationen, was mit den Daten passiert ist (z.B. für "lpstat -W completed -o").

Details:

/usr/sbin/cupsd

• Der cupsd ist der Server für das IPP Protokoll.
• Das IPP Protokoll kann als Erweiterung das HTTP Protokolls angesehen werden. Details zum IPP Protokoll finden sich in RFC-2910 und RFC-2911.
• Der cupsd lauscht am TCP Port 631 auf IPP Aufträge wie z.B. "lp -d queue file" oder "lpstat -t".
• Der cupsd lauscht am TCP Port 631 auf HTTP Aufträge wie z.B. http://localhost:631/printers/
• Der cupsd verwendet UDP Port 631 um sog. "IPP Browsing" Informationen zu senden und zu empfangen. Man kann z.B. "netcat -u -l -p 631" verwenden, um solche Informationen aufzuschnappen (sofern UDP Port 631 noch nicht vom cupsd belegt ist).
• Konfigurationsdatei für den cupsd: /etc/cups/cupsd.conf

/usr/lib/cups/daemon/cups-lpd

• Der cups-lpd ist der Server für das LPD Protokoll (RFC 1179).
• Der cups-lpd nimmt Druckjobs an, die via LPD Protokoll am TCP Port 515 eintreffen.
• Entweder der xinetd oder der inetd wird als "Wrapper" für den cups-lpd verwendet.
• Konfigurationsdateien: Entweder /etc/xinetd.d/cups-lpd oder in /etc/inetd.conf die "cups-lpd" Zeile.

Dokumentation:

• Das "CUPS Software Administrators Manual" ist verfügbar via http://localhost:631/sam.html oder via [file:///usr/share/doc/packages/cups/sam.html file:///usr/share/doc/packages/cups/sam.html]

PPD Dateien

Was ist eine PPD Datei und wie funktioniert sie:

Ein PPD Datei enthält die druckerspezifischen Optionen (und nur die druckerspezifischen Optionen) zusammen mit den zugehörigen PostScript Code Schnipseln, die an den PostScript Interpreter gesendet werden müssen, um eine bestimmte Option zu aktivieren.

Abhängig davon, welche druckerspezifischen Optionen für einen bestimmten Druckjob gesetzt wurden (z.B. "-o PageSize=A4"), liest das Filter-System die passenden PostScript Code Schnipsel (die sog. "PostScript Invocation Values") aus der PPD Datei und setzt sie in den PostScript Datenstrom ein.

Die Syntax für einen Optionseintrag in der PPD Datei mit zwei Beispieleinträgen ist:

Genaue Informationen finden sich in der "Adobe PostScript Printer Description File Format Specification, Version 4.3".

Details:

/etc/cups/ppd/

• Dieses Verzeichnis enthält die PPD Dateien, die der cupsd tatsächlich verwendet.
• Die Einträge (insbesondere die "*Default..." Einträge) in einer PPD Datei in /etc/cups/ppd/ können von den Einträgen in der ursprünglichen PPD Datei, die beim Anlegen der Warteschlange angegeben wurde, abweichen.

/usr/share/cups/model/

• Dieses Verzeichnis enthält die ursprünglichen PPD Dateien aus den Paketen
  • cups: CUPS PPD Dateien
  • cups-drivers: Foomatic (OpenPrinting/LinuxPrinting.org) PPD Dateien
  • gutenprint/cups-drivers-stp: Gutenprint/Gimp-Print PPD Dateien
  • manufacturer-PPDs: PPD Dateien mit freier Lizenz von Druckerherstellern
• Zusätzliche PPD Dateien (z.B. PPD Dateien von Druckerherstellern) können in dieses Verzeichnis kopiert werden, um sie für die Druckerkonfigurationstools verfügbar zu machen.

Die OpenPrinting/LinuxPrinting.org Druckerdatenbank

• Die OpenPrinting/LinuxPrinting.org Druckerdatenbank besteht aus XML Dateien aus denen die Foomatic PPD Dateien erzeugt werden.
• Die OpenPrinting/LinuxPrinting.org Druckerdatenbank ist hier verfügbar: http://www.linux-foundation.org/en/OpenPrinting bzw. http://www.linuxprinting.org/database.html

Der Filter

Was macht das Filter-System und wie arbeitet es:

Der Hauptzweck des Filtersystems ist, die ursprünglichen Daten des Druckjobs (ASCII, PostScript, PDF) in druckerspezifische Daten (PostScript, PCL, ESC/P) umzuwandeln.

Normalerweise erfolgt die Filterung in folgenden Schritten:

1) Bestimmung des MIME-Typs der ursprünglichen Daten gemäss /etc/cups/mime.types. Wenn es nicht "application/postscript" ist, dann Umwandlung nach PostScript gemäss /etc/cups/mime.convs. Beispielsweise "text/plain" wird mit /usr/lib/cups/filter/texttops nach PostScript umgewandelt.

2) Einfügen der "PostScript Invocation Values" in den PostScript Datenstrom gemäss der folgenden Zeile in /etc/cups/mime.convs:

3) Wenn ein nicht-PostScript Drucker mit einer Foomatic PPD Datei verwendet wird, dann wird das PostScript in druckerspezifische Daten konvertiert, gemäss der folgenden Zeile in jeder Foomatic (Version 3.x) PPD Datei:

Wenn ein nicht-PostScript Drucker mit einer Foomatic PPD Datei verwendet wird, dann ist foomatic-rip zusammen mit Ghostscript der PostScript Interpreter. Um PostScript in druckerspezifische Daten umzuwandeln, macht foomatic-rip die folgenden Schritte:

3a) Aufbau einer Ghostscript Kommandozeile mit den notwendigen Ghostscript Parametern gemäss der für den jeweiligen Druckauftrag eingestellten druckerspezifischen Optionen.

3b) In einigen Fällen wird ein "Postfilter" dem Ghostscript Kommando nachgeschaltet (via "Pipe"):

3b1) Für PCL Drucker:
Gewisse Optionen werden durch Änderungen im PCL Datenstrom realisiert (z.B. Papierschachtwahl via "perl -e").

3b2) Für manche GDI Drucker:
Umwandeln der Ghostscript-Ausgabe in druckerspezifische Daten (z.B. für HP PPA Drucker mit pnm2ppa).

3c) Ausführen der Ghostscript Kommandozeile (bzw. "Pipe").

Wenn für einen nicht-PostScript Drucker eine nicht-Foomatic PPD Datei (z.B. eine Gimp-Print PPD Datei von /usr/share/cups/model/stp/) verwendet wurde, dann können die "*cupsFilter" Einträge in der PPD Datei wie folgt aussehen:

*cupsFilter: "application/vnd.cups-raster 100 rastertoprinter"
*cupsFilter: "application/vnd.cups-command 33 commandtoepson"

Mit den Einträgen in /etc/cups/mime.convs ergibt sich dann ein anderer Ablauf der Filterung.

Weitere Informationen zur Filterung finden sich im Supportdatenbank Artikel "Selbst erstellte Filter zum Ausdruck mit CUPS": SDB:Selbst erstellte Filter zum Ausdruck mit CUPS zur Verfügung steht.

Details:

/usr/lib/cups/filter/

Dieses Verzeichnis enthält die verschiedenen Filterprogramme, die das CUPS Filtersystem verwendet, wenn eine PPD Datei beim Einrichten der betreffenden Warteschlange angegeben wurde.

• /usr/lib/cups/filter/*tops (z.B. /usr/lib/cups/filter/texttops) um die ursprünglichen Daten (z.B. "text/plain") nach PostScript umzuwandeln.
• /usr/lib/cups/filter/pstops um die "PostScript Invocation Values" einzufügen und ggf. um das PostScript umzuformatieren (z.B. je zwei Seiten verkleinert auf ein Blatt drucken).
• /usr/lib/cups/filter/foomatic-rip um PostScript in druckerspezifische Daten (z.B. PCL or ESC/P) umzuwandeln.

/etc/cups/interfaces/

Dieses Verzeichnis enthält den Filter, der von CUPS verwendet wird, wenn beim Einrichten der betreffenden Warteschlange keine PPD Datei, sondern ein "System V style Interface Script" angegeben wurde. Ein "System V style Interface Script" ist ein einziges Filterprogramm oder Filterscript, das die druckerspezifischen Daten für alle Datentypen produzieren muss, die bei den ursprünglichen zu druckenden Daten vorkommen können. Weitere Informationen bzgl. "System V style Interface Script" finden sich im Supportdatenbank Artikel "Selbst erstellte Filter zum Ausdruck mit CUPS": SDB:Selbst erstellte Filter zum Ausdruck mit CUPS

"raw"

Wenn beim Einrichten der betreffenden Warteschlange weder eine PPD Datei, noch ein "System V style Interface Script" angegeben wurde, dann erfolgt überhaupt keine Filterung. Die ursprünglichen zu druckenden Daten werden wie sie sind (also "roh") direkt vom Backend an den Empfänger (normalerweise an den Drucker) geschickt. Es kann weder der Zeilenumbruch konvertiert werden (z.B. LF -> CR+LF) noch kann am Ende ein Formfeed angefügt werden. Für derartiges kann ein "System V style Interface Script" verwendet werden.

Die Backends

Was ist ein CUPS Backend und wie arbeitet es:

Normalerweise bekommt das Backend die druckerspezifischen Daten vom Filter und sendet sie weiter an den Drucker oder einen sonstigen Empfänger.

Die Unterschiede zwischen Backend und Filter sind:

• Genau ein Backend, aber normalerweise mehrere Filter (eine Filterkette) werden aktiviert, um einen Druckauftrag zu verarbeiten. Ausnahmen: "System V style Interface Script" (genau ein Filter) und "raw"-Druck (kein Filter).
• Das Backend ist immer das letzte Programm in der Verarbeitungskette, das ausgeführt wird, um einen Druckauftrag zu verarbeiten.

Für das Drucksystem ist der Druckauftrag genau dann komplett abgearbeitet, wenn das Backend fertig ist. Das Backend ist fertig, wenn die Datenübertragung zum Empfänger beendet ist. Wenn danach die weitere Verarbeitung beim Empfänger scheitert (z.B. wenn der Drucker die druckerspezifischen Daten nicht zu Papier bringen kann), merkt das Drucksystem davon nichts mehr.

Wenn die Datenübertragung zum Empfänger endgültig scheitert (normalerweise macht ein Backend mehrere Versuche), dann meldet das Backend einen Fehler an das Drucksystem (genauer an den cupsd). Das Backend entscheidet, ob und wieviele Versuche sinnvoll sind, bis es die Datenübertragung als unmöglich meldet. Da weitere Versuche somit sinnlos sind, wird das Ausdrucken für die betroffene Warteschlange vom cupsd abgeschaltet (disable). Nachdem die Ursache des Problems behoben wurde, muss der Systemverwalter mit /usr/bin/enable (für CUPS 1.1 - d.h. bis Suse Linux 10.1) bzw. mit cupsenable (für CUPS 1.2 - d.h. ab openSUSE 10.2) das Ausdrucken wieder aktivieren.

Weitere Informationen zu Backends finden sich im "CUPS Software Programmers Manual": http://localhost:631/spm.html oder [file:///usr/share/doc/packages/cups/spm.html file:///usr/share/doc/packages/cups/spm.html]

Details:

/usr/lib/cups/backend/
Dieses Verzeichnis enthält die verschiedenen Backends.

Je nachdem wie der Drucker erreichbar ist von dem Rechner, auf dem das CUPS System läuft, bzw. je nach Typ des Empfängers muss das passende Backend verwendet werden.

Das Ziel an das ein Backend die Daten sendet, kann jeder "URI" (Uniform Resource Identifier) sein, für den ein passendes Backend existiert. Der erste Teil des "DeviceURI"-Eintrags in /etc/cups/printers.conf legt das Backend fest, der Rest dient dem Backend als Parameter.

Falls "user" und "password" für das smb Backend benötigt werden, müssen Eigentümer, Gruppe und Zugriffsrechte für die Datei /etc/cups/printers.conf hinreichend restriktiv gesetzt sein. Die Angaben "user" und "password" werden nicht mit dem Kommando "lpstat -v" angezeigt.

Jedes Backend kann auch direkt aufgerufen werden. Beispielsweise die Backends "parallel" und "usb" liefern dabei die IEEE-1284 Identifikation von angeschlossenen Druckern:

root@host# /usr/lib/cups/backend/parallel
direct parallel:/dev/lp0 "ACME FunPrinter 1000" "Parallel Port #1"

root@host# /usr/lib/cups/backend/usb
direct usb://ACME/USB%20Printer?serial=1234 "ACME USB Printer" "USB Printer #1"
direct usb:/dev/usb/lp1 "Unknown" "USB Printer #2"
...

Beim Starten ruft der cupsd alle Backends in /usr/lib/cups/backend/ nacheinander einmal auf. Dadurch ermittelt der cupsd welche Backends auf dem jeweiligen System einsatzfähig sind. Nur die einsatzfähigen Backends stehen für die Konfiguration von Warteschlangen zur Verfügung. Die einsatzfähigen Backends werden mit "lpinfo -v" angezeigt.

Kommandozeilentools

Allgemeine Informationen zu den Kommandozeilentools:

Machen Sie keine manuellen Änderungen in den Konfigurationsdateien in /etc/cups/, wenn es dafür auch geeignete Kommandozeilentools gibt.

Grund:

Die Konfigurationsdateien werden nicht für jeden Druckjob neu eingelesen. Stattdessen hält der cupsd viel Information nur im Hauptspeicher und schreibt je nach Bedarf Informationen in die Konfigurationsdateien zurück. Ausnahme: /etc/cups/cupsd.conf
Nach Änderungen in dieser Konfigurationsdatei muss der cupsd neu gestartet werden, damit er mit der geänderten Konfiguration arbeitet. Siehe im "CUPS Software Administrators Manual" den Abschnitt "Restarting the CUPS Server": http://localhost:631/sam.html#RESTARTING oder [file:///usr/share/doc/packages/cups/sam.html#RESTARTING file:///usr/share/doc/packages/cups/sam.html#RESTARTING]

Kopieren Sie niemals Konfigurationsdateien von anderen Systemen in Ihr System, es sei denn, Sie wissen genau, was Sie tun. Verwenden Sie stattdessen Kommandozeilentools.

Um z.B. dieselben Warteschlangen auf mehreren Maschinen anzulegen (etwa für einen Backup-Server), kopieren Sie nicht /etc/cups/printers.conf und /etc/cups/ppd/*, sondern machen Sie ein Script aus den passenden Kommandozeilen (normalerweise eine Reihe von lpadmin Aufrufen) und lassen dieses Script auf den verschiedenen Machinen laufen. Dadurch bekommen Sie ggf. die jeweils passenden Fehlermeldungen auf der jeweiligen Maschine (z.B. wenn auf einer Maschine eine PPD Datei nicht vorhanden ist oder wenn ein Backend nicht verfügbar oder nicht einsatzfähig ist). Ausserdem haben Sie durch das Script ein Protokoll der Einstellungen und Sie können mit dem Script diese Einstellungen immer wieder herstellen.

Wenn Sie nicht sicher sind, welches hübsche graphische Tool für gewisse spezielle Konfigurationen am besten geeignet ist, nehmen Sie stattdessen Kommandozeilentools.

In vielen Fällen ist die Reihenfolge der Optionen wichtig. Lesen Sie die Man-Pages. Beispielsweise sind die folgenden Kommandos alle verschieden:

lpadmin -E -p queue,
lpadmin -p queue -E
lpadmin -E -p queue -E

Details:

Kommandozeilentools um Warteschlangen anzulegen oder zu ändern:

Beispiel zum Anlegen einer Warteschlange:

root@host# lpadmin -p funprinter1000 -v parallel:/dev/lp0 -E -P /usr/share/cups/model/Postscript.ppd.gz

Kontrolle, was angelegt wurde via Kommandozeilentool

user@host$ lpstat -a funprinter1000 -p funprinter1000 -v funprinter1000
funprinter1000 accepting requests since Jan 01 00:00
printer funprinter1000 is idle.  enabled since Jan 01 00:00
device for funprinter1000: parallel:/dev/lp0

oder Anzeige von /etc/cups/printers.conf:

<Printer funprinter1000>
Info funprinter1000
DeviceURI parallel:/dev/lp0
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
</Printer>

oder Abfrage via Web-Frontend: http://localhost:631/printers/funprinter1000

Ändern der Warteschlange (z.B. Beschreibung und Standort):

root@host# lpadmin -p funprinter1000 -D "ACME FunPrinter 1000" -L "2. floor: room 3"

Anzeige der druckerspezifischen Optionen und deren Voreinstellungen in /etc/cups/ppd/funprinter1000.ppd:

user@host$ lpoptions -p funprinter1000 -l
Resolution/Output Resolution: 150dpi *300dpi 600dpi 1200dpi 2400dpi
PageSize/Media Size: Letter Legal Executive *A4 A5
...

Die Ausgabe hat folgende Syntax:

main-keyword/translation-string: option-keyword option-keyword option-keyword ...

Die Voreinstellung ist durch einen * vor dem "Option-Keyword" gekennzeichnet.

Ändern der druckerspezifischen Voreinstellungen in /etc/cups/ppd/funprinter1000.ppd:

root@host# lpadmin -p funprinter1000 -o Resolution=600dpi -o PageSize=Letter

Die Syntax ist:

lpadmin -p queue -o main-keyword1=option-keyword1 -o main-keyword2=option-keyword2 ...

Verwenden Sie nicht lpoptions für diesen Zweck. Siehe den Supportdatenbank Artikel "Einstellungen zum Ausdruck mit CUPS": SDB:Einstellungen zum Ausdruck mit CUPS Normaler Benutzer können mit lpoptions ihre persönlichen Voreinstellungen in ~/.lpoptions speichern: Siehe dazu denselben Supportdatenbank Artikel.

Verwenden Sie accept bzw. reject um Druckaufträge für eine Warteschlange zu akzeptieren bzw. zurückzuweisen und /usr/bin/enable (enable ist ein Bash-Builtin) bzw. disable um das Ausdrucken aus einer Warteschlange zu starten bzw. zu stoppen (z.B. damit während Wartungsarbeiten am Drucker keine Druckaufträge verloren gehen).

Löschen der Warteschlange:

root@host# lpadmin -x funprinter1000

Kommandozeilentools für den täglichen Gebrauch:

Vermeiden Sie die Kommandos im BSD Stil lpr, lpq und lprm, denn hier sind nur einige generische Optionen unterstützt. Verwenden Sie stattdessen die Kommandos im System V Stil lp, lpstat und cancel.

Verwenden Sie lpoptions um persönliche druckerspezifische Optionseinstellungen in ~/.lpoptions zu speichern, z.B.:

user@host$ lpoptions -o Resolution=1200dpi -p funprinter1000

Die allgemein verfügbaren Optionen beim Ausdruck sind im "CUPS Software Users Manual" im Abschnitt "Standard Printer Options" beschrieben: http://localhost:631/sum.html#STANDARD_OPTIONS oder [file:///usr/share/doc/packages/cups/sum.html#STANDARD_OPTIONS file:///usr/share/doc/packages/cups/sum.html#STANDARD_OPTIONS]

Das Web-Frontend des cupsd

Jeder cupsd im Netzwerk hat ein HTTP Web-Frontend. Die URL für einen lokal laufenden cupsd ist http://localhost:631/ und http://host.domain:631/ ist die URL für einen entfernten cupsd auf dem Rechner "host.domain". Voraussetzung für den Zugriff ist, dass der jeweilige Rechner und der jeweilige cupsd den Zugriff erlauben.

Details:

Für den täglichen Gebrauch ist das Web-Frontend oft die beste Informationsquelle zu Warteschlangen und Druckaufrägen. Beispielsweise liefert http://localhost:631/printers/ eine Übersicht aller Warteschlangen eines lokalen cupsd. Oder z.B. die abgearbeiteten Druckaufräge der Warteschlange "funprinter1000" auf dem Rechner "host.domain" werden mit einer URL in der Art http://host.domain:631/printers/funprinter1000?which_jobs=completed angezeigt.

Das Web-Frontend ist die beste Art, die zum jeweiligen cupsd (bzw. zu dessen Version) passende Dokumentation zu bekommen, z.B. http://localhost:631/documentation.html für die Dokumentation zum lokalen cupsd oder eine URL in der Art http://host.domain:631/documentation.html für die Dokumentation zu einem entfernten cupsd auf dem Rechner "host.domain".

Sogar die PPD Dateien unter /etc/cups/ppd/ sind via Web-Frontend verfügbar. Beispielsweise die PPD Datei der Warteschlange "funprinter1000" auf dem lokalen Recher (/etc/cups/ppd/funprinter1000.ppd) mit der URL http://localhost:631/printers/funprinter1000.ppd und eine URL in der Art http://host.domain:631/printers/queue.ppd für die PPD Datei der Warteschlange "queue" auf dem Rechner "host.domain".

CUPS im Netzwerk konfigurieren

Das grundsätzliche Design von CUPS zum Drucken im Netzwerk:

CUPS Netzwerk Server (die Rechner, wo Spooling und Filterung erfolgt):

• Der cupsd eines CUPS Netzwerk Servers sendet Informationen über seine Warteschlangen an eine beliebige Liste von IP Adressen (Rechneradressen und/oder Broadcastadressen). Die Voreinstellung ist eine leere Liste.
• Das Senden wird in einem vorgegebenen Zeitintervall wiederholt. Die Voreinstellung ist 30 Sekunden.

Clients (die Rechner, die nur Druckaufträge an Server senden):

• Auf jedem Client sollte ein lokaler cupsd laufen, denn per Voreinstellung lauscht ein cupsd auf Informationen, die von Servern kommen. Es gibt eine Liste von Servern, von denen Informationen angenommen werden. Per Voreinstellung wird von jeglichen Servern Information angenommen.
• Die Information über eine bestimmte Warteschlange wird auf dem Client gelöscht, wenn in einem vorgegebenen Zeitintervall keine neue Information über die Warteschlange eintrifft. Die Voreinstellung ist 300 Sekunden.

Auf diese Weise sind die Warteschlangen des Servers direkt auf dem Client verfügbar und Benutzer auf den Clients können die im Netzwerk auf verschiedene Server verteilten Warteschlangen "durchstöbern" (im Englischen "browse") und daher heisst das ganze "Browsing".

Per Voreinstellung ist "Browsing" aktiviert. Jegliche eintreffende Browsing-Information wird akzeptiert, aber keine Browsing-Information wird versendet - siehe oben.

Konfiguration der CUPS Netzwerk Server:

1. Konfigurieren Sie auf dem Server die Warteschlangen für die Drucker, die zu dem Server gehören.
2. Erlauben Sie den Zugriff auf die Warteschlangen für die Client-Rechner.
3. Aktivieren Sie das Senden von Browsing-Information an die Client-Rechner.

Sub-Netze erleichtern die Konfiguration, denn dann genügt es, die Browsing-Information an eine feste Broadcast-Adresse zu senden, statt an eine ständig zu pflegende Liste von einzelnen Rechneradressen.

Der Zugriff auf die Warteschlangen eines Servers ist unabhängig davon, an welche Rechner der Server Browsing-Information sendet. Ein Server kann allen Clients im Netzwerk den Zugriff auf seine Warteschlangen erlauben und nur an einen Teil der Clients Browsing-Information senden. Ein Server sollte aber keine Browsing-Information an Clients senden, die keinen Zugriff auf seine Warteschlangen haben.

Was nicht möglich ist:

Senden von Browsing-Information nur für einen Teil der Warteschlangen eines Servers.

Es ist nicht möglich, nur einen grossen Server für eine grosse Firma zu haben und Browsing-Information für einen Teil der Warteschlangen an die Clients der einen Abteilung oder des einen Gebäudes zu senden und Browsing-Information für einen anderen Teil der Warteschlangen an andere Clients zu senden.

Dazu sind mehrere Server (einer pro Abteilung oder Gebäude) notwendig.

Details:

Konfiguration der Warteschlangen für die Drucker, die zu dem Server gehören:

Die Drucker, die zu einem Server gehören, sind genau diejenigen, für die die Filterung auf dem Server erfolgt.

1) Konfigurieren Sie die Drucker so, dass das Drucken für normale Benutzer auf dem Server korrekt funktioniert.

Im Falle von Problemen:

1. Setzen Sie "LogLevel debug" in /etc/cups/cupsd.conf.
2. Stoppen Sie den cupsd.
3. Bewegen Sie /var/log/cups/error_log* weg (oder löschen Sie es) damit Sie nicht in zu grossen Logdateien suchen müssen.
4. Starten Sie den cupsd.
5. Versuchen Sie erneut, was zu dem Problem geführt hat.
6. Nun finden sich viele Meldungen in /var/log/cups/error_log*, die zur Ursachenermittlung nützlich sind.

2) Erlauben Sie den Zugriff auf die Warteschlangen für die Client-Rechner:

Standardmässig steht seit SUSE LINUX 9.0 in /etc/cups/cupsd.conf

BrowseAllow @LOCAL
.
.
.
<Location />
...
Allow From @LOCAL
</Location>

Damit können alle LOCAL-Rechner auf den cupsd zugreifen. LOCAL-Rechner sind solche, deren IP-Adresse zu einem nicht-point-to-point Interface gehört (genauer: Interfaces deren IFF_POINTOPOINT Flag nicht gesetzt ist) und deren IP-Adresse zum gleichen Netzwerk wie der CUPS-Server gehört. Von allen anderen Rechnern werden jegliche Pakete sofort zurückgewiesen. Genauere Informationen zu "BrowseAllow" finden Sie im Support-Datenbank Artikel SDB:Drucker einrichten ab SUSE LINUX 9.0 Soll der Zugriff weiter eingeschränkt werden oder auch für nicht-LOCAL-Rechner freigegeben werden, dann sind die obigen Einträge anzupassen. Die Möglichkeiten sind in /etc/cups/cupsd.conf kommentiert. Es ist empfohlen, IP Adressen statt Namen zu nehmen.

3) Aktivieren Sie das Senden von Browsing-Information an die Client-Rechner:

Aktivieren Sie in /etc/cups/cupsd.conf den Eintrag "BrowseAddress @LOCAL" um Browsing-Information an alle LOCAL-Rechner zu senden oder fügen Sie Einträge der Art "BrowseAddress client.host.IP.address" oder "BrowseAddress network.broadcast.IP.address" hinzu. Die Möglichkeiten sind in /etc/cups/cupsd.conf kommentiert.

Das Senden von Browsing-Information an die Client-Rechner ist in gewisser Weise optional:

• Wird er weggelassen, bekommen die Client-Rechner nicht automatisch Informationen über die Warteschlangen auf dem Server.
• Dennoch kann wegen dem Schritt davor auf die Warteschlangen des Servers von den Client-Rechnern aus zugegriffen werden.

Gerade in grossen Netzwerken kann es sinnvoll sein, den Zugriff für alle Clients freizugeben, aber Browsing-Information nur an einen Teil der Clients (z.B. nur an die Clients in der gleichen Abteilung oder im gleichen Gebäude wie der Server) zu senden.

4) Denken Sie an den Abschnitt "Restarting the CUPS Server" im "CUPS Software Administrators Manual" (siehe oben).

Konfiguration der Client-Rechner:

Empfohlen:

1. Aktivieren von /etc/init.d/cups, so dass der cupsd beim Booten des Client-Rechners gestartet wird.
2. Starten des cupsd.

Ab SUSE LINUX 9.1 erfolgt das standardmässig. Alternativ kann es mit dem YaST Runlevel Editor oder mit insserv erfolgen. Im Normalfall ist es empfohlen, sonst nichts weiter zu konfigurieren, insbesonere:

• Keine lokalen Warteschlangen auf Client-Rechnern.
• Keine Änderungen an den Voreinstellungen für den cupsd auf Client-Rechnern.

Spezialfälle:

Optional:

Fügen Sie in /etc/cups/cupsd.conf Einträge der Art "BrowseAllow IP.of.desired.server" und "BrowseDeny IP.of.unwanted.server" hinzu, um jegliche Pakete (also auch Browsing-Information) von unerwünschten Servern zurückzuweisen. Es ist empfohlen IP Adressen statt Namen zu nehmen. In bestimmten Fällen kann es nützlich sein, den BrowseOrder Eintrag anzupassen.

Wenn es Server gibt, die keine Browsing-Information senden, aber man kann dennoch auf deren Warteschlangen zugreifen (z.B. Server anderer Abteilungen oder Gebäude), dann kann es sinnvoll sein, die Browsing-Information aktiv vom Server abzufragen (Englisch "polling"): Fügen Sie dazu in /etc/cups/cupsd.conf für jeden Server einen Eintrag der Art "BrowsePoll IP.of.the.server:631" hinzu. Es ist empfohlen IP Adressen statt Namen zu nehmen und standardmässig ist der Port auf dem Server 631. Nach dem erneuten Starten des cupsd wird für jeden BrowsePoll Eintrag ein cups-polld laufen.

Wenn Browsing generell unerwünscht ist:

Setzen Sie "Browsing Off" in /etc/cups/cupsd.conf. Das bedeutet nicht, dass nun nicht mehr auf die Warteschlangen auf den Servern zugegriffen werden kann. Man kann weiterhin z.B. die Kommandozeilentools benutzen, nur ist nun der Server explizit anzugeben (normalerweise mit der Option "-h", siehe die Man-Pages).

"Client-only" Konfiguration:

Wenn Browsing generell unerwünscht ist, gibt es keinen Grund auf dem Client einen cupsd laufen zu haben. In diesem Fall sollte eine "Client-only" Konfiguration gemacht werden. Das geht mit YaST oder manuell wie folgt:

1. Stoppen und deaktivieren des cupsd (YaST Runlevel Editor oder insserv).
2. In /etc/cups/client.conf einen Eintrag der Art "ServerName IP.of.the.server" machen.

So ein Eintrag sollte nicht zusammen mit einem lokal laufenden cupsd vorhanden sein. Es ist maximal ein solcher Eintrag möglich. Daher sollte hier der bevorzugt verwendete Server eingetragen werden. Um auf einen anderen Server zuzugreifen, ist dieser bei den Kommandozeilentools explizit anzugeben (Option "-h") oder die Umgebungsvariable CUPS_SERVER ist passend zu setzten. Manche Anwendungsprogramme ignorieren den ServerName Eintrag. Dann könnte es helfen CUPS_SERVER zu setzten, oder im Anwendungsprogramm ist der Server explizit anzugeben (z.B. mit der Option "-h" im Druckbefehl).

Minimalistische Client Installationen:

Das normale Minimum, um CUPS Server anzusprechen, ist die Pakete "cups-libs" und "cups-client" installiert zu haben. Dann können Server mit den Kommandozeilentools angesprochen werden.

Das unterste Minimum, um CUPS Server anzusprechen, ist nur das Paket "cups-libs" installiert zu haben. Dann können nur noch Programme (wie z.B. kprinter) verwendet werden, die die CUPS Bibliotheken direkt verwenden.