Das grafische Frontend Xpp lehnt sich sehr stark an die ESP PrintPro-Software des CUPS-Erfinders Michael Sweet an.

CUPS ist das Drucksystem des Internet-Zeitalters. Unser Überblick zeigt, was damit derzeit möglich ist, und was hinter den Kulissen abläuft.

Treue Leser des Linux-Magazins kennen das Common Unix Printing System (CUPS) bereits seit unserer Artikelreihe im Jahr 2000 [1]. Inzwischen sind jedoch die Entwicklung und die Akzeptanz von CUPS mit Riesenschritten vorangekommen. Es wird Zeit für eine Auffrischung und ein Update auf den neuesten Stand.

CUPS [2] implementiert das Internet Printing Protocol (IPP) [3] in Version 1.1. Es kann sowohl lokal als auch im Netzwerk den in die Jahre gekommenen Line Printer Daemon vollständig ablösen. Einige Linux-Distributionen wie Mandrake, Caldera, EasyLinux oder Connectiva installieren den LPD schon gar nicht mehr. Auch in aktuellen SuSE-Varianten kann CUPS inzwischen mit YaST konfiguriert werden.

Auf Einzelplatz-Systemen reizt CUPS alle individuellen Eigenschaften des vorhandenen Druckers aus, seine wahren Stärken kommen jedoch erst im Netzwerk zum Tragen. Dort kann auf jedem freigegebenen Drucker unter Nutzung all seiner gerätetypischen Optionen gedruckt werden, ohne dass auf dem Client ein Treiber installiert ist. Mehr noch, der Client erkennt selbständig, welche Drucker im Netz installiert sind, sofern diese an einem CUPS-Server hängen.

Architektur wie ein Webserver

Herzstück von CUPS ist der Server-Daemon oder Scheduler cupsd, der viel mit einem herkömmlichen Webserver gemein hat. Er kann mit jedem Browser über den reservierten Port 631 angesprochen werden. Über diesen Port kommunizieren auch die Clients mit dem Server. Der Datenaustausch mit den am Server angeschlossenen Druckern jedoch kann auf vielerlei Wegen geschehen. Idealerweise verstehen diese selbst IPP, das ist jedoch erst bei etwa 200 Modellen der Fall. Gute Laserdrucker wie die in unserem Test werden wahrscheinlich eher das Appsocket-Protokoll beherrschen, freigegebene Drucker an Windows-Rechnern können mit Samba über SMB angesprochen werden. Für den “Rest” kommt LPD zum Einsatz. Die Kommunikation mit den Druckern über die genannten Protokolle erledigen Backends, die separat konfiguriert werden.

CUPS und Postscript

Wer auf Unix-Systemen druckt, kommt an Postscript nicht vorbei; CUPS ist da keine Ausnahme. Am einfachsten sind deshalb Postscript-fähige Drucker zu handhaben. Deren eingebaute Prozessoren verarbeiten im sehr rechenintensiven Raster Image Process (RIP) PS-Dateien zu Rasterdaten. Für Drucker, die kein Postscript verstehen, muss das ein Rechner erledigen.

In der Druckvorstufe stehen oft dedizierte RIP-Server. Im Firmennetz übernimmt der Printserver diese Aufgaben mit und sollte deshalb über ausreichend Rechenleistung verfügen, falls wirklich regelmäßig mit nicht postscriptfähigen Druckern gearbeitet wird. CUPS ist jedoch flexibel genug, um unter Umständen auch das Aufbereiten der Druckdaten auf dem Client zu erlauben. Dann ist jedoch ein wesentlicher Vorteil dahin; der Client braucht hierfür selbstverständlich eigene Treiber. Die Eigenschaften jedes Druckermodells sind in einer Postscript Printer Description (PPD) im ASCII-Format festgelegt

Drucken ohne Postscript-Geräte

Jede CUPS-Installation besitzt eigene Filter, die auf der älteren Ghostscript-Version 5.5 beruhen, gegenüber dieser jedoch modifiziert und verbessert sind. Einige Filter sind nach der Standardinstallation bereits vorhanden: für PCL-fähige Tintenstrahl- und Laserdrucker der Deskjet und Laserjet-Familien von Hewlett-Packard, Epson Stylus Color und Stylus Photo sowie 9- und 24-Nadeldrucker von Epson. Diese liegen üblicherweise zusammen mit den von Ghostscript abgeleiteten Filtern im Verzeichnis /usr/lib/cups/filter.

