CUPS: Linux-Drucken leicht gemacht -- für Heimanwender wie für ...

CUPS:
Linux-Drucken leicht gemacht -für
Heimanwender wie für Netzwerkadministratoren
von Kurt Pfeifle, kpfeifle.at.danka.de
http://www.danka.de/printpro/faq.html
Stellt Euch vor: ein Freund kommt mit seinem Linux-Laptop zu Besuch. Ihr vernetzt Euch (weil Ihr an einem
gemeinsamen Projekt arbeiten möchtet). Irgendwann möchte er von seinem eigenen Rechner aus "schnell was
ausdrucken" und... es geht einfach! Es geht, ohne dass er extra den Treiber für Euren Drucker installieren
müsste, ja, ohne dass er Eurem neuen super-duper-Tintenstrahler mit 7 Farben, variabler Tinten-Tröpfchengröße
und Photo-Modus überhaupt kennen müsste. Utopisch? Nicht mit CUPS!
Denn seit zwei Jahren verbreitet sich, anfangs fast unbemerkt, zwischenzeitlich immer schneller, eine neue
Druck-Software in der Linux- und UNIX-Welt: CUPS, das Common UNIX Printing System steht beinahe
von Anfang an unter der GPL (GNU General Public License). Es hat vor allem bei vielen experimentierfreudigen
Heimanwendern begeisterte Anhänger gefunden, die mit seiner Hilfe erstmals brauchbaren
Output oder gar Foto-Qualität ihren Tintenstrahlern entlockten.
Dabei wird häufig übersehen: CUPS ist gar nicht auf den Einzelplatz beschränkt; es zeigt seine eigentlich
Stärke darin, dass es alles einen Funktionen netzwerkweit zur Verfügung stellen kann: ein Rechner mit
CUPS kann sogar drucken, wenn er gar keine eigenen Treiber installiert und konfiguriert hat. CUPS verschafft
seinen unterstützten Betriebssystemen in dieser Hinsicht also einen Technologievorsprung vor
gewissen Konkurrenzprodukten aus Redmont und Cupertino ;-)
Die CUPS-Entwickler (Easy Software Products, eine aus 3 Mitarbeitern bestehende Firma) vertreiben die
Software auch als kommerzielles Produkt: sie heißt dann ESP PrintPro. Lizenzeinnahmen dienen dem
Lebensunterhalt der Entwickler und finanzieren so die Weiterentwicklung der GPL-Version.
Was ist neu an CUPS?
CUPS lässt den bisherigen Standard für das Drucken im Netzwerk weit hinter sich: es ersetzt den Line
Printer Daemon (LPD nach RFC 1179) durch den neuen Industrie- und IETF-Standard Internet Printing
Protocol (IPP). Das IPP, Version 1.1, hat bei der Internet Engineering Task Force (IETF) zwischenzeitlich
den Status eines "proposed standard" erreicht. Es wurde von der Printer Working Group (PWG,
ein lockerer Zusammenschluss von Printer-Herstellern unter Beteiligung von Software-Firmen wie IBM,
Microsoft, Novell und SUN) ausgearbeitet.
Das IPP stellt Funktionen zur Verfügung, die das Drucken plattformübergreifend vereinheitlichen sollen
und zugleich einige zentrale Schwächen des LPD beheben:
Authentifizierung von Benutzern über Passwörter oder Certificates;
Verschlüsselung von Druckdaten bei der Übertragung zwischen Hosts oder zum Drucker;
Bekanntgabe verfügbarer Drucker im Netz an jeden Client beim Booten oder Einloggen.
Das IPP erfindet jedoch das Rad nicht neu. Es setzt auf einem bewährten und robusten Datenübertragungsprotokoll
auf, das seine Bewährungsprobe im Internet längst überstanden hat: auf HTTP 1.1. Zwar
fügte die PWG dieser Basis einige für das IPP-Drucken spezifische Erweiterungen hinzu. Jedoch werden
zugleich die Vorteile voll und ganz genutzt, die das Aufsetzen auf einen bereits etablierten Standard bietet:
so können TLS (Transport Layer Security) oder SSL3 (Secure Socket Layer, Vers. 3) zum Zweck der
Verschlüsselung, LDAP (Lightweight Directory Access Protocol) oder SLP (Service Location Protocol)
1

