| SUSE LINUX – Administrationshandbuch Kapitel 5. Druckerbetrieb / 5.6. CUPS Schnelleinstieg | ||||
|---|---|---|---|---|
 | 5.5. Das CUPS-Drucksystem | 5.7. Drucken aus Anwendungsprogrammen |  | |
| SUSE LINUX – Administrationshandbuch Kapitel 5. Druckerbetrieb / 5.6. CUPS Schnelleinstieg | ||||
|---|---|---|---|---|
| 5.5. Das CUPS-Drucksystem | 5.7. Drucken aus Anwendungsprogrammen | | |
Dieser Abschnitt richtet sich an erfahrene Linux-Benutzer. Alle wichtigen Punkte zu CUPS werden kurz und bündig dargestellt.
Ein genereller Überblick findet sich in folgendem Text der CUPS Dokumentation: "An Overview of the Common UNIX Printing System", die via http://localhost:631/overview.html oder via file:///usr/share/doc/packages/cups/overview.html zur Verfügung steht. Die CUPS Home-Page ist: http://www.cups.org/.
Sowohl auf einem Client- als auch auf Server-System erzeugt ein Kommandozeilentool oder ein Anwendungsprogramm 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.
In der Kommandozeile kann dies beispielsweise so aussehen: lp -d queue -t title -o option1=value1 -o option2=value2 file1 file2. lp ist der Befehl zum Senden, die Optionen -d queue -t title liefern Informationen an den Spooler, -o option1=value1 -o option2=value2 sind Filter-Optionen und file1 file2 die zu druckenden Daten.
Die folgenden Schritte passieren nur auf einem CUPS Server. Ein Rechner, auf dem eine Warteschlange angelegt ist, ist ein Server.
Der Spooler (d. h. cupsd) speichert den Druckjob im Spool-Verzeichnis:
Speichern der Information für den Spooler und den Filter in /var/spool/cups/c<job-number>
Speichern der Daten aus den zu druckenden Dateien in /var/spool/cups/d<job-number>-<file-number>
Die zu druckenden Daten werden gefiltert und die druckerspezifischen Daten an den Drucker gesendet:
Starten des Filtersystems: Dazu gehört das Bestimmen der benötigten Filter, um die druckerspezifischen Daten zu erzeugen, und der Aufbau der sog. „Filterkette“ bzw. „Filter-Pipe“. Außerdem werden die Programme der Filterkette mit passend gesetzten Parametern gestartet.
Starten des sog. Backends, um die druckerspezifischen Daten von der Filter-Pipe an den Drucker weiterzuleiten.
Der Druckjob wird beendet, wenn das Backend fertig ist. Die betreffenden Dateien werdem aus dem Spool-Verzeichnis gelöscht.
Der Hauptzweck des Spooler-Systems ist, Daten vom Sender zum Empfänger zu bewegen. Er nimmt Daten entgegen (aber nur von zulässigen Sendern) und speichert sie bis der Empfänger bereit ist, sie entgegenzunehmen. Dann sendet er die Daten an zulässige Empfänger (und schaltet gegebenenfalls vorher passende Filter dazwischen). Darüber hinaus hält der Spooler Informationen bereit, was mit den Daten passiert ist (z. B. für lpstat -W completed -o).
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. cupsd lauscht am TCP Port 631 auf IPP Aufträge wie z. B. lp -d queue file oder lpstat -t. Er lauscht am TCP Port 631 auf HTTP Aufträge wie z. B. http://localhost:631/printers/. 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). Die Konfiguration für cupsd liegt unter /etc/cups/cupsd.conf.
Der cups-lpd ist der Server für das LPD Protokoll (RFC 1179). Er nimmt Druckjobs an, die via LPD Protokoll am TCP Port 515 eintreffen. Entweder wird xinetd oder inetd als „Wrapper“ für cups-lpd verwendet. Seine Konfiguration findet sich unter /etc/xinetd.d/cups-lpd oder in der „cups-lpd“ Zeile von /etc/inetd.conf.
Das CUPS Software Administrators Manual ist verfügbar via http://localhost:631/sam.html oder via file:///usr/share/doc/packages/cups/sam.html
Ein PPD Datei enthält 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. Genaue Informationen finden sich in der Adobe PostScript Printer Description File Format Specification, Version 4.3.
Dieses Verzeichnis enthält die PPD Dateien, die 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.
Dieses Verzeichnis enthält die ursprünglichen PPD Dateien aus den Paketen cups (CUPS PPD Dateien), cups-drivers (Foomatic PPD Dateien) und cups-drivers-stp (Gimp-Print PPD Dateien) und ggf. zusätzliche PPD Dateien (z. B. PPD Dateien von Druckerherstellern).
Zusätzliche PPD Dateien (z. B. PPD Dateien von Druckerherstellern für PostScript Drucker) können in dieses Verzeichnis kopiert werden, um sie in der YaST Druckerkonfiguration verfügbar zu machen - siehe den Supportdatenbank Artikel Drucker einrichten ab SuSE Linux 8.2: http://portal.suse.com/sdb/de/2003/03/jsmeix_print-einrichten-82.html
Die LinuxPrinting.org/Foomatic Druckerdatenbank besteht aus XML Dateien aus denen die Foomatic PPD Dateien erzeugt werden. Die LinuxPrinting.org/Foomatic Druckerdatenbank ist hier verfügbar: http://www.linuxprinting.org/database.html
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:
Bestimmung des MIME-Typs der ursprünglichen Daten gemäß /etc/cups/mime.types. Wenn es nicht „application/postscript“ ist, dann Umwandlung nach PostScript gemäß /etc/cups/mime.convs. Beispielsweise „text/plain“ wird mit /usr/lib/cups/filter/texttops nach PostScript umgewandelt.
Einfügen der „PostScript Invocation Values“ in den PostScript Datenstrom gemäß der folgenden Zeile in /etc/cups/mime.convs:
Wenn ein nicht-PostScript Drucker mit einer Foomatic PPD Datei verwendet wird, wird das PostScript in druckerspezifische Daten konvertiert, gemäss der folgenden Zeile in jeder Foomatic (Version 3.x) PPD Datei:
Tabelle 5.2. PostScript-Konvertierung in Foomatic PPD-Datei
| main keyword | input MIME type | costs | filter |
|---|---|---|---|
| *cupsFilter: | "application/vnd.cups-postscript | 0 | foomatic-rip" |
Wenn ein nicht-PostScript Drucker mit einer Foomatic PPD Datei verwendet wird, ist foomatic-rip zusammen mit Ghostscript der PostScript Interpreter. Um PostScript in druckerspezifische Daten umzuwandeln, macht foomatic-rip die folgenden Schritte:
Aufbau einer Ghostscript Kommandozeile mit den notwendigen Ghostscript Parametern gemäss der für den jeweiligen Druckauftrag eingestellten druckerspezifischen Optionen (d.h. gemäss der jeweiligen „PostScript Invocation Values“ im PostScript Datenstrom).
In einigen Fällen wird ein „Postfilter“ dem Ghostscript Kommando nachgeschaltet (via „Pipe“):
Für PCL Drucker:
Gewisse Optionen werden durch Änderungen im PCL Datenstrom realisiert (z. B. Papierschachtwahl via perl -e).
Für manche GDI Drucker:
Umwandeln der Ghostscript-Ausgabe in druckerspezifische Daten (z. B. für HP PPA Drucker mit pnm2ppa).
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, 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 ein anderer Ablauf der Filterung.
Weitere Informationen zur Filterung finden sich im Supportdatenbank Artikel Selbst erstellte Filter zum Ausdruck mit CUPS: http://portal.suse.com/sdb/de/2003/05/jsmeix_print-cups-filters.html und im CUPS Software Programmers Manual, das via http://localhost:631/spm.html oder file:///usr/share/doc/packages/cups/spm.html zur Verfügung steht.
Dieses Verzeichnis enthält die verschiedenen Filterprogramme, die das CUPS Filtersystem verwendet, wenn eine PPD Datei beim Einrichten der betreffenden Warteschlange angegeben wurde.
Programme, um die ursprünglichen Daten (z. B. „text/plain“) nach PostScript umzuwandeln.
fügt die „PostScript Invocation Values“ ein und formatiert ggf. das PostScript um (z. B. je zwei Seiten verkleinert auf ein Blatt drucken).
wandelt PostScript in druckerspezifische Daten (z. B. PCL or ESC/P) um.
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: http://portal.suse.com/sdb/de/2003/05/jsmeix_print-cups-filters.html
Wenn beim Einrichten der betreffenden Warteschlange weder eine PPD Datei noch ein „System V style Interface Script“ angegeben wurde, 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.
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 (Ausnahme: „System V style Interface Script“).
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 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), 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 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
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.
Tabelle 5.3. Backend Definition
| backend | DeviceURI syntax (example DeviceURI) |
|---|---|
| parallel | parallel:/dev/lp (parallel:/dev/lp0) |
| usb (traditional) | usb:/dev/usb/lp* (usb:/dev/usb/lp0) |
| usb (new) | usb://make/model?serial=number (usb://HP/DeskJet%20990C?serial=1234) |
| ipp | ipp://server.domain/printers/queue (ipp://host.domain/printers/ps) |
| lpd | lpd://server.domain/queue (lpd://192.168.101.202/LPT1) |
| socket | socket://server.domain:port (socket://192.168.101.202:9100) |
| smb | see the man page of smbspool (smb://user:password@workgroup/server/share) |
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.
Ein Backend kann auch direkt aufgerufen werden. Beispielsweise liefern dabei die Backends „parallel“ und „usb“ die IEEE-1284 Identifikation von angeschlossenen Druckern:
root@host# /usr/lib/cups/backend/parallel
direct parallel:/dev/lp0 "Hewlett-Packard HP LaserJet 1220" "Parallel Port #1"
root@host# /usr/lib/cups/backend/usb
direct usb://HP/DeskJet%20990C?serial=1234 "HP DeskJet 990C" "USB Printer #1"
direct usb://EPSON/Stylus%20COLOR%20900?serial=987 "EPSON Stylus COLOR 900"
"USB Printer #2"
Beim Starten ruft cupsd alle Backends in /usr/lib/cups/backend nacheinander einmal auf. Dadurch ermittelt cupsd, welche Backends auf dem jeweiligen System einsatzfähig sind. Die einsatzfähigen Backends werden mit lpinfo -v angezeigt.
Nehmen Sie keine manuellen Änderungen in den Konfigurationen in /etc/cups vor, wenn es dafür auch geeignete Kommandozeilentools gibt. Die Konfigurationsdateien werden nicht für jeden Druckjob neu eingelesen. Stattdessen hält der cupsd viele Informationen nur im Hauptspeicher und schreibt ggf. Informationen in die Konfigurationsdateien zurück, wenn cupsd beendet wird. Die einzige Ausnahme hiervon stellt /etc/cups/cupsd.conf dar.
Nach Änderungen in dieser Konfigurationsdatei muss 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
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, sondern machen Sie ein Skript aus den passenden Kommandozeilen (normalerweise eine Reihe von lpadmin Aufrufen) und lassen dieses Skript auf den verschiedenen Maschinen 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 Skript ein Protokoll der Einstellungen und Sie können mit dem Skript diese Einstellungen immer wieder herstellen.
In vielen Fällen ist die Reihenfolge der Optionen wichtig. Lesen Sie die Manual-Pages. Beispielsweise sind lpadmin -E -p queue, lpadmin -p queue -E und lpadmin -E -p queue -E alle verschieden.
So legen Sie eine Warteschlange per Kommandozeile an:
root@host# lpadmin -p ps -v parallel:/dev/lp0 -D "PS" -L "2.3" \ -P /usr/share/cups/model/Postscript.ppd.gz -E
Kontrollieren Sie, was angelegt wurde:
user@host$ lpstat -l -a ps -o ps -p ps -v ps
Alternativ nutzen Sie die Anzeige von /etc/cups/printers.conf:
<Printer ps> Info PS Location 2.3 DeviceURI parallel:/dev/lp0 State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 </Printer>
oder die Abfrage via Web-Forntend: http://localhost:631/printers/ps
So ändern Sie eine Warteschlange (z. B. Beschreibung und Standort):
root@host# lpadmin -p ps -D "PostScript printer" -L "2.floor: room3"
Zeigen Sie die druckerspezifischen Optionen und deren Voreinstellungen in /etc/cups/ppd/ps.ppd an:
user@host$ lpoptions -p ps -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 Sie die druckerspezifischen Voreinstellungen in /etc/cups/ppd/ps.ppd:
root@host# lpadmin -p ps -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: http://portal.suse.com/sdb/de/2002/11/jsmeix_print-cups-options.html
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).
Zum Löschen einer Warteschlange verwenden Sie den folgenden Befehl:
root@host# lpadmin -x ps
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 für die druckerspezifischen Optionen.
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
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.
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 ps auf dem Rechner host.domain werden mit einer URL in der Art http://host.domain:631/printers/ps?which_jobs=completed angezeigt.
Das Web-Frontend ist die beste Art, die zum jeweiligen cupsd (bzw. zu dessen Version) passende Dokumentation zu bekommen: http://localhost:631/ für die Dokumentation zum lokalen cupsd oder eine URL in der Art http://host.domain:631/ bzw. http://host.domain:631/documentation.html für die Dokumentation zu einem entfernten cupsd auf dem Rechner host.domain.
Auch die PPD Dateien unter /etc/cups/ppd sind via Web-Frontend verfügbar. Beispielsweise die PPD Datei der Warteschlange "ps" auf dem lokalen Recher (/etc/cups/ppd/ps.ppd) mit der URL http://localhost:631/printers/ps.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.
Auf dem CUPS Netzwerk Server erfolgen Spooling und Filterung. 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 sind Systeme, die lediglich Druckaufträge an den 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 (engl. browse). Dieser Vorgang wird daher „Browsing“ genannt.
Per Voreinstellung ist Browsing aktiviert. Jegliche eintreffende Browsing-Information wird akzeptiert, aber keine Browsing-Information wird versendet - siehe oben.
Konfigurieren Sie auf dem Server die Warteschlangen für die Drucker, die zu dem Server gehören. Erlauben Sie den Zugriff auf die Warteschlangen für die Client-Rechner. Aktivieren Sie das Senden von Browsing-Information an die Client-Rechner.
![[Important]](admon/important.png) | Begrenzte Browsing-Informationen |
|---|---|
Es ist nicht möglich, Browsing-Informationen nur für einen Teil der Warteschlangen eines Servers zu senden. | |
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.
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.
Die Drucker, die zu einem Server gehören, sind genau diejenigen, für die die Filterung auf dem Server erfolgt. Konfigurieren Sie die Drucker so, dass das Drucken für Benutzer auf dem Server korrekt funktioniert.
Fügen Sie in /etc/cups/cupsd.conf einen Eintrag der Art Allow From IP of the server im Abschnitt <Location />...</Location> hinzu, damit die Warteschlangen nicht nur via localhost, sondern auch über den eigentlichen Rechnernamen des Servers zugreifbar sind.
Sollten hierbei Probleme auftreten, gehen Sie folgendermaßen vor:
Setzen Sie LogLevel debug in /etc/cups/cupsd.conf.
Stoppen Sie den cupsd.
Bewegen Sie /var/log/cups/error_log* weg (oder löschen Sie es) damit Sie nicht in zu grossen Logdateien suchen müssen.
Starten Sie den cupsd.
Versuchen Sie erneut, was zu dem Problem geführt hat.
Nun finden sich viele Meldungen in /var/log/cups/error_log*, die zur Ursachenermittlung nützlich sind.
Erlauben Sie den Zugriff auf die Warteschlangen für die Client-Rechner:
Das geht mit YaST oder manuell wie folgt: Fügen Sie Allow From IP of the client oder Allow From network IP . * Einträge im <Location />...</Location> Abschnitt in /etc/cups/cupsd.conf hinzu. Verwenden Sie hier IP-Adressen statt Namen.
Aktivieren Sie das Senden von Browsing-Information an die Client-Rechner:
Das geht mit YaST oder manuell wie folgt: Fügen Sie BrowseAddress host or broadcast IP address Einträge in /etc/cups/cupsd.conf hinzu.
Denken Sie an den Abschnitt Restarting the CUPS Server im CUPS Software Administrators Manual: http://localhost:631/sam.html#RESTARTING bzw. file:///usr/share/doc/packages/cups/sam.html#RESTARTING
Der letzte Schritt 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.
Gehen Sie wie folgt vor:
Aktivieren von /etc/init.d/cups, so dass der cupsd beim Booten des Client-Rechners gestartet wird. Dazu entweder den YaST Runlevel Editor oder insserv verwenden.
Starten Sie cupsd.
Im Normalfall ist es empfohlen, sonst nichts weiter zu konfigurieren. Weder lokale Warteschlagen auf den Clients oder Voreinstellungen für cupsd auf den Clients sollten zusätzlich verändert werden müssen.
Um optional bestimmte Server im Netz nach deren Browsing-Informationen abzufragen, gehen Sie wie folgt vor:
Fügen Sie BrowseAllow IP of the desired server und BrowseDeny IP of the unwanted server Einträge in /etc/cups/cupsd.conf hinzu. Verwenden Sie IP-Adressen statt Namen. 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 (engl. polling):
Fügen Sie für jeden Server einen BrowsePoll IP of the server:631 Eintrag in /etc/cups/cupsd.conf hinzu. Verwenden Sie IP-Adressen statt Namen. Der betreffende Port ist 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 Manual-Pages).
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:
Stoppen und Deaktivieren des cupsd (YaST Runlevel Editor oder insserv).
Den passenden ServerName IP of the desired server Eintrag in /etc/cups/client.conf 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 -h im Druckbefehl).
Das 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.