Für andere nicht postscriptfähige Drucker gibt es Cups-O-Matic. Das ist eine auf CUPS angepasste Version der Foomatic-Skriptsammlung des Linux-Printing-HOWTO-Autoren Grant Taylor [4]. Es erschließt alle “naturbelassenen” Ghostscript-Filter für die Verwendung mit dem CUPS-System und setzt damit ein installiertes Ghostscript auf dem Druckserver voraus. Auf der Cups-O-Matic-Website erzeugt man sich zunächst eine PPD für den vorhandenen Drucker in Kombination mit einen Ghostscript-Filter. Aus der Sicht des Nutzers ist diese bereits der “Druckertreiber” und kann mit den üblichen Mitteln (Kommandozeile, GUI oder Browser) im CUPS-System installiert werden. Intern läuft es jedoch etwas komplizierter ab. Benötigt wird auf jeden Fall cupsomatic, ein Perlskript, das im Filterverzeichnis /usr/lib/cups/filter liegen muss. Mit Hilfe dieses Skripts werden die druckerspezifischen Daten aus der PPD an den zuständigen Ghostscript-Filter des Systems übergeben, der die Druckdaten entsprechend aufbereitet.

CUPS und Ghostscript Hand in Hand

Cupsomatic “entführt” die Druckdaten sozusagen für eine kurze Zeit aus der üblichen CUPS-Umgebung, leitet sie dem in der Cups-O-Matic-PPD spezifizierten Ghostscript-Filter zu (der an seiner üblichen Stelle installiert bleiben kann) und gibt das Ergebnis an CUPS zurück. Mit Cups-O-Matic druckt CUPS also in gleich guter (oder schlechter) Qualität wie alle anderen Ghostscript-Systeme, aber es stehen alle Netzwerk-Features von CUPS für die von Ghostscript unterstützten Drucker zur Verfügung.

Außer Cups-O-Matic gibt es noch andere Möglichkeiten, Filter in CUPS einzubinden, nämlich für Turboprint (siehe Artikel Seite 52) und Gimp-Print (siehe Kasten).

Druckerklassen für “Großdruckereien”

Wenn in einem Netzwerk mehrere Drucker des gleichen Typs vorhanden sind, oder auch bestimmte Drucker nur zeitweilig zur Verfügung stehen, kann man diese in Klassen zusammenfassen. Wird ein Druckauftrag an eine Klasse geschickt, geht dieser an das nächste freie Gerät. Damit kann bei hohem Druckaufkommen oder bei wichtigen Druckjobs Load Balancing und Failover erreicht werden.

CUPS konfigurieren

Das grafische Frontend Xpp lehnt sich sehr stark an die ESP PrintPro-Software des CUPS-Erfinders Michael Sweet an.

Das CUPS-Drucksystem lässt sich über diverse Kommandozeilen-Befehlen überwachen und administrieren. Die wichtigsten sind lpadmin, lpoptions und lpstat. Mit lpstat -p -d werden beispielsweise die verfügbaren Drucker angezeigt. lpadmin konfiguriert Drucker, Druckerklassen und Benutzerrechte. Anzumerken ist, dass CUPS bei entsprechender Konfiguration einen eigenen Administrator kennt, also keine Root-Rechte benötigt. Mit lpoptions können die gesamten über die PPD konfigurierbaren Druckereigenschaften angezeigt und geändert werden. Das ist jedoch sehr mühsam, da sie sich naturgemäß von Modell zu Modell unterscheiden. Deshalb sind hier grafische Tools wie xpp, gtklp,kups, oder das Web-Interface über http://[rechnername]:631 ausgesprochen nützlich. Diese lesen die jeweilige PPD aus und machen sie per Mausklick konfigurierbar.

In KDE 2.2 wird die CUPS-Konfiguration dank KDEPrint nahtlos in die Systemsteuerung integriert.

In KDE 2.2 wird mit KDEPrint eine Vermittlungsschicht zwischen KDE-Applikationen und verschiedenen Printing-Subsystemen Einzug halten. Damit kann CUPS in KDE-Applikationen einfacher und vollständiger administriert werden. Das bisherige Konfigurationstool kups wird nicht mehr weiterentwickelt.

Allgemeine Einstellungen für das CUPS-Drucksystem sind in /etc/cups/cupsd.conf zu finden. Hier zeigt sich wieder die Nähe zu Apache. Diese Konfigurationsdatei ist genau wie httpd.conf aus Direktiven aufgebaut. In cupsd.conf kann man über die Browsing On Drucker automatisch im gesamten Netz bekannt machen, Browse-Relais für Netzwerk-übergreifendes Drucken bestimmen, Optionen zur Authentifizierung und Verschlüsselung festlegen und vieles mehr. Um das Studium der Handbücher [6] kommt der Administrator mit hohen Ansprüchen höchstens bei guten Apache-Kenntnissen herum. Zum Glück ist CUPS aber mit den Default-Einstellungen nach der Installation schon weitgehend einsatzfähig. n