für die Abfrage verfügbarer Drucker im Netz vor den IPP-Karren gespannt werden. Proxys (also Vermittlungs-
und Zwischenspeicherungs-Rechner, die oft an den Grenzen zwischen Intra-Nets und dem Internet
Dienst tun) können ohne Änderung im Quellcode ihres Programms IPP-Daten vermitteln und weiterleiten.
Betriebssysteme (Server, Client und Standalone):
CUPS und ESP PrintPro sind erhältlich für Linux und UNIX, insbesondere für...
...alle Linux-Versionen ab Kernel 2.0 (auf Intel-Prozessoren);
...SUN-Solaris (für Intel und SPARC-Prozessoren) ab Version 2.5 bis zur neuesten Version (8);
...HP-UX ab Version 10.20 bis zur neuesten Version (11.0);
...Silicon Graphics IRIX ab Version 5.3 bis zur neuesten Version (6.5);
...Digital Unix ab Version 4.0;
...Compaq Tru64 Unix ab Version 4.0;
...OSF/1 ab Version 4.0.
CUPS ist zwischenzeitlich auch auf *BSD portiert worden (allerdings nicht von den CUPS-Entwicklern
selbst). Eine Version für IBM-AIX ist in Vorbereitung. ESP PrintPro- oder CUPS-Clients beliebiger
unterstützter Linux- und UNIX-Versionen können cross-plattform auf ESP PrintPro- oder CUPS-Server
aller unterstützten Linux- und UNIX-Versionen drucken.
Warum wird der LPD beerdigt?
Zum Zeitpunkt, als der LPD entstand, Mitte der 70er Jahre, war das heutige Internet mit seinen -zig Millionen
über TCP/IP verbundenen Rechnern noch unvorstellbar (sein Vorläufer hat erst ca. 1985 die Anzahl
von 1.000 vernetzten Rechnern erreicht). Fragen von Authentifizierung und Verschlüsselung waren
entsprechend unwichtig und spielten noch keine zentrale Rolle. Drucker hatten noch keinerlei "Eigenintelligenz":
diese erlaubt ihnen heute beispielsweise, ganze Seiten als Farb-Grafik aus entsprechenden
PostScript-Anweisungen als Bitmap-Muster mit 1200 dpi Auflösung zu berechnen, im eigenen Speicher
zwischenzulagern und dann "auf ein Mal" auf ein Blatt aufzutragen. Drucker der damaligen Zeit hämmerten
Buchstabe für Buchstabe und zeilenweise ASCII-Text auf Papier, das in Form einer Endlos-Schlange aus
einem Karton gezogen wurde. Drucker waren noch keine eigenständige Knoten im Netz, sondern immer
direkt an einen der "Gross"-Rechner angeschlossen, der sie dann u.U. per LPR/LPD seinen "Nachbar"-Rechnern
zur Verfügung stellte.
Das LPD/LPR-Protokoll war nie ein verbindlicher Standard. Als "RFC 1179" wurde es erst 1990
niedergeschrieben. Es kam bei der IETF nie über den den Status "informational" hinaus. Es brachte
lediglich die Praxis-Konventionen zu Papier, die sich zum damaligen Zeitpunkt herauskristallisiert hatten
und an die sich als Minimalbasis die meisten Hersteller auch fortan irgendwie hielten... oder auch nicht.
Je weiter die Drucker- und Netzwerktechnik sich in der Folgezeit entwickelte, umso mehr Abweichungen
und herstellerspezifische Erweiterungen flossen in die einzelnen Implementierungen ein -- und umso unvereinbarer
miteinander wurden diese. Hersteller wie HP versuchten gar, mit "HP JetDirect" einen eigenen
Standard zu etablieren. In der UNIX- und Linux-Welt wurden verschiedenen Versuche unternommen,
über den klassischen Line Printer Daemon hinauszugehen: LPRng, PPR, PDQ, PLP u.a. sind verschiedene
Versuche, dessen Beschränkungen aufzuheben und etwas Neues an seine Stelle zu setzen. Sie setzten sich
jedoch nie auf breiter Front durch.
Rückwärtskompatibilität
Muss man befürchten, dass bei breiter Einführung des IPP alte Anwendungen, Programme und Shellscripte,
die drucken wollen, hinfällig werden? Oder dass herkömmliche Drucker nicht mehr verwendbar sind? Nein
-- das IPP beugt diesen Gefahren vor: es kann eingeführt werden, ohne dass bestehende Anwendungen in
Gefahr kommen, nicht mehr drucken zu können, und ohne ihre Druck-Schnittstellen umzuprogrammieren
zu müssen: es hat ein "Mapping" zum LPD vorgesehen, das die wichtigsten Funktionen berücksichtigt.
CUPS selbst setzt dies beispielsweise dadurch um, dass es die unter Linux verwendeten Druckbefehle
"lpr" und "lp" ebenfalls versteht (es setzt allerdings eigene Versionen an die Stelle der alten, die zusätzlich
2

zu den bisher bekannten auch mit den neuen CUPS-spezifischen Parameter und Optionen umgehen können).
Der CUPS-Daemon
Im Mittelpunkt der CUPS-Software steht der CUPS-Daemon cupsd, auch scheduler genannt. Er ist für
das Steuern aller druckrelevanten Abläufe verantwortlich: er nimmt Druckjobs entgegen (sowohl vom localhost
als auch von entfernten Rechnern im Netz), speichert sie zwischen, führt sie den gegebenenfalls
erforderlichen Filtern zu, sortiert sie dann in die Warteschlangen ein und ruft das richtige backend auf,
wenn es daran geht, den fertigen Job zum Ausgabegerät zu schicken.
Natürlich, das ist nichts eigentlich Neues, das machen im Grossen und Ganzen auch andere, traditionelle
Druck- und Spool-Systeme. Seine drei "Killer"-Features bezieht CUPS aus:
der eingangs erwähnten vollständigen Unterstützung des Internet Printing Protocol samt einem
zugehörigen Web-Interface, das von jedem Browser aus den Zugriff auf Druck- oder Administrations-Funktionen
ermöglicht;
dem Drucken der Clients auf die serverseitig konfigurierten Endausgabegeräte, ohne dass diese
Clients auch nur einen einzigen Drucker einrichten müssten;
seiner Rückwärtskompatibilität und Multi-Protokollfähigkeit durch Unterstützung für Clients, die
noch mit Windows ("Samba"), Älteren UNIX-Systemen ("LPD") oder Apple MacOS ("NetATalk")
arbeiten.
Die Client-Server-Architektur von CUPS
In der CUPS-Terminologie ist jeder Rechner, der lokal einen "Treiber" installiert hat und direkt mit einem
Druckausgabe-Gerät kommuniziert, ein Server. Druckertreiber unter Linux oder UNIX sind nicht direkt mit
solchen unter Windows vergleichbar. Bei CUPS besteht die Treiberfunktionalität in der Aufbereitung eines
Druckjobs mittels diverser "Filter", die das Druckformat für den Drucker so präparieren, dass es von
diesem auch verdaut werden kann. Hinzu kommt für jeden "Treiber" eine Druckerbeschreibungsdatei
(PPD, PostScript Printer Description), welche gerätespezifische Optionen beschreibt und wie diese
anzusteuern sind, und ein "backend", das für das Verschicken der Jobs über das bei der Druckerinstallation
gewählte Protokoll (parallel, seriell, USB, Netzwerk/LPD, Netzwerk/HP JetDirect, Netzwerk/IPP)
zuständig ist. Prinzipiell kann jeder CUPS-Rechner seine lokal installierten Drucker im lokalen Netz anderen
Rechnern zur Verfügung stellen. Diese werden dadurch zu seinen Clients.
Ein Client ist ein Rechner, der selbst keinen Drucker installiert hat, jedoch die Druckdienste eines anderen
Rechners in Anspruch nehmen kann. Wird ein CUPS-Rechner im Netz als Server verwendet, dann ist dieser
auch für die komplette Job-Aufbereitung verantwortlich. Ein Standalone-Rechner mit einem
CUPS-Drucksystem an Bord stellt demnach einen Server dar, der sein eigener Client ist.
CUPS-Server sind Webserver auf Port 631 mit IPP-Erweiterungen
Die CUPS-Entwickler haben für die Konfiguration des CUPS-Daemon bewusst eine Ähnlichkeit zu dem
bekannten Webserver Apache gewählt. Da IPP auf HTTP 1.1 beruht, gleicht die Konfigurationsdatei von
CUPS derjenigen des weitverbreiteten Werbservers. Sie findet sich unter /etc/cups/cupsd.conf und ist
ähnlich aufgebaut wie die httpd.conf.Für jeden Zweck gibt es Einstellungen: Server-Name, Name und Ort
der Log-Dateien, verwendeter Server-Port, Zugriffsmasken, Absicherung mittels Passwörtern usw. In
diesem Paper wird im Folgenden auf manche dieser Einstellungen genauer eingegangen.
Browsing -- automatische Veröffentlichung von Druckerlisten im LAN
CUPS-Rechner halten untereinander über den IPP-Port 631 (Standard-konform; jedoch konfigurierbar)
Verbindung. Nicht nur die Druckdaten werden über das HTTP-ähnliche Protokoll über diesen Port weitergereicht,
auch andere Informationen werden ausgetauscht.
Dabei spielt das "Browsing" eine zentrale Rolle: jeder CUPS-Rechner, in dessen cupsd.conf sich der Eintrag
"Browsing On" befindet, macht per UDP-Broadcast die Namen, verfügbaren Zusatz-Infos und einige
Status-Bits der betreffenden Drucker im LAN in regelmässigen Abständen bekannt. (Ein Rechner mit der
kommerziellen CUPS-Version ESP PrintPro tut dies nur, wenn eine entsprechende Lizenz geladen ist.)
3

