Ein CUPS (Common Unix Printing System) verbirgt seine komplexe Architektur so geschickt vor seinen Clients, dass die Installation eines Druckers mit dem KDE- oder CUPS-Assistenten kaum von der an einem Windows-Rechner zu unterscheiden ist.

CUPS als IPP-basiertes (Internet Printing Protocol,[1]) Server-Drucksystem für Linux-Clients bringt Vorteile: Zum einen unterstützt CUPS [2] neben allen Postscript-(Laser-)Druckern viele Tintenstahler, zum anderen ermöglicht der zentraler CUPS-Server eine Benutzerauthentifizierung, das Verschlüsseln von Druckdaten sowie das Beliefern der Clients mit Druckerspezifika. Zudem ist es in der Lage, die Druckertreiber zentral an die Clients zu verteilen.

Der folgende Beitrag demonstriert dem Systemadministrator eine effiziente CUPS-Konfiguration für ein typisches Büroszenario, das beispielsweise einen Postscript-Laser als Abteilungsdrucker sowie einen Tintenstrahler für den Präsentationsdruck ausmacht.

CUPS-Basics

In der CUPS-Begriffswelt ist jeder Host, der lokal einen Drucker nebst zugehörigem Treiber installiert hat und unmittelbar mit einem Ausgabegerät kommuniziert, ein Server. Die Funktion eines Druckertreibers bei Linux/CUPS umfasst die gesamte Aufbereitung der Druckjobs mit Filtern. Dazu verwaltet CUPS pro Gerät eine PPD-Beschreibungsdatei, die alle Gerätespezifika und deren Ansteuerung enthält, sowie ein Backend, das die Jobs über ein Protokoll versendet.

Rechner, die die Dienste eines CUPS-Servers über ein nicht-lokales Backend in Anspruch nehmen, sind Clients. Die Architektur von CUPS ähnelt der von Webservern, genauer: einem HTTP-Server mit IPP-Erweiterungen auf Port 631. Die Konfigurationsdatei »/etc/cups/cupsd.conf« ahmt auch die Apache-Konfigurationsdatei nach, denn das Internet Printing Protocol fußt auf HTTP 1.1 [1]. Basiswissen über den Kdeprint-Assistenten, das CUPS-Webinterface und die Architektur vermitteln[3],[4] und[5].

Server richtig dimensioniert

Sind viele Clients mit Druckdiensten zu versorgen, muss das CUPS-System der Last entsprechend ausgelegt sein. Der Server braucht zusätzlich Ressourcen, wenn er die Druckdaten der Clients aufbereiten soll und Treiber und Filter verwaltet muss. Mit Linux-Clients ist das der Normalfall. Im homogenen CUPS-Betrieb braucht der Admin kaum Installationsschritte an den Clients vorzunehmen. Anders ist das, wenn Windows-Clients ins Spiel kommen: Dann arbeitet CUPS eng mit Samba zusammen und ermöglicht es den Clients, ihre Druckertreiber vom Server zu installieren, was aber die Administration komplexer gestaltet und Ressourcen auf dem CUPS-Server bindet.[6]

Im Szenario für diesen Artikel stellt ein Abteilungs-Laserdrucker (im Folgenden ein Minolta-QMS) als echter Postscript-Drucker keine zusätzliche Anforderung, da die Raster-Engine des Geräts die Aufbereitung der Druckdaten selbst bewerkstelligt. Der CUPS-Server benötigt lediglich ausreichend Festplattenplatz zum Spoolen. Bei Nicht-Postscript-Druckern - so beim Farb-Tintenstrahler - übernehmen CUPS und Ghostscript die Aufbereitung der eingehenden Daten.

Der Ghostscript-RIP beansprucht unter Umständen einiges an Prozessorzeit, Arbeitsspeicher und Plattenplatz. Die Rasterdaten einer A3-Farbseite von Sechs-Farben-Tintenstrahldruckern erreichen mühelos 50 MByte. Da der CUPS-Server diese Leistung für alle Clients erbringen muss, sollte er großzügig dimensioniert sein. In größeren Umgebungen lassen sich CUPS-Server clustern und bieten so ein Load-Sharing oder Failover.

Ein CUPS (Common Unix Printing System) verbirgt seine komplexe Architektur so geschickt vor seinen Clients, dass die Installation eines Druckers mit dem KDE- oder CUPS-Assistenten kaum von der an einem Windows-Rechner zu unterscheiden ist.