Diese Zeitabstände werden über die Direktive "BrowseIntervall 30" z.B. auf eine halbe Minute festgelegt.
Standardmäßig "posaunt" der CUPS-Daemon seine Browsing-Informationen über alle verfügbaren
Schnittstellen in die LAN-Welten, mit denen er verbunden ist, denn es gilt "BrowseAddress
255.255.255.255" als Voreinstellung.
In älteren CUPS-Konfigurationen (wie sie anfänglich etwa bei Linux Mandrake 7.2 verwendet wurden)
führte diese Voreinstellung allerdings dazu, dass vorhandene ISDN-Karten sich in Minutenabständen beim
Internet-Provider einwählten: sie wollten so der Broadcast-Aufforderung des CUPS-Daemon nachkommen.
Linux-Neulinge waren damit oft überfordert: sie wussten nicht, wie dieses Verhalten in den Griff zu
kriegen war -- dabei gab es natürlich schon immer die Möglichkeit, das Broadcasting gezielt auf eine
bestimmtes Netzinterface oder auf einen kleineren Adress-Bereich einzugrenzen: die Direktive
"BrowseAddress 10.160.16.255" z.B. schränkt die Bekanntgabe der verfügbaren Drucker effektiv auf
das Heimat-Subnetz des Autors ein.
Damit die Broadcasts volumenmäßig überschaubar bleiben, stehen pro Drucker stehen für jede Broadcast-Nachricht
maximal 1024 Bytes zur Verfügung. In der Praxis kommt man meist mit 100 bis 150 Bytes
aus -- denn nicht für jeden Drucker wird die maximal mögliche Anzahl von Buchstaben zur Beschreibung
seines Standorts oder seiner weiteren Eigenschaften auch tatsächlich ausgenutzt (diese Beschreibungen
kann der Administrator optional als Zusatz zum Druckernamen bei der Druckerinstallation eingeben; sie
werden den Anwendern in den GUIs oder im Browser angezeigt, wenn sie die Druckerliste anschauen).
Cachen der Druckerlisten bei den Clients
Alle CUPS-Daemons "lauschen" auf dem Port 631; so fangen sie die Broadcast-Informationen der Server
auf und legen sie in einem lokalen Cache ab. Die Gültigkeitsdauer des Cache ist ebenfalls veränderlich; sie
wird über die cupsd.conf-Direktive "BrowseTimeout 300" z.B. auf 5 Minuten festgelegt.
Browsing funktioniert nur bis zum jeweils nächsten Router oder Gateway; dahinter werden laut
TCP/IP-Spezifikation keine Broadcasts weitergegeben, denn diese müssen sich auf das lokale LAN
beschränken. Sollen bei einem Client nur die Informationen eines bestimmten CUPS-Servers verwertet
werden, so kann dies über die Zeilen von der Art "BrowseAllow 10.160.16.255", "BrowseDeny
10.160.16.55" gemeinsam mit "BrowseOrder Allow,Deny" gezielt beeinflusst werden. Im gegebenen
Beispiel würde der Client alle Browse-Packete der Server des lokalen Netzes akzeptieren, jedoch diejenigen
von dem Rechner mit der IP-Adresse 10.160.16.55 ignorieren, wenn er die Liste verfügbarer Drucker
generiert. (Auf dem genannten Rechner experimentiert mein Kollege Hansjörg mit ständig wechselnden
CUPS-Konfigurationen und manchmal dutzenden verschiedenen Druckern -- für mich würde dies eine viel
zu unübersichtliche Browse-Liste ergeben... ;-)
Bei funktionierender Namensauflösung können diese Anweisung natürlich auch in der Form "BrowseAllow
.systemsupport.danka.de", "BrowseDeny development.systemsupport.danka.de" gegeben
werden; in anderen Worten: Host- und Domain-Namen sind natürlich ebenfalls überall da legal, wo
IP-Adressen in cupsd.conf-Direktiven verwendet werden.
"Zero Administration" for Clients
Für Netz-Administratoren und Anwender ist es sicherlich die bequemste Alternative, einen gut funktionierenden
und flexiblen Druckdienst in Anspruch zu nehmen oder zu gewährleisten, wenn die Druckserver
im Netz so eingestellt sind, dass sie ihre installierten Drucker aktiv per UDP-Rundspruch bekannt geben.
Jede Änderung auf den Servern ist innerhalb von 30 Sekunden (oder dem jeweils eingestellten "BrowseIntervall...
") für alle Clients sichtbar und verbindlich:
Der Chef hat den Etat für die Nachrüstung des Abteilungsdruckers mit einem Finisher und einer
Sorter-Mailbox genehmigt? OK, sobald der Treiber auf dem Server konfiguriert ist, können die
Clients darauf zugreifen (Naja, vielleicht dauert es doch 1 Minute... ;-).
Der Abteilungsleiter hat entschieden, dass der teure Farbdrucker nur noch nach Eingabe eines
Passworts benutzt werden darf? Kein Problem -- dieÄnderung der Konfiguration auf dem Server ist
in Minutenschnelle for die Clients wirksam...
In keinem dieser Fälle braucht direkt bei den Clients eingegriffen zu werden.
4

Eine CUPS-Vorführung, die Windows-Administratoren leicht vor Neid erblassen
lässt...
Mit folgender Vorführung lässt sich eine verblüffende Wirkung erzielen:
Angenommen, es existiert bereits ein CUPS-Server (z.B. unter Linux) im LAN, auf dem 20 verschiedene
Drucker fertig konfiguriert sind. Dann wird unter den Augen der Zuschauer in Minutenschnelle CUPS oder
ESP PrintPro auf einem weiteren Rechner, z.B. auf einer SUN-SPARC-Maschine installiert. Während der
Software-Installation sei die SPARC durch Ziehen des Steckers vom LAN getrennt. Dann wird beispielsweise
das Fenster des ESP PrintPro "Printer Managers" geöffnet. Das Fenster ist anfangs (natürlich) leer.
Nach Wiederherstellen der Netz-Verbindung füllt sich innerhalb weniger Sekunden das Fenster mit allen
20 verfügbaren Druckern, da die SPARC jetzt Zugang zu den Browsing-Informationen des CUPS-Servers
hat. Und wenn man dann vorführt, wie jeder beliebige "aus dem Nichts aufgetauchte" Drucker "mit allen
verfügbaren Schikanen" druckt (z.B. Heftung, Lochung, Duplex, andersfarbiges Deckblatt...), nimmt das
Staunen beinahe kein Ende... Warum bloß kommt einem dabei das Schlagwort von der "Zero Administration
for Clients" in den Sinn?
Polling -- aktive Beschaffung der Druckerlisten durch die Clients bei den Servern
Es mag jedoch Fälle geben, in denen ein Drucker-Browsing wegen des damit verbundenen Server-Broadcast
vom Administrator nicht erwünscht ist, selbst wenn der dadurch verursachte Netzverkehr
noch so minimal ist. In diesem Fall besteht die Möglichkeit, die Clients anzuweisen, nicht erst passiv auf
Broadcast-Infos zu warten, sondern sich die benötigten Druckerinformationen direkt beim zuständigen
Server selbst zu besorgen. Dazu muss jedoch jeder einzelne Client entsprechend konfiguriert werden: die
Anweisung "BrowsePoll 10.160.16.55:631" bewirkt diese Abfrage nach den verfügbaren Druckern
beim genannten Server auf Port 631, sobald gedruckt werden soll. (In Wahrheit würde ich diesen speziellen
Server natürlich niemals wählen, da mein chaotischer Kollege Hansjörg, dem dieser Rechner gehört.... OK,
ich hör' ja schon auf, siehe jedoch oben ;-)
"BrowsePoll.. "-Anweisungen dürfen mehrfach in der Konfigurationsdatei vorkommen; dann fragt der
Client eben mehrere Server ab.
Das Polling ist vor allem dann unverzichtbar, wenn man einen Server nutzen will, der hinter einem Router
oder Gateway (d.h. in einem anderen Sub-Netz) sitzt.
BrowseRelay -- Server in anderen LANs lokal nutzbar machen
Da kein Broadcast die Hürde eines Routers oder Gateways überwinden kann, braucht man Möglichkeiten,
Server und ihre Drucker in einem Nachbarnetz zu nutzen, deren broadcasts "hier" nicht ankommen.
Natürlich könnte man jeden Client, der die lokalen Drucker (falls vorhanden) per lokalem Server-Broadcast
mitgeteilt bekommt, zusätzlich zum "Polling" der entfernten CUPS-Server auffordern. Das würde bedeuten:
bei jedem einzelnen Client wären die entsprechenden Einträge in der cupsd-conf erforderlich -entsprechend
viel Arbeit für den Administrator -- sowohl bei der Erstkonfiguration, als auch bei jeder
späteren Änderung.
Die elegantere Alternative ist folgende: man bestimmt einen der CUPS-Rechner im LAN zum
"Browse-Relay". Man kann hierfür einen Rechner benutzen, der ohnehin in beiden Netzen "zu Hause" ist,
z.B. einen Gateway- oder Router-Rechner. Dies bewirkt beispielsweise ein Eintrag der Form
"BrowseRelay 192.78.215.80 10.160.31.255/255.255.240.0", der die Broadcasts des entfernten
Servers192.78.215.80 aufzeichnet und dessen Drucker im Netz 10.160.16.0 (dieses ist ge-"subnet"-tet mit
der Netzmaske 255.255.240.0) veröffentlicht. (Die Clients nehmen dann im Falle des Drucken-Wollens mit
dem entfernten Druckserver direkten Kontakt auf, da ihnen dessen Adresse durch das Browse-Relay
bekannt gemacht wurde).
Manchmal ist jedoch dies nicht praktikabel (z.B. wenn der Router gar kein Linux-Rechner ist). Auch kein
Problem: man macht einfach einen "normalen" lokalen CUPS-Rechner zum Browse-Relay; dieser wird
beauftragt, einen oder mehrere der entfernten Server zu pollen, indem man in seine Konfigurationsdatei
eine entsprechende Anweisung "BrowsePoll..." schreibt. Zusätzlich wird er mit der Direktive
5

"BrowseRelay 127.0.0.1 255.255.255.255" dazu gebracht, alle ihm selbst bekannten Drucker in der
gesamten erreichbaren Umgebung zu publizieren.
"BrowseRelay"-Anweisungen dürfen ebenfalls mehrfach in der Konfigurationsdatei vorkommen.
Schnittstellen zu den Clients:
Diese Schnittstellen dienen dem Empfang eingehender Druckjobs und der Kommunikation mit den
Clients (zwecks Statusmeldungen etc.):
für ESP PrintPro- oder CUPS-Clients (Linux- und unterstützte UNIX-Plattformen) wird standardmäßig
das IPP verwendet;
Linux-, Apple- und UNIX-Clients können wahlweise auch über LPR/LPD bedient werden;
bei älteren Windows-Clients (Win9x, WinNT4.0) kann wahlweise LPR/LPD (nach RFC 1179),
SMB/CIFS (Standard-Netzprotokoll von Microsoft-Systemen, hier verwirklicht über Samba)
oder IPP (wenn eine entsprechende Client-Software zum Einsatz kommt) verwendet werden;
da Microsoft innerhalb Windows 2000 das IPP ausreichend kompatibel implementiert hat, können
Clients mit diesem Betriebssystem ohne weitere Software-Installation über ESP PrintPro mit
den Druckern verbunden werden;
Apple-Rechner können wahlweise über LPR/LPD, IPP oder AppleTalk kommunizieren (bei AppleTalk
muss auf Server-Seite das Packet NetATalk installiert sein);
Backends -- Kommunikation zwischen Server und Drucker
Drucker können über verschiedene Schnittstellen und Protokolle mit dem Server verbunden werden: parallel
oder seriell, per USB- oder Netzwerkanschluss (IPP, LPD, HP JetDirect, SMB/"Samba" u.a.). Diese
Aufgabe übernehmen die sogenannten CUPS-backends; für jedes Protokoll ist ein anderes Backend
zuständig (insofern entsprechen sie ungefähr den von Windows her bekannten "Druck-Monitoren").
Per IPP können Druckaufträge weitergeleitet werden an andere CUPS-Printserver, an IPP-fähige Drucker
oder andere IPP-fähige Printserver. Derzeit gibt es auf dem Markt mehr als 200 Geräte, die
IPP-Unterstützung eingebaut haben. Dazu gehören alle internen und externen HP JetDirect Printserver der
Baureihen 300X, 400N, 500X und 600N (beispielsweise in der LaserJet 8000-Serie im Einsatz) sowie die
neuen Generationen der Hersteller Axis, i-data, Lexmark, SEH und vieler anderer.
Per LPD können eigentlich alle herkömmlichen Netzwerkdrucker angesprochen werden (oder auch andere
Druckserver, an die aus irgendeinem Grund Aufträge weitergereicht werden sollen); es ist sozusagen der
"kleinste gemeinsame Nenner" aller Netzwerkdrucker..
HP JetDirect (auch unter der Bezeichnung AppSocket-Protokoll bekannt) ist das Mittel der Wahl, wenn der
Zieldrucker dieses Protokoll beherrscht (das tun zwischenzeitlich auch viele Nicht-HP-Geräte!), denn es
hat bi-direktionale Fähigkeiten und ermöglicht gewisse Status-Rückmeldungen, die über LPR/LPD nicht
erhältlich sind.
Freigegebene Drucker, die an Drucker-Ports von Windows-Rechnern hängen, können mittels Samba
beschickt werden. Hierfür ist allerdings die zusätzliche Installation von Samba ab 2.0.6 auf dem
CUPS-Server nötig. Denn dann wird über das Tool "smbspool", das als Bestandteil von Samba ausgeliefert
wird (und ebenfalls von Michael Sweet programmiert wurde) und über einen symbolischen Link
mit dem smb-backend verknüpft werden muss, das Windows-eigene SMB-Protokoll verwendet. Dieser
Sym-Link wird über den Befehl "ln -s ‘which smbspool‘ /usr/lib/cups/backend/smb" angelegt.
Somit erlaubt es die Gesamtheit der "eingebauten" Backends CUPS, Druckjobs an herkömmliche Drucker
aller Art zu verschicken. Schließlich werden die nicht von heute auf morgen verschwinden oder CUPS und
dem IPP zuliebe verschrottet werden... ;-)
6

Backends:
Die backends dienen dem Versand von Druckdaten zu den Ausgabegeräten oder zu anderen Servern im
Netzwerk. Sie sind für verschiedene Hardware-Schnittstellen und Übertragungsprotokolle verfügbar.
Künftige Erweiterungen sind leicht möglich, anpaßbar an die weitere Entwicklung der Technik:
serielleAnschlüsse (COM-Ports" in der Windows-Welt);
parallele Anschlüsse;
USB-Schnittstellen;
div. Netzwerkverbindungen (mit den Protokollen HTTP, IPP, SMB/CIFS ["Samba"], AppSocket
["HP JetDirect"], AppleTalk ["NetATalk"])
Alle Backends sind in dem Verzeichnis /usr/lib/cups/backend/ zu Hause. Dazu gehören auch jeweils
eigene Backends für die lokalen seriellen, parallelen bzw. USB-Schnittstellen.
Clients aus der Apple-, Microsoft- oder übrigen UNIX-Welt:
Nicht-CUPS-Clients aus der UNIX-, der Apple MacOS- oder MS Windows-Welt erhalten ebenfalls Zugriff
auf die Dienste eines CUPS- oder ESP PrintPro-Druckservers. Welches Protokoll dabei verwendet
werden kann, hängt von den Vorlieben des Administrators oder eventuell angetroffener Notwendigkeiten
ab:
über AppleTalk: Apple MacOS;
über das traditionelle LPR/LPD-Protokoll: Apple MacOS, UNIX, MS Windows und andere;
über SMB/CIFS (Samba"): MS Windows-Rechner aller Generationen;
über IPP: MS Windows 2000 von Haus aus, sowie alle Betriebssysteme, bei denen
IPP-Client-Software installiert ist.
Unter Umständen ist die Installation zusätzlicher, nicht im Lieferumfang von CUPS oder ESP PrintPro
enthaltener Software auf Server oder Clients erforderlich (beispielsweise das OpenSource-Packet Samba).
PostScript erfordert Interpretation
Fast alle Anwendungsprogramme, die unter Linux (oder UNIX) druckbaren Output erzeugen, benutzen
hierfür PostScript. PostScript ist eine Programmiersprache, die darauf spezialisiert ist, Seitendarstellungen
von Dokumenten aller Art auf eine abstrakte Art zu beschreiben. PostScript benutzt hierfür eine spezielle
Syntax, die Linien, Kurven, Füllungen, Buchstaben, Schrift-Fonts und viele weiteren Grafikobjekte sowie
deren jeweilige Position, Größe und Farbe definiert, die zusammen das fertige Seitenbild auf dem
bedruckten Blatt ergeben. PostScript ähnelt daher stark einer Art von "Vektor"-Format (obwohl es in sich
natürlich auch "fertig gerasterte" Elemente einbetten kann).
Die "Marking Engine" eines Druckers bringt jedoch alle Bilder nur punktweise zu Papier -- auch eine Linie
ist hier eigentlich nur eine sehr dichte Aneinanderreihung von Punkten. Da PostScript die Anordnung von
Toner oder Tinte auf dem Papier nicht pixelweise beschreibt, muss das adäquate "Raster"-Format für den
Drucker zuerst durch einen aufwendigen "Raster Image Prozess" (RIP) aufbereitet werden. In
PostScript-Druckern sind Hardware-RIPs in Form spezialisierter PostScript-Prozessoren eingebaut. Diesen
Druckern kann man das durch das Linux-Programm erzeugte PostScript direkt übergeben; sie sind in der
Lage, PostScript-Dateien schnell zu berechnen und zu verarbeiten.
Für Nicht-PostScript-Drucker muss das von ihrer Marking Engine verwendete Rasterformat zuerst
"mundgerecht" zubereitet werden. Unter Linux ist hierfür das ghostscript-Packet zuständig; ghostscript
stellt also eine Art Software-RIP dar. Da jeder Hersteller eigene, proprietäre Rasterformate für seine
Drucker verwendet (und diese manchmal auch noch von Modell zu Modell wechselt), gibt es eine
entsprechende Vielzahl zuständiger ghostscript-"Filter". Diese Filter-Programme sind für die
entsprechende Daten-Konversion zuständig.
Besonders heikel ist die Aufgabe bei modernen Tintenstrahlern: diese verwenden heute bereits 7 verschiedene
Tinten-Tönungen (zusätzlich zu den 3 verwendeten Grundfarben eine jeweils hellere
7

Schattierung plus Schwarz) und sie können außerdem noch Tröpfchen verschiedener Größen auf Papier
spritzen, um auch jede noch so feine Abstufung in Foto-Qualität darstellen zu können.
Dabei kommt es nicht alleine auf das reine 2-dimensionale Bitmap-Layout des fertigen Rasterbildes auf
dem Papier an, sondern auch auf die Reihenfolge der Übertragung einzelner Punkt-"Zeilen" zum
Druck-Kopf. Denn moderne Druck-Köpfe haben mehrere Düsen für jede Farbe: bei jeder waagrechten
Bewegung des Druckkopfes sind somit jeweils mehrere "Zeilen" aktiv, das Bild wird in einem Prozess
aufgebaut, der einer Art von Weben gleicht.
Da die Hersteller-Spezifikationen für die Rasterformate und deren Übertragung an die Druckköpfe den
Programmierern der ghostscript-Filter meist nicht zugänglich sind, ist es extrem schwierig, brauchbare
Ergebnisse zustande zu bringen. Viele moderne Tintenstrahldrucker haben mit den Standard-ghostscript-Treibern
ein entsprechend schlechtes Ergebnis beim Farbdruck.
Exkurs: Das Gimp-Print-Projekt
Das wird sich wohl bald entscheidend ändern -- vor allem dank des Gimp-Print-Projektes. Dieses hat mit
dem stp-Treiber bereits einen hervorragenden Anfang gemacht. "stp" kann bereits eine Vielzahl von Epson,
Canon- und HP-Druckern zu Foto-ähnlicher Ausgabe-Qualität an-"treiben"...
Gimp-Print entstand ursprünglich als reines Plug-In zum bekannten Bildbearbeitungsprogramm GIMP.
Diese wurde übrigens ebenfalls von Michael Sweet, dem heutigen Haupt-Entwickler von CUPS, ins Leben
gerufen. Seit er mit CUPS begann, ist die Leitung des Gimp-Print-Projekt in die Hände von Robert Krawitz
übergegangen; Michael trägt jedoch immer noch zur Code-Basis bei.
Das Gimp-Print-Packet lässt sich von http://gimp-print.sourceforge.net/ als Quell-Packet herunterladen.
Aus dieser Code-Basis lässt sich der stp-Filter in drei verschiedenen Inkarnationen kompilieren:
als Plug-In für den GIMP,
als "normaler" ghostscript-Filter (ergänzend braucht man dann noch Grant Taylor's foomatic, wenn
man diesen ghostscript-Filter unter CUPS nutzen will),
und als Filter in einer Form, die sich nahtlos in CUPS einpasst und mehr als 100 modellspezifische
PPDs für HP-, Canon- und Epson-Tintenstrahler mitbringt.
Welche Version man braucht, wird über einen Parameter beim Aufruf des configure-Scripts gesteuert:
"./configure --with-ghost --with-foomatic --with-gimp --with-cups" lässt des anschliessende
"make"-Kommando alle Varianten gleichzeitig erzeugen.
MIME-Types -- Bestimmung und Kennzeichnung von Dateiformaten
CUPS verwendet als Grundlage für seinen zentralen Filter "pstoraster" ein modifiziertes ghostscript.
Dieses beruht zwar noch auf der Version 5.50, bringt jedoch bei vielen Druckern bereits weitaus bessere
Ergebnisse zustande als das Standard-ghostscript. Da CUPS außer PostScript auch PDF, Text und viele
Grafikformate direkt verarbeiten kann (für diese sind dann Filter mit Namen wie pdftops, texttops, imagetops
oder imagetoraster zuständig), muss es in der Lage sein, diese Formate auf zuverlässige Weise zu
identifizieren und für die Weiterverarbeitung zu kennzeichnen.
Zu diesem Zweck verwendet es MIME-Types. MIME-Types dienen der Bestimmung des Dateiformats
(auch unabhängig von der mitgebrachten Datei-Endung) und der Festlegung dessen, was mit dieser Datei
geschehen soll (z.B. welchem Filter-Programm sie zugeführt werden soll).
MIME steht für Multipurpose Internet Mail Extensions. MIME-Typen sind in einem RFC-Standard
definiert, um Datei-Typen und -Formate zu bezeichnen; MIME-Types für neuentwickelte Datenformate
können bei der IANA (Internet Assigned Numbers Authority) registriert, reserviert und veröffentlicht
werden.
MIMEs wurden ursprünglich geschaffen, um einen Standard zu haben, der es ermöglicht, mittels E-Mail
(die ursprünglich nur für druckbare ASCII-Dateien gedacht war) jegliche anderen (registrierten)
Dateiformate auszutauschen. Zwischenzeitlich spielen sie auch für den reibungslosen Datenverkehr über
HTTP (auf Webseiten surfen, Dateien aller Art laden, speichern oder abspielen) eine entscheidende Rolle.
Beim Versand einer Datei über HTTP wird vom Server jeweils die eindeutige MIME-Type-Bezeichnung
8

mit angegeben. Ein Web-Server, der eine MIME-typisierte Datei vom Server erhält und diese nicht selbst
anzeigen kann, "weiss" dann aufgrund der MIME-Kennung, welches Programm oder Plug-In ihm dabei
behilflich ist (meist konfigurierbar). Obwohl es Plattformen gibt, die Dateiformate nach der Dateinamens-Endung
zuordnen, ist dies nicht in jedem Falle eindeutig. Die Endung .doc z.B. kann Indikator für
eine einfache Textdatei, ein FrameMaker- oder ein MS Word-Dokument sein.
MIME-Types beseitigen durch ihre Registrierung bei IANA jegliche Zweideutigkeit. Sie geben den
beteiligten Programmen (Browser, Web-Server, Mail-Client, Mail-Server...) ein eindeutiges Identifizierungsschema
an die Hand, das Missverständnisse weitgehend ausschliesst.
MIME-Types werden nach folgendem Schema angegeben: Hauptkategorie/Nebenkategorie.
Beispiele für MIME-Types, mit denen CUPS arbeitet, sind text/plain (reine Textdatei), text/html
(HTML-Datei), image/gif (Grafik im GIF-Format), application/pdf (PDF-Datei), application/vnd.cups-raster
(das CUPS-eigene Rasterformat).
CUPS besitzt in der Datei /etc/cups/mime.types eine eigens zuständige Datei, die Regeln definiert, nach
denen unbekannte Formate in die MIME-Types-Kategorien einsortiert werden. Beim Weitergeben an Filter
oder andere IPP-Rechner dienen diese MIME-Types dann der eindeutigen Kennzeichnung des vorhandenen
Formats. Und in /etc/cups/mime.convs existiert eine Konfigurationsdatei, in der festgelegt wird,
welcher Filter für welchen MIME-Type zuständig ist...
Filter -- die Arbeitpferde des ghostscript-RIPs
Die verschiedenen CUPS-Filter ergeben erst in ihrer Gesamtheit die volle RIP-Funktionalität, die es erlaubt,
die vielen Ausgangsformate.(die ja nicht nur aus PostScript alleine bestehen) zu verarbeiten und zu
drucken. Oft lässt sich bereits anhand ihres Namens erahnen, welche Art der Konvertierung sie durchführen.
Auf meinem System (CUPS in der Erweiterung mit ESP PrintPro) sind in /usr/lib/cups/filter/ folgende
vorhanden:
* hpgltops
Umwandlung von der HP-Plottersprache HP-GL/2 nach PostScript
* imagetops
Umwandlung diverser Grafik- und Bildformate in PostScript
* imagetoraster
Umwandlung verschiedener Grafik- und Bildformate in das CUPS-eigene Rasterformat
* pdftops
Umwandlung von PDF (Portable Dokument Format) zu PostScript
* pstops
Umwandlung von PostScript nach PostScript (wird benötigt, um die Seiten eines Jobs zu zählen oder
um z.B. 2-up oder ausgewählte Seiten einer Datei zu drucken)
* pstoraster
Umwandlung von PostScript zu dem CUPS-eigenen Rasterformat
* texttops
Umwandlung von Text in PostScript
* rastertoescp
Umwandlung des CUPS-eigenen Rasterformats nach ESC/P (Epson-Format) [nur bei ESP Print-
Pro]
* rastertoescp2
Umwandlung des CUPS-eigenen Rasterformats nach ESC/P2 (Epson-Format) [nur bei ESP Print-
Pro]
* texttopcl
Umwandlung von Text in PCL [nur bei ESP PrintPro]
* rastertopcl
Umwandlung des CUPS-eigenen Rasterformats nach PCL [nur bei ESP PrintPro]
* rastertoepson
Umwandlung des CUPS-eigenen Rasterformats nach ESC (Epson-Format) [nur bei CUPS]
* rastertohp
Umwandlung des CUPS-eigenen Rasterformats nach PCL [nur bei CUPS]
9

* texttohp
Umwandlung von Text in PCL [nur bei CUPS]
In der Praxis müssen bei jedem Konvertierungs-Job mehrere Filter hintereinandergeschaltet werden, um
aus der Ausgangsdatei die versandfertige, Drucker-spezifische Enddatei zu erzeugen; pstops ist praktisch
immer beteiligt, alleine schon, um die Accounting-Funktionalität zu gewährleisten...
Die Kette hintereinandergeschalteter Filter sieht beim einfachen Druck der CUPS-Testseite (PostScript) auf
einem HP LaserJet wie folgt aus: pstops -> pstoraster -> rastertohp. Beim Druck einer GIF-Grafik
besteht die "Kette" nur aus dem einen Glied imagetops (im Falle eines PostScript-Druckers), und aus imagetoraster
-> rastertohp im Falle eines LaserJets bei Verwendung von CUPS, und aus imagetoraster ->
rastertopcl im Falle eines LaserJets bei Verwendung von ESP PrintPro.
Druckbare Formate:
Viele Dateiformate können von CUPS auf "transparente" Weise gedruckt werden, d.h. ohne dass eine entsprechende Anwendung
geöffnet werden muss. Diese Formate werden über die MIME-Type-Klassifizierung automatisch erkannt und über die
Filter so gewandelt, dass ein druckbares Format für den Zieldrucker herauskommt. Zu den dergestalt unterstützten Formaten
gehören:
Adobe® PDF
Adobe® PostScript® (Level 1 - 3)
ASCII Text
Graphics Interch. Format (GIFSM)
HP-GL
HP-GL/2
Internationaler Text
JPEG/JFIF
Kodak PhotoCD
Portable aNyMap (PNM)
Portable BitMap (PBM)
Portable GrayMap (PGM)
Modularer Aufbau
Durch den modularen Aufbau der Filter-Funktion lassen sich jederzeit weitere Filter in das CUPS-System
integrieren. Drucker- und Softwarehersteller können durch das CUPS-Framework jetzt sehr einfach und
kostengünstig "Treiber" für Linux entwickeln (oder entwickeln lassen): es ist nur ein eigener (oder
angepasster) Filter für den Drucker, eine Drucker-PPD und eventuell entsprechende Einträge in der Datei
/etc/cups/mime.convs nötig.
Die Filter brauchen nicht einmal im Quellcode vorzuliegen, falls der Hersteller meint, wertvolle Betriebsgeheimnisse
wahren zu müssen.
Es gibt nur folgendes zu beachten: ein CUPS-Filter muss außer dem Standard-Verhalten eines UNIX-Filters
(Lesen von stdin, Schreiben nach stdout) noch sechs bzw. sieben weiteren Parametern verarbeiten können:
er muss mit User-Namen, Job-Titel, Job-ID, Drucker-Namen, Anzahl der gewünschten Kopien,
Job-Optionen und dem übergebenen Dateinamen (wenn es der erste Filter in der Kette ist) umzugehen in der
Lage sein (d.h. diese entgegennehmen und weitergeben).
Dezidierte Druckserver
Wer CUPS als dezidierten Druckserver betreiben will, der eine Anzahl von Clients bedient, sollte sein
System dem Druckaufkommen entsprechend auslegen. Das Verarbeiten von PostScript durch das
ghostscript-Software-RIP benötigt unter Umständen (je nach Zieldrucker) eine Menge Ressourcen:
CPU-Zeit, RAM, Plattenplatz. Die Rasterdaten für eine A3-Farbseite auf einem
6-Farb-Tintenstrahl-Drucker können leicht 60 MB übersteigen. Da bei CUPS der Server diese Aufgabe für
die Clients erbringt (und den Administrator von der Konfiguration der Clients entlastet), sollte er auf keinen
Fall zu schwach für das projektierte Druckaufkommen ausgelegt sein, um unnötige Wartezeiten zu vermeiden.
Bei Einsatz von PostScript-Druckern entfällt allerdings der größte Teil der rechenintensiven
RIP-Vorgänge: hier genügt unter Umständen ein ausrangierter 486 mit ausreichend Plattenplatz zum
Spoolen und Zwischenlagern der Aufträge.
Wichtige Hinweise bei Erst-Installation
10
Portable Network Graphics (PNG)
Portable PixMap (PPM)
SGI® RGB
Sun® Raster
Tagged Image File Format (TIFF)
Windows® Bitmap (BMP)

Wer CUPS auf einem System installieren will, für das es noch keine fertig geschnürten Packete der betreffenden
Linux-Distribution gibt, verwendet am besten das "portable" .tar.gz-Format der
CUPS-Entwickler (Es werden auch RedHat-.rpm- und Debian-.deb-Packete angeboten). Zuvor sollten die
bestehenden Druck-Packete de-installiert werden. (Bei SuSE z.B. "lprold" oder "lprng"). Nach dem Auspacken
des Packetes mit "tar -xvzf cups-1.1.6.tar.gz" steht im lokalen Verzeichnis u.a. das Installations-Skript
zur Verfügung. Es wird dort von root mit dem Befehl "./cups.install" ausgeführt.
Achtung: es ersetzt bestehende Dateien und Befehle wie printcap, lp, lpr, lpq, lpc, lpadmin durch eigene
Versionen, sichert die bestehenden jedoch zuvor unter der Endung .O (Sollte man CUPS wieder loswerden
wollen, stellt das De-Installations-Skript "cups.remove" den Ursprungszustand wieder her).
Wichtige Hinweise für das Upgraden
Wer immer auf dem aktuellsten Stand sein will, wird sich eventuell die als .tar.gz.-tarball vorliegenden
Binärdateien vom CUPS-Server holen. Die Installation mit dem mitgelieferten cups.install-Shellscript ist
dann ein Kinderspiel. Es lässt alle vorhandenen Konfigurations-Dateien "in Ruhe" und überschreibt diese
nicht: Die mitgelieferte neue Konfigurationsdatei wird unter dem Namen cupsd.conf.N neben die "aktive"
geschrieben.
Achtung: Dies bedeutet, dass man zwar weiterhin ein laufendes System hat, jedoch *nicht* in den Genuss
neuer Features kommt, ohne in die cupsd.conf.N zu schauen und neu vorhandene Direktiven eventuell
händisch in die aktive cupsd.conf zu übertragen und auf die eigenen Verhältnisse anzupassen... CUPS wird
ziemlich zügig weiterentwickelt und in fast jeder neuen Release finden sich zusätzliche Konfigurations-Optionen.
Drei verschiedene Benutzer-Schnittstellen
CUPS verfügt über zwei verschiedene "eingebaute" Benutzerschnittstellen: die Kommandozeile und das
per Browser zugängliche Web-Interface.
Darüber hinaus gibt es noch optionale grafische Benutzeroberflächen, die von Dritten beigesteuert wurden
und sich nachträglich als CUPS-Bedien-Frontends installieren lassen: XPP (X Print Panel) von Till
Kamppeter, QtCUPS und KUPS (von Jean-EricCuendet und Michael Goffioul) und GTKlp (von Tobias
Müller). Wählt man diese Tools innerhalb der Programme, die drucken sollen, als "Druck-Kommando",
dann poppt bei jedem Druckauftrag zuerst ein Fenster auf, das den Anwender Drucker und Job-Optionen
auswählen lässt.
Die kommerzielle CUPS-Version, ESP PrintPro beinhaltet zusätzlich zu den 2.300 Druckertreibern und
einigen ghostscript-Verbesserungen (beruhend auf per NDA, Non Disclosure Agreements, lizenzierten
Herstellerinformationen) ebenfalls ein Graphical User Interface (GUI).
Verschiedene CUPS-Ressourcen und -Locations
Wie ein "normaler" Web-Server herrscht auch der CUPS-Daemon über verschiedene (reale und virtuelle)
Ressourcen (auch locations genannt), die von den Clients mittels URI addressiert werden. Dazu gehören:
/admin/,
/printers/,
/printers/druckername,
/printers/druckername.ppd,
/jobs/,
/classes/,
/classes/klassenname
Locations können per Browser "betreten" werden, wenn man den URI-Pfad zum Webserver-Wurzelverzeichnis
um die Bezeichnung der Location ,,verlängert". Beispiel: Die Location /classes/all_laserjets
auf dem CUPS-Server transmeta.danka.de wird über die URL
http://transmeta.danka.de:631/classes/all_laserjets erreicht.
Differenzierte Rechte
11

Allerdings ist nicht jede Location gleichermaßen zugänglich. Die Zutritts-Berechtigung zur Location wird
je nach Konfiguration überprüft und u.U. verwehrt. Der IPP-Server CUPS gestattet -- wie jeder
HTTP-Server -- dem Administrator, die Berechtigungen für die verschiedenen Locations unterschiedlich zu
setzen. Dazu dienen die "AuthType"-Direktiven: "AuthType None" verzichtet völlig auf eine Authentifizierung,
"AuthType Basic" verwendet die HTTP-Basic-Methode und "AuthType Digest" nimmt die
HTTP-Digest-Methode.
Darüber hinaus kann der Zutritt je nach Herkunft des Nutzers gewährt oder verweigert werden. Die aus der
Apache-Konfiguration bekannten Direktiven "AllowFrom..." und "DenyFrom..." samt der Auswertungs-Reihenfolge
"Order Allow,Deny" bzw. "Order Deny,Allow" sind hierfür ausschlaggebend. Als
Variablen können bei diesen Direktiven All, None, Host-Name, IP-Adresse, Domain-Name samt
entsprechenden *-Platzhaltern auftreten.
Alle diese Vorgaben sind durch Editieren der gut kommentierten /etc/cups/cupsd.conf einzustellen.
Nach einer Neuinstallation ist die Location /admin/ erst mal nur für root zugänglich, jedoch nicht remote,
sondern nur vom localhost aus (und auch nur dann, wenn der root-Account kein leeres Passwort hat).
Achtung: man sollte nicht der Selbsttäuschung anheimfallen, dass diese Rechtefestlegung nur für das
Web-Interface gilt. Auch bei Nutzung der Kommandozeile oder einer GUI greift man zwangsläufig auf
locations des CUPS-Servers zu und kommt dadurch mit den gesetzten Rechten in Berührung.
Verschlüsselung über SSL3/TLS
Eines der neueren Merkmale von CUPS ist seine Unterstützung des Verschlüsselungs-Standards TLS
(Transport Layer Security), der inzwischen den IETF-Status "proposed standard" erreicht hat. TLS ist von
Netscapes SSL3 (Secure Socket Layer Version 3) abgeleitet und verwirklicht eine asymetrische Verschlüsselung
von Daten. CUPS stützt sich für die Kernfunktionen auf diesem Gebiet auf die Entwicklungen
des OpenSSL-Projekts, dessen libraries es für seine Funktionen nutzt. Die CUPS-Entwickler bezeichnen
die TLS-Unterstützung zwar noch als "experimentell" -- wenn das Entwicklungstempo jedoch in dem seitherigen
Tempo weitergeht, ist demnächst mit wirklicher "Produktreife" dieses Features zu rechnen.
Übergabe von Job-Optionen auf der Kommandozeile
Wer die Optionen seines Druckers von der Kommandozeile aus nutzen will, muss zuerst herausfinden: wie
hat der Hersteller diese überhaupt in die PPD hineincodiert?
Ein gutes Werkzeug für diesen Zweck ist der Befehl "lpoptions". In der Form "lpoptions -h transmeta
-p Hitachi_DDP70_ClusterPrintingSystem -l" wird die PPD des Druckers Hitachi_DDP70_ClusterPrintingSystem
auf dem CUPS-Host transmeta zu allen verfügbaren (-l für "langes Ausgabeformat")
Optionen befragt. Die Ausgabe dieses Beispiels ist zu lang, um hier wiedergegeben zu werden. Deshalb will
ich danach suchen, wie diesem Drucker per PPD mitgeteilt wird, dass er doppelseitig (Duplex oder duplex?)
drucken soll: "lpoptions -h transmeta -p Hitachi_DDP70_ClusterPrintingSystem -l | grep
uplex" liefert die Ausgabe: "TR-Duplex/Duplex: False *True". -- Hieraus ist zu ersehen:
der Name der gesuchten Option ist "TR-Duplex";
hinter dem Schrägstrich steht die Übersetzung der Option, wie sie vom Web-Interface oder einer GUI
übernommen werden sollte ("Duplex");
die Option kann die beiden Werte "False" und "True" annehmen;
der gegenwärtig eingestellte Wert ist "True" (erkennbar an der Markierung mit dem Stern *).
Soll jetzt ausnahmesweise doch einseitig gedruckt werden, muss man folgendes Kommando verwenden:
"lpr -P Hitachi_DDP70_ClusterPrintingSystem -o TR-Duplex=False /Pfad/zu/Druckjob".
Accounting
Prinzipiell führt der CUPS-Server über jede verarbeitete Seite Buch. In der Datei /var/log/cups/page_log
ist für jede Seite ein Eintrag der Form: "Druckername Benutzer Job-Nr [Datum+Uhrzeit] Seiten-Nummer
Auflage" enthalten. Diese Datei lässt sich dann für Buchhaltungszwecke beliebig auswerten. Von Thies
Moeller stammt das Perl-Skript PrintAnalyzer, welches aus dem page_log einige Statistiken extrahiert,
12

die Aufschluss über die Anzahl der Druckaufträge (pro Drucker und gesamt), die Nutzer und ihr Druckaufkommen,
die zeitliche Verteilung der Drucke und vieles mehr geben.
Anmerkung: Die Seitenanzahl eines Jobs wird bei Durchlauf des Filters pstops ermittelt. Hierfür muss die
Anwendung ein sogenanntes DSC-konformes PostScript (DSC = Document Structuring Conventions)
generieren, was in der Regel der Fall ist. Fast alle Jobs passieren zwar durch diesen wichtigen Filter; die
anderen jedoch, die an diesem Filter vorbeilaufen (also z.B. Samba-Druckjobs, die von Windows-Clients
stammen, welche Original-Windows-Treiber verwenden und deshalb auf dem CUPS-Server die Option
"-o raw" verwenden müssen, da der Druckjob auf Windows bereits im druckbaren Format erzeugt wird
und keine Filterung auf Linux-Seite mehr verträgt), werden nur mit der Seitenzahl 1 gezählt.
Weitere Information über wichtige Kommandos
Wer sich über die wichtigsten CUPS-Kommandos informieren will, sollte einfach mal mit
"lp-[Tab]-[Tab]" alle mit "lp" beginnenden Kommandos (sowohl als User, wie auch als root -- denn für
die beiden decken sich die erlaubten Befehle nicht) ausfindig machen. Die meisten werden zu CUPS
gehören. Die zugehörigen man-Pages sollten als erstes Lesematerial dienen; sie verweisen dann auch auf
zusätzliche Befehle (wie cancel und enable), die nicht mit "lp" beginnen.
Bei laufendem CUPS-Daemon ist außerdem über http://localhost:631/documentation.html die
komplette aktuelle CUPS-Dokumentation in HTML- und PDF-Format im Zugriff (von einem entfernten
Client aus muss man eventuell die URL http://CUPS-Server:631/documentation.html verwenden.
Sollte der CUPS-Daemon ausnahmsweise Probleme machen, finden sich die Dateien in der Regel unter
/usr/share/doc/cups/ im lokalen Datei-System.
Hersteller unterstützter Druckermodelle bei ESP PrintPro (kommerzielle CUPS-Erweiterung)
Hier eine Liste der Hersteller derzeit unterstützter Druckermodelle. Diese Liste wird ständig erweitert.
Insgesamt werden mit der Software derzeit über 2.300 Druckermodelle unterstützt, davon mehr als 1.000
Nicht-PostScript-Modelle (zumeist Tischgeräte der einen oder anderen Art):
3M
5500
A.B.Dick
Accel
Acolor_SM
Adobe
Agfa
ALPS
Apple
APS
AST
Autologic
Birmy
CalComp
Canon
CCL
CCP
ColorLink
Colormate
ColorScript
COLOSSAL
COMPAQ
CompuPrint
Crosfield
Cyclone
Danka
Dataproducts
Digital
Dolev
EFI
ENCAD
EPSON
Fargo
FIRST
FP Fuji
Fujitsu
FX
COMPAQ
DDP
DDS
GCC
GDT
Gestetner
Heidelberg
Hitachi
HP
IBM
IDT
Indigo
infotec
IRIS
IS
Jet
JVC
Kanji
Kodak
LaserPress
LBP
Lexmark
LHAG
Linotronic
Linotype
MajestiK
Management
Mitsubishi
MJ
Monotype
Mutoh
NEC
NeXT
NWS
OceColor
OKI
Okidata
Panasonic
Panther
PantherPlus
PantherPro
Pictura
PlateMaker
PostArt
PostArtPro
PrePress
ProofPositive
QMS
Quasar
QuasarJ
Qume
Ricoh
Samsung
SC7000 J
Scantext
Schlumberger
Scitex
Seiko
Shinko
Sony
SPARCprinter
Splash
StyleScript
Tally
Tektronix
TI
Typhoon
UNISYS
Varityper
Xante
Xerox
& versch. andere
Tipps und Tricks
Der erfahrene CUPS-Anwender kann sehr schnell eine Menge Tipps und Tricks ausfindig machen, die es
ihm erlauben, sein System voll und ganz auszureizen. Zum Beispiel sind über die Kommandozeile eine
grosse Anzahl von IPP-Funktionalitäten möglich, die noch keine Entsprechung in einer der GUIs oder im
Web-Interface haben. Experimentierfreudige Linuxer sollten sich das RFC 2910 besorgen, worin die
13

Spezifikationen des IPP 1.1 festgelegt sind. Darin finden sich viele Funktionen, die auf der
CUPS-Kommandozeile funktionieren, jedoch in die "offizielle" CUPS-Dokumentation noch nicht Eingang
gefunden haben.
Eines der von mir ausfindig gemachten Beispiele: das Kommando "lpr -P HeidelbergDigimaster -o
job-hold-until=indefinite /usr/share/doc/sam.pdf" schickt das CUPS-Software Administrator
Manual zur Verarbeitung durch den Drucker HeidelbergDigimaster9110 -- jedoch wird der Job nicht sofort
gedruckt, sondern für unbestimmte Zeit auf "Halde" gelegt. (Er kann dann jederzeit manuell freigegeben
oder gleich gelöscht werden). "job-hold-until" gehört zu den in IPP 1.1 festgelegten "Job Template Attributes";
es akzeptiert als gültige Werte "indefinite", "day-time", "evening", "night", "weekend", "second-shift"
und "third-shift" oder eine Zeitangabe in der Form "HH:MM".
Mehr zu dem Thema "Tipps + Tricks" muss aus Platzmangel dem in Arbeit befindlichen "CUPS Printing
HOWTO" vorbehalten bleiben.
Ausblick
Der Leiter der CUPS-Entwicklung, Michael Sweet, hat eng mit dem Samba-Team zusammengearbeitet, um
eine möglichst nahtlose Zusammenarbeit von CUPS mit der Windows-Welt zu erreichen. Die ersten
Früchte dieser Kooperation kann man bereits ernten, seit die neueste Samba-Release 2.2 freigegeben ist.
Durch die verwirklichte "Point&Print"-Technologie ist es Windows-Anwendern möglich, die PPD für den
Zieldrucker durch einfachen Doppelklick zu installieren (vom CUPS-Server als Downloadquelle). [Anmerkung
und Ergänzung: natürlich kann man auch den originalen Windows-Treiber auf dem CUPS-Server
hinterlegen und den Clients übergeben].
Auf der Windows-Seite wird so in jedem Falle ein mit dieser PPD gespickter einfacher PostScript-Treiber
zum Einsatz kommen -- selbst wenn der Zieldrucker ein Nicht-PostScript-Gerät ist! Der CUPS-Server
empfängt PostScript plus gerätespezifische Job-Optionen aus der PPD und konvertiert dieses mittels seiner
Filter in das Rasterformat des Zieldruckers. Administratoren von großen Installationen unter Windows
Terminal Servern (WTS) können sich dann auf höhere Stabilität ihrer Server freuen: denn der vielfältige
Treiber-Wirrwarr, der auf den Servern bisher herrscht (wenn man sich in der betroffenen WTS-Umgebung
nicht gerade auf ein bestimmtes Druckermodell für die Clients in -zig-dutzendfacher Auflage geeinigt
hatte), ist dann zu Ende. Es brauchen keine PCL- und andere Treiber mehr eingesetzt werden, die z.T. für
ihre negativen Auswirkungen auf die Server-Uptime notorisch sind. [Mancherorts wird die Hälfte aller
"Bluescreens" (die dann sofort mehrere Dutzend Client-Rechner für eine Viertelstunde lahm legen) auf die
Anwesenheit zertifizierter (!) HP-PCL-Treiber zurückgeführt...]. Der eine PostScript-Treiber genügt für
alle Drucker (die unterschiedlichen PPDs haben keine negativen Auswirkungen auf den Server).
Fazit
CUPS macht das Drucken nicht nur für den Anfänger oder Heimanwender einfacher. CUPS ist auch fürden
gestressten Administrator im Enterprise eine echte Erleichterung. Dabei sind dem Tausendsassa CUPS
heterogene Netzwelten seit Anfang bekannt. Und gerade hier kann CUPS dem weiteren Vormarsch von
Linux im Enterprise und auf den Desktops mehr als behilflich sein: denn das schönste KDE nützt samt
K-Office nichts, wenn Drucken unter Linux das Ge-Murkse bleibt, das es oftmals noch ist...
Der Autor:
Kurt Pfeifle arbeitet in Stuttgart als System-Spezialist für die Danka Deutschland GmbH, einem der größten herstellerunabhängigen
Anbieter im Vertrieb und Service von Systemlösungen für den Digitaldruck, bestehend aus integrierten Hard- und
Software-Komponenten. Er ist unter kpfeifle.at.danka.de zu erreichen.
Links:
http://www.danka.de/printpro/faq.html
CUPS-FAQ von Kurt Pfeifle, insgesamt 150 Fragen (und derzeit etwas weniger Antworten ;-)
http://www.pwg.org/ipp/
14

Informationen über das Internet Printing Protocol aus erster Hand
http://www.cups.org/software.html
CUPS downloaden
http://www.cups.org/documentation.html
Informationen über CUPS aus erster Hand
http://www.easysw.com/software.html
ESP PrintPro downloaden
http://www.easysw.com/documentation.html
Informationen über ESP PrintPro aus erster Hand
http://www.linuxprinting.org/
Grant Taylors Linux Printing HOWTO, CUPS-O-Matic und PDQ-O-Matic u.v.m.
http://www.pwg.org/ipp/IPP-Products.html
Liste IPP-fähiger Produkte bei der Printer Working Group
Anmerkung: dieses Paper ist eine erweiterte und überarbeitete Fassung eines für "LinuxEnterprise" im Fühjahr geschriebenen,
jedoch erst in Ausgabe 07/2000 erscheinenden Artikels.
15
Kurt Pfeifle