LinuxTag 2000 Konferenz-CD-ROM

 

Drucken leicht gemacht: Drucken leicht gemacht: mit Internet Printing Protocol (IPP) und dem »Common Unix Printing System« (CUPS)
von Kurt Pfeifle (kpfeifle@danka.de)

Vorbemerkung

Der Autor dieses Papiers ist ein Linux-Anfänger. Er hat beruflich viel mit Druckern zu tun. Da Linux seit neuestem zu seinen Hobbys gehört, hat er sich deshalb natürlich auch (hauptsächlich in seiner Freizeit) mit Drucksoftware für sein Lieblings-Betriebssystem beschäftigt. Derzeit versucht er seinen Arbeitgeber, die Danka Deutschland GmbH (einer der grössten Hersteller-unabhängigen Anbieter für Digitalsysteme zum Kopieren, Drucken, Faxen und Scannen) davon zu überzeugen, ESP PrintPro ins Produkt-Portfolio aufzunehmen.

Der Autor kann keinerlei Gewährleistung für die Richtigkeit all seiner Ausführungen übernehmen. Dieses Papier wurde für den »Linuxtag 2000« geschrieben. Die Veranstalter des Linuxtag 2000 erhalten alle Rechte an diesem Papier übertragen, solange seine ursprüngliche Urheberschaft erwähnt und es im Sinne der »Open Source«-Bewegung verwendet wird.

Des Autor wünscht sich vom KDE-Projekt die baldige Fertigstellung von »KUPS«, einem grafischen Frontend für das hier beschriebene CUPS. Vielleicht kann dieses Papier einen Beitrag leisten, indem es CUPS bekannter macht und die Grundlage für ein »CUPS+Linux-HOWTO« bildet.

Dieses Papier wendet sich an

  • sowohl Linux- und PC-Einsteiger, die ausser über CUPS zusätzlich etwas über die Hintergründe des Druckvorgangs erfahren wollen,
  • als auch erfahrene Administratoren und Entwickler, für die CUPS und IPP noch Neuland sind.

Lese jeder die Teile, die am meisten interessieren.

Des Autor wünscht sich vom KDE-Projekt die baldige Fertigstellung von »KUPS«, einem grafischen Frontend für das hier beschriebene CUPS. Vielleicht kann dieses Papier einen Beitrag leisten, indem es CUPS bekannter macht und die Grundlage für ein »CUPS+Linux-HOWTO« bildet.


Linux hat MS-Windows bereits in vielen Bereichen hinter sich gelassen. Projekte wie KDE und GNOME entwickeln sich geradezu rasant weiter. In punkto Anwenderfreundlichkeit beim Thema »Drucken vom Desktop aus« allerdings hinkt Linux trotz aller KDE-Fortschritte den Microsoft-Betriebssystemen unstreitig noch meilenweit hinterher.

Linux wird erst dann den Desktop - vor allem in der Geschäftswelt - erobern können, wenn das Drucken für die Anwender mindestens so einfach wird, wie sie es von ihrem bisher benutzten Betriebssystem gewohnt sind.

Die Neuentwicklung »Common Unix Printing System« (CUPS) könnte Linux in diesem Bereich einen grossen Schritt weiter bringen.
 

        Vorbemerkung
1. Einführung: Wie die Druckprotokolle sich entwickelten
    1.1 Von der Erblast aus den 70er Jahren (LPR/LPD)...
    1.2 ...über viele clever umschiffte Untiefen...
    1.3 ...und Ankerplätze...
    1.4 ...zu neuen Ufern: Internet Printing Protocol (IPP)
    1.5 IPP: im »Standards Track« mit Status »experimentell«
    1.6 Vorgeschichte der Neuentwickung
    1.7 Heutige Praxis: viele herstellerspezifische Erweiterungen 
    1.8 Die »Printer Working Group« und die IETF
2. Das IPP als kommender Standard
    2.1 Design-Ziele des IPP
                Abb. 1: Ein IPP-Client kann einem IPP-Server die URI eines zu druckenden
Dokumentes übergeben. Der Server holt dieses selbständig per FTP
oder HTTP 1.1 ab und druckt es aus.
    2.2 IPP-Umsetzung als HTTP-Erweiterung
    2.3 HTTP überträgt alles, nicht nur HTML!
    2.4 HTTP ist auch für die »Gegenrichtung« nutzbar
    2.5 Adressierung über URIs
    2.6 Portnummer 80 für HTTP
    2.7 Portnummern für andere Dienste
    2.8 LDAP-Dienst für netzweite Informationen
    2.9 IPP wird LDAP-Anbindung haben
    2.10 IPP: revolutionär neu, und doch altbewährt!
    2.11 Die URIs des IPP
    2.12 Drucken wie Browsen
3. Grundsätzliches zum Thema Drucken
    3.1 Wie kommt die Datei von der Festplatte auf das Papier? 
        3.1.1 Dateien sind verschieden
        3.1.2 Drucker sind verschieden 
        3.1.3 Für jede mögliche Umwandlung ein Programm? 
        3.1.4 Die Theorie: eine Seitenbeschreibungssprache 
        3.1.5 Die Praxis: mehrere Seitenbeschreibungssprachen
        3.1.6 PostScript als PDL
        3.1.7 Vektoren zu Pixeln konvertieren
        3.1.8 RasterImage-Prozessoren (RIPs)
        3.1.9 PostScript-Treiber
    3.2 PostScript Printer Description (PPD)
        3.2.1 Basis-PostScript-Treiber und PPD
        3.2.2 PPD und Graphical User Interface (GUI)
        3.2.3 PPD konfiguriert den Treiber
        3.2.4 »Hersteller-eigene« PostScript-Befehle in der PPD
        3.2.5 Zwischenbemerkung 1: Ohne GUI keine Ausnutzung aller PPD-Optionen
        3.2.6 Zwischenbemerkung 2: ESP PrintPro, eine GUI für CUPS
        3.2.7 Drucker-Grundausstattung
        3.2.8 Drucker-Zusatzausstattung
        3.2.9 Drucker-Voreinstellung
        3.2.10 Drucker-Beschränkungen
    3.3 PostScript und Linux
4. Die IPP-Implementierung durch CUPS
    4.1 PPDs - auch für Nicht-PostScript-Drucker!
        4.1.1 PostScript-Drucker - kein Problem
        4.1.2 Nicht-PostScript-Drucker: woher die PPD nehmen?
        4.1.3 Mit dem PPD-Schema können alle Hersteller ohne
Schwierigkeiten Treiber für CUPS schreiben
    4.2 CUPS 1.1 - Design-Übersicht
                Abb. 2: Ein Blockdiagramm der wichtigsten CUPS-Komponenten
    4.3 Der CUPS-»Scheduler«
        4.3.1 Der Scheduler als Print-Server
        4.3.2 Der Scheduler als HTTP-Server
        4.3.3 Der Scheduler und das »Browsing«
        4.3.4 Der Scheduler als Print-Spooler
        4.3.5 Der Scheduler und die CGI-Programme
        4.3.6 Der Scheduler als Werkzeug des Benutzers
        4.3.7 Der Scheduler und Drucker-»Klassen«
        4.3.8 Der Scheduler und Server-»Klassen«>
        4.3.9 Der Scheduler und Drucker-PPDs
    4.4 Die CUPS-Konfigurationsdateien
        4.4.1 /etc/cups/cupsd.conf
        4.4.2 /etc/cups/printers.conf
        4.4.3 /etc/cups/mime.types
        4.4.4 /etc/cups/mime.convs
        4.4.5 /etc/cups/ppd/1_infotec4700MF.ppd
        4.4.6 /etc/cups/clients.conf
        4.4.7 /etc/cups/classes.conf
    4.5 Die CUPS-Server-Konfigurationsdatei näher betrachtet
        4.5.1 Bekannte Server-Direktiven
        4.5.2 Authentifizierung für Nutzer und Administratoren
        4.5.3 Zugriffskontrollen beschränken Rechte
        4.5.4 Empfehlung: AuthClass System für Admin-Zugriff
        4.5.5 »Browsing« stellt Drucker im Netz zur Verfügung
    4.6 Die CUPS-Filterprogramme
        4.6.1 /usr/lib/cups/filter/hpgltops
        4.6.2 /usr/lib/cups/filter/imagetoraster
        4.6.3 /usr/lib/cups/filter/imagetops
        4.6.4 /usr/lib/cups/filter/pdftops
        4.6.5 /usr/lib/cups/filter/pstops
        4.6.6 /usr/lib/cups/filter/pstoraster
        4.6.7 /usr/lib/cups/filter/texttops
    4.7 Die CUPS Interface Library
    4.8 Die CUPS Backend Interfaces
                Abb.3: IPP-Server und -Client unterhalten sich per IPP. Das
Druckausgabe-Gerät wird vom Server so angesprochen, wie dieses es
versteht: LPR/LPD, HP JetDirect usw.
        4.8.1 /usr/lib/cups/backend/http
        4.8.2 /usr/lib/cups/backend/ipp
        4.8.3 /usr/lib/cups/backend/lpd
        4.8.4 /usr/lib/cups/backend/socket
        4.8.5 /usr/lib/cups/backend/parallel
        4.8.6 /usr/lib/cups/backend/serial
        4.8.7 /usr/lib/cups/backend/usb
        4.8.8 /usr/lib/cups/backend/smb
        4.8.9 Druck in eine Datei
    4.9 Die Log-Dateien von CUPS
        4.9.1 /var/log/cups/access_log
        4.9.2 /var/log/cups/error_log
        4.9.3 /var/log/cups/page_log
    4.10 Die Berkeley- und SystemV-Kommandos
        4.10.1 /usr/sbin/lpc und /usr/bin/lpstat
        4.10.2 /usr/bin/lpr und /usr/bin/lp
        4.10.3 /usr/bin/lprm und /usr/bin/lpq
        4.10.4 /usr/bin/lpadmin
    4.11 Drucker einrichten per Kommandozeile
        4.11.1 Drucker konfigurieren mit /usr/bin/lpadmin
        4.11.2 Was lpadmin in die /etc/cups/printes.conf schreibt
        4.11.3 Drucker und System kontrollieren mit /usr/bin/lpstat
        4.11.4 Beispiel für eine /etc/cups/printers.conf
        4.11.5 Beispiele für CUPS-Befehle von der Kommando-Zeile
    4.12 Verschiedene Back-Ends in Benutzung
    4.13 Drucken per Kommandozeile
    4.14 Zugang über den Web-Browser
                Abb. 4: Seit neuestem können CUPS-Drucker über einen beliebigen Browser administriert werden:
Einträge für installierte Zusatzausstattungen, Default-Einstellungen für beliebige Optionen, usw.
sind möglich. Der URI zu dieser Funktion lautet:
http://10.160.16.40:631/admin/?op=config-printer&printer_name=1_infotec4651MF."
    4.15 Die versteckte Datei ~/.lpoptions
    4.16 CUPS und Ghostscript
5. ESP PrintPro - grafische Benutzoberfläche für CUPS
                Abb. 5: Ausschnitte aus verschiedenen GUI-Fenstern für ESP PrintPro.
    5.1 Installation und Lizenzierung
        5.1.1 Derzeit über 2300 Druckertreiber
                Abb. 6: ESP PrintPro liefert derzeit Treiber fü über 2300 Drucker-Modelle.
        5.1.2 ESP PrintPro als CUPS-Server besonders ausfallsicher
    5.2 Grafisches User Interface (GUI)
        5.2.1 Der Printer Wizard
                Abb. 7: Printer Wizard-Fenster zur Auswahl des geeigneten »Backends«
        5.2.2 Der Printer Manager
                Abb. 8: Printer Manager-Fenster mit Browse-Liste aller verfügbaren Geräte.
Hier können Drucker und Drucker-Klassen hinzugefü gelöscht; modifiziert,
gestoppt, gestrtet und getestet werden.
        5.2.3 Der Print-Panel
                Abb. 9: Printer Panel-Fenster mit Liste aller verfügbaren Drucker.
Über den Button »More Options« sind alle Job-Einstellungen erreichbar.
        5.2.4 Die PrintPro-Kommandozeile
6. CUPS und ESP PrintPro in praktischer Erprobung
    6.1 Zuviel Netzlast durch »Browsing«?
    6.2 Installation von ESP PrintPro 4.1b3 auf S.u.S.E 6.4
        Auspacken
    6.3 Installation von ESP PrintPro 4.1b3 auf Solaris 2.7
    6.4 Wie man eine PPD für einen PostScript-Drucker editiert
        6.4.1 Drucker-Grundausstattung
        6.4.2 Drucker-Zusatzausstattung
        6.4.3 Drucker-Voreinstellung
        6.4.4 Drucker-Beschränkungen
    6.5 Wie man eine CUPS-PPD für einen Nicht-PostScript-Drucker schreibt
    6.6 Wie man mit Job-Optionen druckt
        6.6.1 Joboptionen auf der Kommandozeile mitgeben
        6.6.2 Joboptionen über den Browser einstellen
    6.7 Beispielaufzeichnung aus den CUPS-Logbüchern
    6.7.1 Vorbereitungen
    6.7.2 Die Einträge im Access-Log
        6.7.3 Die Einträge im Error-Log
        6.7.4 Die Einträge im Page-Log
        6.7.5 Aufzeichnungen mit dem Debug-Level
    6.8 URIs zur Abfrage von CUPS
    6.9 Einige lpadmin-Kommandos und ihre Ausgaben
    6.10 Warum CUPS die LPR-Kommandos nicht mit SETUID root installiert
7. KUPS als KDE-Frontend für CUPS
8. Troubleshooting und Fehlersuche
9. Zusammenfassung
    9.1 Wo wird CUPS in nächster Zeit auftauchen?
    9.2 Druckerhersteller und CUPS
        mehr Infos
        Über den Autor
        Anmerkung

1. Einführung: Wie die Druckprotokolle sich entwickelten

Welcher Linux-Benutzer hat sich nicht schon stundenlang mit Drucker-Konfigurations- und Anwendungsproblemen herumgequält? Einsteigern, erfahrenen Benutzern und System- und Netzwerkadministratoren bietet CUPS einen neuen Ansatz zu diesem Thema. Es basiert auf dem neuen »Internet Printing Protocol« (IPP). Deshalb und auch wegen seiner anderen Features hat CUPS das Zeug, sich zu dem kommenden Standard für Drucken unter Linux und Unix zu mausern.

An den Druckproblemen, welche die Netzwerkadministratoren laut Statistiken über die Hälfte ihrer Zeit kosten, ist zwar nicht selten die versagende Mechanik der Ausgabegeräte schuld. Aber die Probleme der Anwender mit dem häufig verwendeten »Administrator-Druckbefehl der Woche« sind tief in der bisherigen Art und Weise verwurzelt, wie die Unix-Druck-Systeme funktionieren.

1.1 Von der Erblast aus den 70er Jahren (LPR/LPD)...

Die Protokolle, die in der (Unix-)Netzwerk-Welt benutzt werden, um Drucker anzusteuern, stammen noch aus der Zeit der Zeilen-Drucker. Diese Zeilen-Drucker brachten einen ASCII-Datenstrom mit Text zu Papier. Das war in den 70er Jahren: in der EDV/IT-Branche eine halbe Ewigkeit! Seither hat sich an dem Grund-Design der Druck-Protokolle nichts geändert.

Heutige Drucker arbeiten nicht mehr zeilen-, sondern seitenorientiert. Sie bringen nicht in erster Linie Buchstaben zu Papier, sondern Grafik. Zwar können sie natürlich auch noch ASCII-Files drucken. Jedoch spielen sie ihre Stärken erst aus, wenn sie mit einer Page Description Language (PDL, z.B. PostScript oder PCL) angesprochen werden. 

Nur mit vielen Skripts, Tricks und Kniffen wurden die alten Unix-Drucksysteme so weit gebracht, auch mit diesen heutigen Druckern umgehen zu können. Es spricht andererseits auch für die Stärke der Unix-Plattform, dass das Thema »Drucken im Netzwerk« trotz allen technischen Fortschritts immer noch bewältigt wird.

1.2 ...über viele clever umschiffte Untiefen...

Denn Unix hat sich als ungeheuer flexibel, robust und anpassungsfähig erwiesen: es beruht auf einer Philosophie der vielen kleinen, unabhängig voneinander einsetzbaren Tools. Diese Tools können vom Administrator für alle Anwender konfiguriert werden: wie es gerade jetzt oder unter diesen bestimmten Umständen oder von diesem bestimmten Anwender benötigt wird. Auf diese Weise hat sich Unix (und Linux) bis heute immer erfolgreich an allerlei Neuentwicklungen angepasst.

Was das Thema »Drucken« betrifft, war es in jüngster Zeit jedoch in den meisten Fällen ein »Gehen an Krücken« - keine Spur von einfacher Konfiguration, Administration und Anwendung. Ein gewiefter Administrator oder zumindest tiefgreifende Kenntnisse des Systems sind allemal erforderlich, um am Drucksystem etwas zu ändern.

Kaum ein Unix-Anwender ist in der Lage, die Einstellungen für seine Druckjobs von Fall zu Fall umzustellen. Eventuell hat der Administrator den Anwendern zwei verschiedene Queues (Druckerwarteschlangen) eingerichtet: eine für den einseitigen Druck, eine andere für den doppelseitigen... Bestenfalls sind noch zusätzliche Queues für A3- und A4-Druck vorhanden.

Dabei haben die meisten modernen Drucker - zumindest die in der Geschäftswelt verwendeten - eine Vielzahl von Einstellmöglichkeiten:

  • sie können doppelseitig drucken;
  • auch gelochter Output ist auf Wunsch möglich;
  • sie können Druckjobs in einem Rutsch zu Broschüren zusammenhefteten;
  • oder sie mit Rückenstich-Heftung versehen und falten

  • .

Diese und viele andere Optionen bietet Hochleistungsdrucker mit entsprechenden Endverarbeitungsgeräten schon seit Jahren. Kein Privatanwender hat solche »Boliden« zu Hause.In Unternehmen, Behörden und Organisationen sind sie jedoch weit verbreitet.

MS-Windows- und Apple-MacIntosh-Benutzer kennen die Möglichkeiten solcher Drucker schon längst. Linux-Anwender konnten bisher nur neidisch sein, wenn sie über ihren »Druck«-Tellerrand schauten...

1.3 ...und Ankerplätze...

Das »alte« LPR/LPD-Protokoll ist nach Ansicht vieler Entwickler und Anwender nicht mehr unbedingt den heutigen Ansprüchen gewachsen. Dies zeigt sich auch darin, dass in den letzten Jahren zahlreiche Versuche gemacht wurden, neue Druck- und Spool-Systeme in der Unix-Welt zu etablieren: LPRng, PPR, PLP, PDQ, Palladin sind Namen solcher Neu-Entwicklungen.

Sie alle bleiben jedoch weitgehend auf dem bisherigen »Standard« verhaftet, so viele nützliche Zusatz-Features sie auch einführen mögen. Es sieht nicht so aus, als ob irgendeinem der bisherigen Neuansätze der »grosse Wurf« gelungen sei.

1.4 ...zu neuen Ufern: Internet Printing Protocol (IPP)

Das Internet Printing Protocol (IPP) bietet die Gelegenheit, in den nächsten Jahren die alten Zöpfe abzuschneiden und auf allen Unix-Plattformen (und auch in der Windows-Welt) einen neuen Standard zu etablieren. Das hier vorgestellte Open Source »Common Unix Printing System« (CUPS, mit GPL-Lizenz) ist eine der ersten funktionierenden Implementierungen des IPP und hat das Zeug, der Standard für Druck- und Spoolsysteme unter Linux (und Unix generell) zu werden.

In der vielfältigen Unix-Welt gibt es zwei Haupt-Strömungen; diese spiegeln sich auch in den Drucksystemen wieder: die »Geschmacks-Richtungen« Berkeley (BSD) und die AT&T (System V).

Zusätzlich hat jeder Hersteller seine eigenen Erweiterungen und Abänderungen zu diesen Grundrichtungen eingeführt. Viele bauten verschiedene Übergänge zur jeweils anderen Richtung an. Inzwischen herrscht auf dem Markt ein ziemliches Wirrwarr... Eine leidige Lage für Administratoren und Anwender - und auch für die Hersteller! 

Darüber hinaus verwirklicht jedes Anwendungsprogramm seine Schnittstelle zu den Druckdiensten auf andere Art. Manche -- wie Star Office, WordPerfect oder Applixware -- bringen sogar ihre »eigenen« Druckertreiber mit. Von der verwirrenden Vielfalt an Schnittstellen sind nicht einmal verschiedene KDE-Programme ausgenommen. Dabei ist KDE doch angetreten, einheitliche und leicht bedien- und konfigurierbare Benutzerschnittstellen zu schaffen!

1.5 IPP: im »Standards Track« mit Status »experimentell«

Seit Mai 1999 liegt im Standards Track der »Internet Engineering Task Force« (IETF) eine Reihe von Request For Comments (RFC) vor, die in ihrer Gesamtheit die Version 1.0 des IPP beschreiben.

Das IETF ist eine Vereinigung von Netzwerkexperten, Herstellern, Programmierern und Wissenschaftlern, die das Internet technisch weiterentwickeln. In den RFCs lassen sich (manchmal auf ziemlich unterhaltsame Art und Weise) technische Beschreibungen für viele Dinge nachlesen, die im Internet eine Rolle spielen. Der »Standards Track« ist für Dokumente bestimmt, die einen »offiziellen« Internet-Standard definieren oder auf dem Wege dahin eine Zwischenstation darstellen.

Der Status des IPP 1.0 ist noch experimentell. Jedoch werkeln die Autoren bereits an den Erweiterungen für Version 1.1. Die für das IPP relevanten RFCs tragen die Nummern 2565, 2566, 2567, 2568 und 2569 sowie 2639. Unter der WWW-Adresse

  http://www.pwg.org/ipp/

lassen sich alle für das IPP relevanten RFCs, Entwürfe, Arbeits- und Diskussionspapiere aufstöbern.

Grosse Linux-Distributionen wie S.u.S.E. haben eine komplette Sammlung von RFCs »an Bord«. Wer unter S.u.S.E. das Paket rfc aus der Serie doc installiert hat, findet unter /usr/doc/rfc/ eine Sammlung aller bisher erschienen RFCs.

1.6 Vorgeschichte der Neuentwickung

Es gibt zwei verschiedene, ältere Ausgangspunkte für die heutigen Bemühungen um einen neuen Druck-Standard:

  • -- Im März 1990 veröffentlichte die »European Computer Manufacturers Association« (ECMA) ihren »Standard« ECMA-40 unter dem Titel »Document Printing Application«. Daraus wurde bis 1996 sogar ein ISO/IEC Standard (Nr. 10175). Der Standard 10175 fusste jedoch engstens auf der OSI-Schichten-Implementierung von Netz-Protokoll-Stapeln. Dieses ISO/OSI-Schichten-Modell hat heute nur noch die Bedeutung eines guten theoretischen Erklärungs-Musters für die real verwendeten Protokolle zu Ausbildungszwecken. Im Alltag spielt das DPA-Dokument keine tragende Rolle mehr.
  • -- In der Praxis konnte das Line Printer Daemon Protocol (LPD) jahrzehntelang als Standard gelten. Das LPD ist festgehalten im RFC 1179 der IETF. Es wurde zwar erst im August 1990 geschrieben. Jedoch war es damals nicht die Grundlage für Neuentwicklungen (wie oftmals heutige IETF-RFCs, so auch die IPP-relevaten). Sondern RFC 1179 hielt 1990 in rein beschreibender Weise die Funktionalitäten der existierenden, Unix-Print- und -Spool-Systeme fest. Und die waren vom Design her bereits 15 Jahre alt, als RFC 1179 geschrieben wurde! Der RFC 1179 hatte somit immer nur informativen Charakter und brachte es nie so weit, in den Standards Track der IETF aufgenommen zu werden. Trotzdem bildete er den Ausgangspunkt und die gemeinsame Basis für die weiteren Implementierungen vieler Hersteller (auch unter MS-Windows).

1.7 Heutige Praxis: viele herstellerspezifische Erweiterungen 

Das LPD-Protokoll hat daher aus heutiger Sicht eine ziemlich beschränkte Ausgangsbasis. Es ist für eine Umgebung geschaffen worden, in der nur Zeilendruckern mit Endlospapier vorhanden waren. Diese Drucker mussten zumeist (wenig oder nicht strukturierte) Ströme von ASCII-Text ausgeben. Grafikdruck war noch undenkbar.

So waren die Hersteller mangels eines neuen allgemeinen Standards spätestens dann gezwungen, ihre eigenen Erweiterungen zu erfinden, als die Drucktechnik sich hin entwickelte zu Geräten, die Grafiken, Einzelblätter und Seitenbeschreibungs-Sprachen (PDLs) verarbeiteten. 

Heute ist durch die diversen inkompatiblen und proprietären Erweiterungen der Hersteller zum LPR/LPD-Drucken der Scheidepunkt erreicht. Es ist nicht mehr angemessen ist, RFC 1179 als »Standard« zu betrachten. Eine völlig neue Lösung muss her. Das IPP ist am Horizont. 

1.8 Die »Printer Working Group« und die IETF

Ein neues Protokoll fürs Drucken im Netz - und alle machen mit? Oder scheitert es mal wieder an der Vielfalt der Plattformen und an den Eigensinnigkeiten der Hersteller? 

In diesem Fall vermutlich nicht: Das IPP wurde von der Printer Working Group (PWG) entwickelt. In der PWG haben in den letzten Jahren alle wichtigen Hersteller von Printer-Hardware sowie einige Software-Hersteller mitgearbeitet: Xerox, Lexmark, IBM, Hitachi-Koki, i-data, Hewlett-Packard, JCI, Epson, Seiko, Canon, NEC, Panasonic, Peerless, Kodak, Kyocera, Tektronix, Okidata, Sharp, Heidelberg, Océ, SEH, QMS, Samsung, Compaq, Novell, Microsoft, Adobe... Und alle diese Hersteller haben angekündigt, dass ihre Geräte und Produkte der nächsten Generation Funktionen für das IPP eingebaut haben werden.

Die PWG hatte zuvor bereits die Printer-MIB, eine Management Information Base (MIB) für Druckausgabegeräte wesentlich mitgestaltet. Diese MIB wird für das Simple Network Management Protocol (SNMP) benötigt. Sie legt die Struktur einer Art Datenbank fest. Diese Datenbank tragen Drucker in sich. In ihr halten sie Informationen über sich und ihren Zustand fest. Die Datenbank kann via SNMP abgefragt werden. Sie hilft beim Netzwerk-Management, um Drucker im und übers Netzwerk zu verwalten.

Den MIBs, dem SNMP und vielen anderen Protokollen und Standards für das Funktionieren der »Inter-Netze« wurden erst über das IETF endgültig Leben eingehaucht, selbst wenn sie ursprünglich »auf anderem Mist gewachsen« waren. Auch das IPP wird mit dem »Segen« der IETF seinen Weg auf den Desktop jedes PC-Benutzers und in die »Innereien« jedes modernen Druckers machen.

2. Das IPP als kommender Standard

Die IETF hat nicht nur die grundlegenden Transferprotokolle (TCP/IP) zu Standards erhoben, diedas Internet erst zur heutigen Wirklichkeit werden liessen. Es hat auch eine Reihe von Anwendungsprotokollen für verschiedene Bereiche definiert: für e-Mail, Datenübertragung und das WWW.

Drucken über das Internet kommt jetzt dazu. Und wir alle haben verfolgt, wie schnell die Internet-Leitlinien sich auch zu Intranet-Standards entwickeln. Ohne Zweifel wird das IPP sich in den nächsten Jahren schnell durchsetzen.

Wenn es um Drucken im Netzwerk geht, ob WAN oder LAN: am IPP führt kein Weg vorbei!

2.1 Design-Ziele des IPP

In das Design des IPP flossen viele Ideen der ECMA- und ISO/IEC-Papiere ein. Gleichzeitig bietet es über ein »Mapping« auf den LPD (RFC1179) eine gewisse Rückwärtskompatibilität zu den wichtigsten Funktionen bestehender Installationen. Obwohl es einen völligen Neuanfang macht, ist damit sichergestellt, dass vorhandene Anwendungen weiterlaufen.

Welche Funktionen bietet das IPP? Was ist so neu daran? Natürlich muss es als Grundvoraussetzung für eine erfolgreiche Einführung alles das können (und zwar besser!), was die »alten« Protokolle und heutige Installationen bereits mehr oder weniger gut machen:

  • Druckjobs an den ausgewählten Drucker schicken (die sog. Push-Methode); 

  • ;-) 
  • einen zuvor geschickten Job wieder annullieren; 
  • moderne PDLs (PostScript, PCL,...) verarbeiten; 
  • auf Anforderung interne Anweisungen der PDLs mit eigenen überschreiben;
  • Rückmeldungen des Druckers bei Problemen entgegennehmen;
  • den Fortgang eines Jobs überwachen.

Client beauftragt den IPP-Server, eine zu druckendeDatei selbst bei einer URL abzuholen...

Abb. 1: Ein IPP-Client kann einem IPP-Server die URI eines zu druckenden Dokumentes übergeben. Der Server holt dieses selbständig per FTP oder HTTP 1.1 ab und druckt es aus.

Die Bedürfnisse und Anforderungen von drei Personengruppen standen bei den Überlegungen für das IPP Pate: Anwender, die drucken wollen; Bediener, die die Geräte am Laufen halten sollen; und Administratoren, die für die Einrichtung, Konfiguration und Instandhaltung der Geräte im Netz sorgen müssen. Folgende neuen Design-Ziele für das IPP wurden durch die PWG formuliert: 

  • einen IPP-Drucker oder -Server anweisen, das zu druckende Dokument selbst abzuholen (die sog. Pull-Methode); 
  • Printer im Netzwerk finden, selbst wenn sie vorher noch nicht bekannt sind (IP-Adresse, Standort); 
  • eine Liste der besonderen Fähigkeiten eines bestimmten Druckers abrufen ;
  • Informationen über Treiber (Installation, Konfiguration, Auffinde-Ort...) für den ausgewählten Drucker verfügbar machen; 
  • das Drucken bereits beginnen, noch bevor alle Dokumentendaten übertragen sind;
  • mehrere Dokumente zu einem einzigen Druckjob zusammenbinden; 
  • den Fortgang eines Jobs von überall her überwachen; 
  • Drucker und Druckserver von überall her konfigurieren; 
  • ausreichende Sicherheit (Authentifizierung der Nutzer, Verschlüsselung der Druckdaten...) für das Drucken über das Internet; 
  • Zusammenspiel mit modernen Internet-Konzepten (Web-Browsing, Verzeichnisdienste...). 

2.2 IPP-Umsetzung als HTTP-Erweiterung

Beinahe alle diese Ziele erreicht das IPP 1.0. Es erfindet das Rad jedoch nicht neu. Sondern es setzt auf jenem bereits bestehenden Client/Server-Protokoll auf, welches das Internet am Wachsen und Pulsieren hält: das »Hypertext Transfer Protokoll« (HTTP 1.1).

Wie bitte? HTTP?! Auf den ersten Blick eine eigenartige Idee...

Was ist denn das HTTP? Dient es nicht einzig und allein dem Internet-Surfen?! Erstmal schon. Aber HTTP ist angelegt als ein vollwertiges Datenübertragungs-Protokoll. Es stellt die Verbindung zwischen Client-Browser und Web-Server her, hält sie aufrecht und beendet sie. Es überträgt HTML-Seiten auf den lokalen Rechner und übergibt sie dem Browser zur Darstellung. Das ist, was jeder Internet-Surfer erstmal sieht.

2.3 HTTP überträgt alles, nicht nur HTML!

Was den meisten Anwendern nicht bewusst ist: eingebettet in HTML-Seiten sind oftmals noch viele andere Formate: Grafiken (GIF, JPEG, PNG...), Sounds (WAV, MP3...), ausführbarer Code in Form von Java-Applets, usw. Alle diese Datei-Formate werden über das HTTP automatisch vom Server zum Client übertragen. Er kann sie auch direkt herunterladen und auf der Festplatte speichern. Oder sie werden vom Browser automatisch anderen Programmen zur Weiterverarbeitung übergeben: Plug-Ins für Audio-, Video-, PDF- oder was-auch-immer für Formate arbeiten Hand in Hand mit dem Browser, um die übertragenen Dateien ihrer Bestimmung zuzuführen.

Diese Formate werden über die Multimedia Internet Mail Extensions (MIME) vom Server mit einer Kennung versehen und somit vom Browser einem bestimmten Anwendungsprogramm zugeordnet. Der Browser als Client verwendet zum »Holen« der Dateien den im HTTP definierten GET-Befehl.

2.4 HTTP ist auch für die »Gegenrichtung« nutzbar

Eine andere Tatsache ist vielen ebenfalls nicht bewusst. Mit der Methode POST ist es möglich, Daten in die andere Richtung zu übertragen: vom Client zum Server. Wer zum Beispiel im Web Formulare ausfüllt und die Einträge per »Absenden!«-Button freigibt, hat den Browser angewiesen, einen dieser Befehle zu verwenden...

HTTP 1.1 ist erfahrungsgemäss ein äusserst robustes, bewährtes und flexibles in jede Richtung funktionierendes Client-Server-Datenübertragungsprotokoll.

Was lag folglich näher, als es für die Übertragung von Druckdaten rund um die Welt (oder auch nur von einem Ende des Raums zum andern) »aufzubohren«?

2.5 Adressierung über URIs

HTTP verwendet für die Adressierung aller Objekte, die Methode der allseits bekannten Uniform Ressource Identifiers (URIs). Die Eingabe in der Adresszeile

  http://www.linux-magazin.de/ausgabe/2000/02/CUPS/cups1.html

fordert den Browser auf, die Methode http:// zu verwenden, um vom Rechner www in der Domäne linuxmagazin.de im Serververzeichnispfad /ausgabe/2000/02/CUPS/ die Datei cups1.html zu holen und anzuzeigen.

Auf fast jedem Rechner im Internet oder im lokalen Netz laufen verschiedene Dienste. Rechner im Netz unterscheiden sich voneinander durch ihre IP-Adresse. Ein Server erkennt anhand der IP-Adresse, ob er selbst oder ein anderer »gemeint» ist.

Damit der angesprochene Rechner aber »weiss«, welcher Dienst von ihm verlangt wird, muss er noch ein zusätzliches Unterscheidungsmerkmal haben. Dieses besteht in der Portnummer, an diesich die Anfrage richtet.

2.6 Portnummer 80 für HTTP

Portnummern können als Zusätze zu IP-Adressen in einer URI mitgegeben werden. Portnummern sind Kennungen für Dienste, die ein Rechner im Netz bereitstellt. Sie sind nicht zwingend festgelegt.

Dem Web-Administrator des Linuxtages könnte es durchaus in den Sinn kommen, seinen HTTP-Server einzig und alleine auf die Portnummer 12345 hören zu lassen. Allerdings müssten dann die Besucher der Webseiten diese Kennung im Browser explizit angeben, etwa so:

  http://www.linuxtag.de:12345/DasIst/NurEin/Beispiel.html

Wenn jedoch jeder Webmaster seine Portnummern willkürlich wählen würde, wäre das Internet weitaus komplizierter zu handhaben als es ist. Deshalb sind für bestimmte Dienste sogenannte well known ports reserviert. Einen Browser kann man mit der Methode

  http://...

ohne Angabe einer Portnummer zu einem Webserver schicken: dann verwendet er von sich aus den Port 80. Denn dieser ist für Dienste vorgesehen, die über HTTP abgewickelt werden.

2.7 Portnummern für andere Dienste

Wenn man den Netscape ohne Angabe eines Ports zum Zweck einer Datenübertragung per File Transfer Protocol (FTP) mit der Methode

  ftp://...

zu einer IP-Adresse schickt, klopft er automatisch am Port 21 an. Denn für FTP ist der Port 21 der Standard-Port. Mit

  ldap://...

geht Netscape zum Port 389. Dieser Port ist für das Lightweight Directory Access Protocol (LDAP) vorgesehen. 

2.8 LDAP-Dienst für netzweite Informationen

Mit LDAP können bereits heute sogenannte Directory Services (Verzeichnisdienste) in Anspruch genommen werden. Verzeichnisdienste stellen bestimmte Informationen netzweit zur Verfügung. Dies können beispielsweise interne e-Mail-Adressen oder Telefon-Nummern von Mitarbeitern eines Unternehmens sein. LDAP-Informationen müssen in einer geeigneten Datenbank gespeichert sein.

Vielerorts werden etwa interne e-Mail-Adressen über einen LDAP-Dienst online verfügbar gemacht: ohne dass der Benutzer etwas über die genaue Funktionsweise weiss, wird dann beim Schreiben einer e-Mail-Adresse nach Eingabe der ersten Buchstaben des Namens die komplette Zeile richtig ergänzt. Wenn alle Änderungen ständig auf dem zentralen LDAP-Server eingepflegt werden, brauchen sich die Benutzer nicht mehr um die Aktualisierung ihrer Firmen-Adressbücher selbst zu kümmern.

2.9 IPP wird LDAP-Anbindung haben

In Zusammarbeit mit dem IPP wird LDAP in der Lage sein, den Benutzern im Netz Informationen über verfügbare Drucker, ihre jeweiligen Fähigkeiten zur Verfügung zu stellen: der zuständige Betreuer, der Drucker-Standort, die geladene Papierart and andere Details.

Alle oben genannten Ports sind die Standard-Ports für die genannten Dienste. Ohne Angabe von Portnummer findet der Browser den Kontakt mit diesen Diensten alleine aufgrund der Nennung der zugehörigen Methode (wie http, ftp, ldap usw.). Werden diese Dienste an anderen als diesen well known Ports bereitgestellt, müssen deren Nummern bei der Adressierung ausdrücklich mitverwendet werden, damit sie gefunden werden. 

2.10 IPP: revolutionär neu, und doch altbewährt!

Der Ansatz, nicht etwa etwas völlig Neues zu entwickeln, sondern das IPP auf dem HTTP 1.1 aufzusetzen, bietet somit mehrere gewaltige Vorteile:

  • HTTP 1.1 ist ein bewährtes, stabiles, universell gesprochenes Protokoll, ein offener Standard, der relativ leicht erweitert werden kann; 
  • Alle Drucker-Hersteller können mit HTTP bereits relativ gut umgehen, da sie in den letzten Jahren ohnehin schon »embedded« Web-Server in ihre Produkte eingebaut haben. (Man versuche einmal testweise, die IP-Adresse eines Netzwerkdruckers im Browser einzugeben...); 
  • HTTP 1.1 funktioniert rund um die ganze Welt, über Hardware- und Betriebssystem-Grenzen hinweg, über Router und Gateways, in LAN und WAN, in Intra- und Inter-net, durch Firewalls hindurch (wenn gewollt), verschlüsselt und unverschlüsselt...; 
  • Um nach einem Drucker mit einem bestimmten Fähigkeiten-Profil zu suchen, lassen sich sehr leicht Verzeichnisdienste wie LDAP (siehe unten) ankoppeln. Entsprechende Standards sind in Arbeit; 
  • Verschlüsselung über SSL3 (»Secure Socket Layer«) oder TLS (»Transport Layer Security« - ein in Arbeit befindlicher Standard zur sicheren Datenübertragung im Internet) lässt sich zum IPP genauso einfach hinzufügen wie zu HTTP. 

Das IPP liegt demnach ganz und gar in einer guten und bewährten Unix-Tradition: es ist so aufgebaut, dass es sich nahtlos in die Reihe anderer Internet-Standards einfügt und mit diesen zusammenarbeitet...

2.11 Die URIs des IPP

Das Internet Printing Protocol hat von der IANA (der Internet Assigned Numbers Authority) inzwischen sein eigenes Adressierungs-Schema erhalten. Es lautet - wen wundert's? - ipp://. Auch eine eigens reservierte Standard-Portnummer ist vorhanden: es ist 631.

Künftig kann ein IPP-Druck-Client (gleichgültig, ob Linux, Unix, Mac, BeOS, Amiga oder Windows) den IPP-Drucker (das ist nichts anderes als ein Drucker mit einem eingebetteten IPP-Printserver) daher auf folgende Weise ansprechen:

  ipp://meindrucker.deinedomaene.hier/

Die dem IPP reservierte Portkennung ist 631. Da das IPP mit dem HTTP sehr eng verwandt ist, kann der IPP-Daemon eines IPP-Servers oder Printers auch mit jedem Standard-Browser »sprechen». Wenn der Administrator nicht Gründe hatte, eine andere Portnummer einzurichten, sollte die Adressierungsmethode von einem beliebigen Brrowser aus wie folgt sein:

  http://meindrucker.deinedomaene.org:631/

Das sollte genügen, um den Drucker mit der Ausgabe einer HTML-Seite antworten zu lassen. Auf dieser Seite könnten sich dann Hyperlinks befinden, die den Weg zu Druckertreibern, gespoolten Druckjobs und deren Status und Beeinflussung (wie Löschen oder Stoppen oder Zurückstellen) oder der Konfiguration und Administration des Servers selbst weisen...

2.12 Drucken wie Browsen

Auf diese Weise kann jeder Browser zum IPP-Client werden, selbst wenn sein Programmierer nicht im Traum eine solche Möglichkeit vorgesehen hatte!

Wenn ein Standard-HTTP-Browser verwendet wird, kann (zumindest heute) nur die Methode http:// angewandt werden und erfordert dann auch die Angabe des Ports 631. Wenn eine auf IPP spezialisierte Software (oder eventuell ein Browser der nächsten Generation?) zum Einsatz kommt, genügt ipp:// ohne Portnummer. 

Für einen dedizierten IPP-Print-Server gilt das Analoge. Wenn er den festgelegten Standard einhält, muss er bei einer HTTP-Verbindung mit seinem Port 631 eine HTML-Seite zurücksenden. Alle über ihn verfügbaren Drucker mitsamt ihren Eigenschaften müssen darauf verzeichnet sein. Jeder Drucker muss über einen Hyperlink anwählbar sein..

Erweiterte Implementationen des Protokolls sollten sogar einen »Treiber«-URI anbieten. Von der aus muss sich ein benötigter Druckertreiber auf dem Client installieren lassen, falls dieser noch keinen hat.

Ach ja, bevor ich vergesse, es zu erwähnen:

  application/ipp

so lautet die MIME-Zuordnung für das IPP als Anwendung. Damit können alle Dateien, die per Netz auf einem IPP-Server landen, der richtigen Anwendung zugeführt werden, wenn sie diese MIME-Kennzeichnung tragen.

3. Grundsätzliches zum Thema Drucken

Eine Datei so auszudrucken, wie sie auf dem Bildschirm aussieht, ist nicht so einfach wie es scheint. Bevor sie von der Festplatte auf's Papier kommt, muss eine ganze Reihe von Aufgaben erledigt sein.

Wer von den Lesern weiss, wozu PostScript und PostScript-Printer-Descriptin-Dateien (PPDs) dienen, braucht hier nicht weiterzulesen. Er kann direkt zu Abschnitt 4 gehen. 

3.1 Wie kommt die Datei von der Festplatte auf das Papier? 

In der Steinzeit des PC-Druckens wurden nur Buchstaben gedruckt. Das wurde von Zeilendruckern erledigt, die heute kaum noch jemand kennt. Es gab keine grosse Auswahl an Schrifttypen. Der Job des Drucksystems war relativ einfach: den gewünschten Schrifttyp auswählen, den geschickten (z.B. ASCII-)Code Buchstabe um Buchstabe umsetzen, an den richtigen Stellen noch einen Zeilenvorschub, Wagenrücklauf und Formularvorschub durchführen.

3.1.1 Dateien sind verschieden

Ganz anders heute. Auf der Festplatte liegen nur noch selten reinen Textformate. Die Formate verschiedener Textverarbeitungsprogramme können völlig unterschiedlich sein. Dann gibt es noch Grafik-Programme, Tabellenkalkulationen und-und-und... Das Format auf der Festplatte unterscheidet sich auch garantiert von dem Format, das der Drucker braucht, damit er das Papier an den richtigen Stellen schwärzt (oder färbt).

3.1.2 Drucker sind verschieden 

Und beinahe jeder Drucker will es gerne anders haben... Es gibt Drucker, die TIFF direkt drucken können. TIFF ist ein standardisiertes Raster-Format. Beinahe alle Druckausgabegeräte verwenden irgendeine Form von Rasterformat. Nur Plotter nicht: sie können mit Stiften Linien zeichnen. Die meisten Drucker verwenden ein eigenes, proprietäres Rasterformat.

Die Auflösung der Rasterpunkte ist ebenfalls nicht für jeden Drucker gleich. Es gibt zwischen 300 dpi (Dots per Inch, ein Mass für die Auflösung) als heutiger Untergrenze eines Standard-Laserdruckers bis 4800 dpi für Film-Belichter im Grafischen Gewerbe so ziemlich alles.

3.1.3 Für jede mögliche Umwandlung ein Programm? 

Vor dem Drucken muss mindestens eine Formatumwandlung stattfinden. Will man eine Seite aus dem Internet ausdrucken, braucht man eine Konvertierung von HTNL in das druckerspezifische Format. Das erledigt ein Konvertierungsprogramm. Unter Linux heissen solche Programme oft Dateifilter.

Viele Speicherformate für PV-Programme - viele Rasterformate für Drucker: das erfordert noch viel mehr Konvertierungsprogramme, wenn die Übersetzung direkt stattfinden würde. Hersteller von Druckern wären überfordert, wenn sie für jedes PC-Datei-Format (und jedes Betriebssytem) einen Filter schreiben müssten, der die Druckdatei abholt und richtig umgewandelt beim Drucker abliefert. Programmierer von Anwendungen wären überfordert, wenn sie einen Filter für jedes mögliche Druck-Ausgabe-Gerät schreiben müssten.

3.1.4 Die Theorie: eine Seitenbeschreibungssprache 

Die (theoretische) Lösung ist einfach: man trifft sich in der Mitte, man teilt den Übersetzungsvorgang in zwei verschieden Schritte ein. Der gemeinsame Nenner ist eine Page Description Language (PDL, Seitenbeschreibungssprache). Jedes Anwendungsprogramm kommt dann mit einem Ausgabefilter Richtung Drucker aus - einem, der die zu druckende Datei in das PDL-Format umwandelt. Jeder Drucker braucht nur einen Eingangsfilter: der holt den Druckjob als PDL-Datei ab und macht daraus das geforderte druckerspezifische Rasterformat.

3.1.5 Die Praxis: mehrere Seitenbeschreibungssprachen

Das Leben ist komplizierter als die schöne Theorie. Es gibt mehr als eine Seitenbeschreibungs-Sprache. Neben PostScript (entwickelt von der Firma Adobe) ist PCL (von Hewlett-Packard) sehr weit verbreitet. Wegen der Art der mathematischen Beschreibung der in der Grafik angeordneten Linien und Objekte werden PDLs oft als Vektorgrafik-Format bezeichnet. Sowohl PostScript als auch PCL gibt es in verschiedenen Versionen. (Die Entwicklung wird auch nicht stehen bleiben). Somit gibt es auch mindestens PostScript- und PCL-Drucker. Manche Drucker verstehen mehrere PDLs.

3.1.6 PostScript als PDL

PostScript ist eine Pogrammier-Sprache, die darauf spezialisiert ist, die Anordnung von Linien, Schriften und Grafiken auf einem Ausgabe-Medium (in der Regel Papier) zu beschreiben. Eine PostScript-Datei beschreibt die Druckseite als Grafik. Sie kann das unabhängig von der physikalischen Auflösung des Druckers tun.

Der PostScript-Standard ist ein proprietäres Format. Adobe hat ihn allerdings offengelegt und gut dokumentiert (sonst hätte er sich nicht so weit verbreitet) [1]. PostScript-Drucker »verstehen« diese Programmier-Sprache. Indem sie sie interpretieren, färben sie das Papier an den gewünschten Punkten mit der entsprechenden Druckfarbe. PostScript wurde erstmalig Anfang der 80er Jahre eingesetzt. Aktuell ist die PostScript-Version 3.

3.1.7 Vektoren zu Pixeln konvertieren

Druck-Ausgabegeräte sind in der Regel Pixel-orientiert. Sie können keine »Linie« direkt zeichnen (das können nur Plotter). Sie ordnen Punkte so an, dass sie dem menschlichen Auge als Linie erscheinen. Da die PostScript-Befehlssprache im Prinzip vektor-orientiert ist, muss eine PostScript-Druckdatei in die entsprechende pixelweise Anordnung der Farb- oder Tonerflächen und -linien »übersetzt« werden, bevor die Druckausgabe tatsächlich erfolgen kann.

Das Format, in welchem ein Drucker die »pixelweise« Seitenbeschreibung erwartet, ist ebenfalls hersteller- und typabhängig. Das auf jedem Linux-Rechner vorhandene Ghostscript ist nichts anderes als ein PostScript-Interpreter, welcher in das entsprechende Rasterformat des Druckers übersetzt. Diese Übersetzungsarbeit erledigt eine Kette geschickt hintereinandergeschalteter Filterprogramme. Sie ist recht aufwendig und belastet einen Rechner vor allem bei grossen oder farbigen Druckfiles sehr stark.

3.1.8 RasterImage-Prozessoren (RIPs)

Bei PostScript-Druckern braucht die PostScript-nach-Raster-Übersetzung nicht von dem Rechner selbst durchgeführt zu werden, der das PostScript-File drucken will, sondern diese Berechnung wird von einem »Raster Image Process« (RIP) übernommen, welcher mit dem PostScript-Drucker integriert ist.

Das RIP (ja, im Deutschen hat es sich eingebürgert, das RIP zu sagen anstatt der RIP...) kann eine reine Software-Lösung sein. Bei Hochleistungs-Farbdruckern läuft die RIP-Software oft auf einer separaten Unix-Maschine von Sun, SGI oder anderen Herstellern. An diesen Rechner ist dann die Marking Engine, der physikalische Drucker, angeschlossen. Bei anderen Druckern ist das RIP hardwaremässig als spezialisierter Chip im Drucker implementiert (meist bei kleineren PostScript-Druckern).

3.1.9 PostScript-Treiber

Die Grundfunktion eines PostScript-Treibers ist: aus dem gegebenen Format eine PostScript-Datei erzeugen. Mit purem PostScript wird sich jedoch kaum ein Drucker zufrieden geben. Selbst wenn er drucken würde, käme der Output als simpler, einseitiger A4-Job im Ausgabefach heraus. Und das wiederum würde dem Anwender vermutlich nicht gefallen: wollte er den Job doch doppelseitig und gelocht und geheftet und auf dem grünen Papier im mittleren Papierfach und-und-und...

Diese Sonderfunktionen des Druckers liegen ausserhalb der Reichweite der PDL (hier PostScript). Diese müssen vom Drucker separat angefordert werden. Hier kommen die soigennanten PPDs ins Spiel.

3.2 PostScript Printer Description (PPD)

Hersteller von PostScript-Druckern müssen sich an die Spezifikation der »PostScript Printer Description« (PPD) halten. Ein PPD-file ist eine menschen- und maschinenlesbare ASCII-Datei. In ihr ist eine formalisierte Beschreibung der Eigenschaften und installierten optionalen Komponenten des Druckers nachzulesen. PPDs sind durch Adobe ebenfalls gut dokumentiert [2].

3.2.1 Basis-PostScript-Treiber und PPD

Unter Windows oder dem MacOS ist ein Adobe-kompatibler PostScript-Druckertreiber aus zwei Komponenten zusammengesetzt: zuerst muss die Basisversion eines Treibers vorhanden sein, meist ein Original-Adobe PostScript-Treiber. Dieser erstellt aus den Ausgangs-(Dokumenten- oder Grafik)-Formaten einen einfachen (»plain«) PostScript-Code (d.h. ohne viele zusätzliche Ausgabe-Optionen). Mit dieser Grundversion kann man einseitige (A4-)DruckJobs auf jedem PostScript-fähigen Drucker ausgeben. Diese Funktionalität ist normalerweise auf jedem Linux-System ebenfalls vorhanden, da hier für jeden Druckjob ebenfalls »einfaches« PostScript erzeugt werden kann.

Sobald komplexere Kommandos an den Drucker geschickt werden müssen, um das endgültige Aussehen des Druckergebnisses zu beeinflussen, kommt die PPD-Datei ins Spiel. Diese setzt auf dem Grund-Treiber auf und erweitert dessen Funktionalität um all die Hersteller-spezifischen Besonderheiten des Druckers. 

3.2.2 PPD und Graphical User Interface (GUI)

Die PPD-Datei wird bei dieser Treiber-Architektur nicht nur ausgewertet, um das Druck-File zu erzeugen, sondern auch, um die grafische Benutzer-Oberfläche (Grafical User Interface - GUI) des Treibers zu verändern und an die vorhandenen Druckereigenschaften anzupassen. In der Benutzer-Oberfläche werden so die druckerspezifischen Auswahl-Optionen angeboten, welche in der PPD festgelegt sind. (Für noch-Windows-Benutzer: im Druckerordner mit der rechten Maustaste auf den PS-Drucker klicken, »Eigenschaften« wählen...) Der Treiber verarbeitet bei der Erstellung des Druck-Files die angewählten Optionen und baut die entsprechenden PostScript- oder Hersteller-spezifischen Steuerbefehle in den Druckdatenstrom ein.

3.2.3 PPD konfiguriert den Treiber

PPDs werden in beinahe unveränderter Form sowohl auf Macintosh-, als auch auf Windows-Plattformen verwendet. In den PPDs sind die standardisierten PostScript- oder die herstellerspezifischen Kommandosequenzen zur Ansteuerung des Druckers festgehalten. Die PPD definiert ausserdem des Druckers Default-Einstellungen (Voreinstellungen) und weist auf gegenseitige Ausschlüsse miteinander unvereinbarer Optionen hin. Die PPD wird unter Windows vom Basis-Druckertreiber ausgelesen, um sich die eigene Funktionalität mit den druckerspezifischen Besonderheiten aufzumotzen. Eine PPD ist sozusagen ein Mechanismus, der es dem Treiber erlaubt, sich selbst auf den konkreten Zieldrucker hin zu konfigurieren.

3.2.4 »Hersteller-eigene« PostScript-Befehle in der PPD

Es gibt für die gebräuchlichsten Optionen zwar standardisierte PostScript-Befehle. Aber die Drucker-Hersteller haben die Freiheit, eigene Befehle zu definieren. Davon machen sie auch kräftig Gebrauch, z.T. notgedrungen.

Die Firma Kodak beispielsweise war die erste, welche einen PPD-Befehl zum Ansteuern einer Papierschneide-Vorrichtung brauchte, die in dem neuentwickelten, 110 Seiten/Minute schnellen Hochleistungs-Drucker »DigiSource 9110«zum Einsatz kommt. (Die Fertigung dieses Modells ist inzwischen in die Hände der Firma Heidelberg übergegangen und wird heute unter dem Namen »Digimaster 9110« u. a. von Danka vermarktet). Dieser für den hochprofessionellen Bereich konstruierte Drucker hat einige besondere Features, die in dieser Vielseitigkeit von keinem Konkurrenz-Produkt erreicht werden: bis zu 6 verschiedenfarbige Blätter können pro Druckjob gezogen werden; Ausdrucke auf A3 oder A4 können zu einem »Rückenstich«-gehefteten, gefalteten und beschnittenen Heft in A4 oder A5-Endformat ausgegeben werden; usw. Es gab zum Zeitpunkt der Entwicklung dieses Druckers keine »fertigen« Adobe-PostScript-Befehle, die ein Endverarbeitungsgerät mit diesen Optionen ansteuern konnte.

Folglich definierte Kodak eigene, nur diesem Drucker verständliche Maschinen-Befehle, welche in der zugehörigen PPD-Datei festgehalten sind, aber im GUI des Treibers in menschen-verständlicher Form zur Auswahl stehen. Diese Kodak-PPD-Befehle fangen mit dem Kürzel »*KD...« an. Solche mit *KD.. beginnenden Schlüsselwörter werden uns in den folgenden Listings an manchen Stellen noch begegnen. Andere Drucker-Hersteller haben in Absprache mit Adobe ihre eigenen Befehle: Hewlett-Packard benutzt als Befehlseinleitung »*HP...«, Ricoh »*RI...«, Lexmark »*LX...« ...

3.2.5 Zwischenbemerkung 1: Ohne GUI keine Ausnutzung aller PPD-Optionen

Anmerkung: Prinzipiell ist es möglich, alle diese Optionen unter Linux auch von der Kommandozeile aus zu benutzen. Natürlich muss das verwendete Druck-System dann PPDs auslesen und richtig interpretieren können. Das hier beschriebene CUPS kann dies. Man betrachte einmal folgende Kommandozeile:

  root@transmeta:/home/kurt/Downloads > lpr -P Digimaster9110\

     -o KD75Pamphlet=True -o KD95Trim=True -o KD04DocExit=BookletMaker\

     -o KD10Duplex=DuplexNoTumble -o KD05BodyPaper=A3 \

         -o KD25FrontCoverMode=BothSides\

     -o KD26FrontCoverPaper=A3 -o PageSize=A3 -o page-ranges=1-8\

          /kurt/home/LinuxMagazin/Teil2cupsesp.pdf

Die Backslashes am Ende der Zeilen sollen symbolisieren, dass dies alles eigentlich in einer Zeile geschrieben werden müsste, um den Auftrag wie folgt zu drucken:

  • auf dem Drucker Digimaster9110...
  • ...die Datei /kurt/home/LinuxMagazin/Teil2cupsesp.pdf drucken,
  • davon jedoch nur die Seiten 1 bis 8...
  • ...auf A3-Papier...
  • ...als A4-Heft (=Pamphlet), d.h. fertig gefaltet, »Rückenstich«-geheftet und Front-beschnitten...
  • ...mit einem kartonierten Umschlag auf andersfarbigem Papier versehen (FrontCoverPaper).

Diese Optionen sind unmöglich auswendig zu lernen. Zudem lauten sie bei einem anderen Hersteller, der eventuell eines Tages dieselben Features anbietet, mit Sicherheit anders. Sie müssen mühsam aus der PPD ausgelesen und auf der Kommandozeile richtig eingegeben werden.

3.2.6 Zwischenbemerkung 2: ESP PrintPro, eine GUI für CUPS

Wer alle Optionen eines modernen PostScript-Druckers benutzen will, hat folglich nur eine praktikable Möglichkeit: über ein grafisches User-Interface (GUI) die vom Hersteller-PPD auszulesen, die entsprechenden Optionen mit der Maus zu markieren. Die Kommandozeile wird besser nur dort benutzt, wo sie tatsächlich besser und schneller ist...

Das im Abschnitt 5 vorgestellte kommerzielle »ESP PrintPro«, das auf CUPS basiert, ist eine grafische Benutzeroberfläche für CUPS, die zudem mit (derzeit) 2300 Drucker-PPDs ausgeliefert wird. Da dürfte ein grosser Teil des aktuellen Drucker-Marktes abgedeckt sein.

ESP PrintPro kann unter Linux erstmals alle Features in einer PPD genauso ansprechen, wie es unter Mac-OS oder MS-Windows möglich ist. Der besondere Clou bei ESP PrintPro: Es kann über Druckerbeschreibungsdateien, die dem PPD-Format entsprechen, auch PCL- und andere Nicht-PostScript-Drucker ansteuern, da deren Escape-Sequenzen oder anderen Steuersignale in der Quasi-PPD eingebettet und für die GUI auslesbaren Form beschrieben sind...

3.2.7 Drucker-Grundausstattung

Zu den Grund-Eigenschaften eines PostScript-Druckertyps zählen u.a. folgende:

  • Kann er doppelseitig drucken?
  • Kann er mit verschiedenen Papierformaten umgehen (A4, A3, Briefumschläge, Sonderformate)?
  • Kann er Papier gezielt aus einem bestimmten Fach ziehen (z.B. unten, wo immer das Recyclingpapier eingefüllt ist)?
  • Kann er den Output in einem bestimmten Fach ablegen (obere Ausgabe, Sorterfach Nr. xy)?
  • Welche PostScript-Schriften hat er geladen?

3.2.8 Drucker-Zusatzausstattung

Viele Drucker können vom Hersteller mit Zusatzausstattungen aufgerüstet werden. Die PPD muss die tatsächlich vorhandene Konfiguration kennen, um richtig zu funktionieren. Optional installierbare Komponenten können sein:

  • zusätzliche RAM-Module (als Speicher für große Druck-Jobs oder zum Downloaden zusätzlicher Schriftfonts);
  • zusätzliche Drucker-Festplatte;
  • Duplex-Einheit (um doppelseitig zu drucken)

  • zusätzliche Papiermagazine; 
  • Endverarbeitungsgerät (um aus dem Druck-Job eine fertig geheftete Broschüre zu machen);

  • usw.

Bei der Erst-Installation eines Druckers sollte man sicherstellen, dass des Druckers PPD hinsichtlich seiner Zusatzausstattung auf dem richtigen Stand ist. Bei Nachrüstungen muss dies in die PPD eingetragen oder abgeändert werden. Kaum jemand wird jedoch Einträge in die PPD manuell vornehmen. Unter Windows oder Mac ist es ein GUI (Graphical User Interface), welches nach den entsprechenden Mausklicks die Einträge umschreibt. Unter CUPS gibt es viele Optionen (siehe unten). Für Mäuse-Hasser und Tastatur-Liebhaber, oder für Scripte, die Druckfunktionen benutzen, stehen eine Reihe von Kommandozeilen-Tools zur Verfügung, die korrekte Einträge in die PPD schreiben.

3.2.9 Drucker-Voreinstellung

Ein Drucker kann über die PPD-Vorgaben vom Treiber so angesteuert werden, dass jeder seiner Funktionen mit einer bestimmten Vor-Einstellung versehen ist. Jeder Job wird dann nach diesen Vorgeben gedruckt, wenn nicht explizit etwas anderes bestellt wird:

  • »Drucke immer doppelseitig, ausser es ist etwas anderes angegeben.« 
  • »Nehme das Papier aus dem Grossraum-Magazin, ausser es ist ausdrücklich ein anderes angewählt.«

Wer zu 90 % seine Jobs doppelseitig, geheftet und gelocht druckt (wie ich), sollte dafür sorgen, dass dies als Voreinstellung in der PPD vermerkt ist. Sonst muss er diese Optionen bei jedem Druckjob extra angeben.

3.2.10 Drucker-Beschränkungen

Manche der anwählbaren Drucker-Optionen schliessen sich gegenseitig aus:

  • Offensichtlich ist, dass ich für ein Blatt nicht gleichzeitig A4 und A3 anwählen kann (manche Drucker lassen allerdings zu, dass innerhalb eines Druck-Jobs die Formate gemischt werden).
  • Will ich beispielsweise mit dem Hochleistungs-Drucksystem Kodak DigiSource 9110 eine fertige Broschüre erstellen, darf ich nicht die obere Ausgabe, sondern muss den Booklet-Maker anwählen.

Einige dieser Beschränkungen sind nicht unmittelbar sichtbar. Manche (fehlerhaften) PPDs lassen es beispielsweise zu, doppelseitige Folien-Drucke anzuwählen: was erstens nicht viel Sinn für den Leser macht, und - schlimmer - eine teure Reparatur nach sich ziehen kann, wenn die Folie sich im zweiten Durchlauf um die Laserdrucker-Heizwalze wickelt und anfängt zu schmelzen... Der Autor weiss aus eigener Erfahrung, dass auch dem Kundendienst-Techniker solche Sercice-Einsätze nicht den grössten Spass machen.
;-)

3.3 PostScript und Linux

PostScript ist in der Unix-/Linux-Welt das Standard-Format für druckbare Daten. (Ausser bei HP-UX?! Ich weiss es nicht. Wer kann mich aufklären?!). Selbst wenn sie letztendlich auf einem Nicht-PostScript-Drucker ausgegeben werden, nehmen sie oft einen »Umweg« über dieses Format, um anschliessend von dem allgegenwärtigen Ghostscript in das jeweilige druckerspezifische Format überführt zu werden.

Die zentrale Seitenbeschreibungsprache unter Linux ist PostScript. Beinahe jedes Programm, das druckbaren Output erzeugt, kann PostScript generieren. Und das allgegenwärtige Programm-Paket ghostscript sorgt dann dafür, dass über Filterprogramme aus dem vorliegenden PostScript genau das bestimmte Rasterformat erzeugt wird, das der angepeillte Drucker versteht. Ghostscript fungiert demzufolge als ein Software-RIP, das die zu druckende Datei für das Ausgabegerät aufbereitet.

Filterprogramme übernehmen unter Linux wie unter Unix eine den Druckertreibern unter Windows vergleichbare Aufgabe. Sie konvertieren Dateiformate. Die »marking engine« ist der Teil des Druckers, der für die Übertragung des Toners auf das Medium zuständig ist. Die marking engine versteht das Format nicht, das eine Anwendung wie etwa StarOffice verwendet. Sie erwartet die Datein in einem gerasterten Format. Plotter können mit ihren Stiften Linien zeichnen. Drucker machen Linien sichtbar, indem sie viele Punkte so dicht nebeneinander auf dem Papier anordnen, dass sie dem menschlichen Auge als Linie erscheinen. 

4. Die IPP-Implementierung durch CUPS

Das »Common Unix Printing System« (CUPS) ist im Quellcode verfügbar und unterliegt derselben Lizenz wie der Linux-Kernel: der GNU General Public License (GPL). Es ist die bereits am weitesten fortgeschrittene Implementierung des IPP.

CUPS läuft nicht nur auf Linux (ab Kernel 2.0, Intel, glibc), sondern auch auf mehreren wichtigen Unix-Spielarten:

  • Compaq Tru64 UNIX ab 4.0,
  • Digital UNIX® ab 4.0

  • HP-UX ab 10.20,
  • Silicon Graphics IRIX ab 5.3,
  • OSF/1 ab 4.0,
  • Sun Solaris ab 2.5 (Intel, SPARC)

4.1 PPDs - auch für Nicht-PostScript-Drucker!

CUPS kann mit PostScript-Druckern umgehen. All deren Optionen können voll und ganz angewählt und genutzt werden. Zum Ansteuern und Konfigurieren der PostScript-Drucker benutzt es PPD-Dateien. Diese Dateien, sogenannte »PostScript Printer Descriptions« (siehe oben), sind nach einer durch die Erfinder der PostScript-Sprache, der Firma Adobe, festgelegten Spezifikation aufgebaut. Eine PPD für einen bestimmten PostScript-Druckertyp beschreibt demnach die allgemeinen und besonderen Fähigkeiten eines bestimmten PostScript-Ausgabegeräts und auch, wie man dieses ansteuert. 

4.1.1 PostScript-Drucker - kein Problem

CUPS verwendet PPDs daher zunächst mal bei allen PostScript-Druckern. Die Beschaffung der richtigen PPD ist hier keine besondere Schwierigkeit. Für PostScript-Drucker liefert der Hersteller in der Regel fertige PPDs für die Mac- und Windows-Plattformen. Diese PPDs können unter Linux mit CUPS auf Punkt und Komma übernommen werden. CUPS kann sie problemlos verwenden, um alle Drucker-Optionen anzusprechen.

Auch Nicht-PostScript-Drucker können von CUPS über PPDs (siehe oben) angesteuert werden. -- Nanu? - Wie soll denn das funktionieren? Ganz einfach: indem die proprietären Drucker-Steuer-Signale oder z.B. PCL-Escape-Sequenzen in eine »Dummy«-PPD verpackt werden. ( - »Dummy«-PPD ist meine Ausdrucksweise für dieses Feature. Mir ist nichts anderes eingefallen. Aber eigentlich ist sie nicht korrekt. Die »Dummy«-PPDs werden ja nicht nur testweise verwendet. - ).

4.1.2 Nicht-PostScript-Drucker: woher die PPD nehmen?

Das Problem: es gibt derzeit noch nicht besonders viele PPDs für Nicht-PostScript-Drucker!

  • Die Hersteller dieser Drucker liefern bisher mit ihrem Produkten noch keine solchen »Dummy«-PPDs aus. Der Linux-Markt war für sie bisher noch nicht interessant genug.
  • andererseits ist CUPS noch zu unbekannt, als dass es von »Hackerseite« bereits eine grosse Sammlung solcher Dateien gäbe.

Beides könnte sich in nächster Zeit sehr schnell ändern.

4.1.3 Mit dem PPD-Schema können alle Hersteller ohne Schwierigkeiten Treiber für CUPS schreiben

Mit der Ausnutzung des PPD-Schemas hat CUPS einen beinahe genial zu nennenden Ansatz für die Lösung des Druckproblems gefunden. Damit liegt ein einheitliches Format zur Konfiguration und Kontrolle aller möglichen Typen von Druckern vor. Dies vereinfacht den Aufbau eines neuen Drucksystems für Unix und Linux erheblich (unabhängig vom neuen »Übertragungs«-Protokoll IPP). Es erleichtert die Einbindung aller möglichen Drucker in das System, da eine einheitliche Schnittstelle zum System vorliegt. 

Die Kunst besteht darin, funktionierende PPDs für Nicht-PostScript-Drucker zu schreiben, so dass alle Features des Druckers gleichermassen wie bei proprietären Windows-Treiber angewählt werden können.

In dem kommerziellen Paket ESP PrintPro (siehe unten), das eine grafische Benutzeroberfläche für CUPS liefert, sind derzeit über 2300 PPDs (= Druckertreiber für verschiedene Modelle) enthalten, davon über 1000 für Nicht-PostScript-Drucker. Wenn eine 3-Mann-Firma das für dutzende von Druckermarken hinkriegt, sollte es eigentlich für die Geräte-Hersteller keine Überforderung sein, CUPS-PPDs selbst zu schreiben. Oder, solange die Hersteller noch nicht spuren, sollte es leicht möglich sein, diesen Job in einem OpenSource-Projekt zusammenzufassen. Die Open Source-Bewegung hat schon Schwierigeres bewältigt. Aber das sagt einer, der vom Programmieren nicht viel Ahnung hat...
;-))

Prinzipiell ist dieser Ansatz äusserst elegant und müsste eigentlich zur sofortigen Nachahmung verlocken: einen zwar proprietären, aber veröffentlichten und allgemein akzeptierten Standard (nämlich die PPD-Spezifikation der Fa. Adobe) zu benutzen, um »Druckerbeschreibungsdateien« für jede Art von Druckern (und nicht nur für die ursprünglich gedachten PostScript-Typen) zu schreiben.

4.2 CUPS 1.1 - Design-Übersicht

Ich habe CUPS unter Linux (S.u.S.E. 6.1 bis 6.4) und Solaris 2.7 mit einer ganzen Reihe von Druckern verschiedener Hersteller äusserst erfolgreich eingesetzt. Eine Einschränkung ist zu machen: Alle Drucker waren PostScript-Drucker. Die zugehörigen PPDs beschaffte ich, indem ich sie von Windows-Rechner oder der zugehörigen Treiber-Installations-CD auf den CUPS-Rechner kopierte. Die Test-Systeme umfassten von einer Ricoh Aficio 180 (18 Seiten pro Minute) über einen Hewlett-Packard Mopier 320 (32ppm) und eine infotec 4651MF (65ppm) bis hin zu Kodak IS 70cpII (70ppm) und Heidelberg Digimaster 9110 (110ppm) bei schwarz-weiss-Geräten ebenso wie eine Reihe von Hochleistungs-Farbdruckern (infotec, Danka und Canon).

In den letzten Wochen habe ich CUPS in der brandaktuellen Version 1.1b3 getestet. Dies ist eine Beta-Version des kommenden CUPS 1.1. CUPS 1.1 wird viele Features des (noch nicht fertigen) IPP 1.1 implementieren. Wer CUPS auf seinem Rechner installiert, braucht keinen Line Printer Daemon mehr. Dessen Funktion wird von nun an vom CUPS-Daemon cupsd übernommen.

Abb. 2: Ein Blockdiagramm der wichtigsten CUPS-Komponenten

CUPS-Blockdiagramm mit Scheduler, Konfigurationsdateien, Filtern, Librarys und

Das Gesamt-Paket von CUPS besteht aus mehreren Hauptkomponenten, die jeweils unterschiedliche Aufgaben wahrnehmen. Es sind dies:

  • der »Scheduler«,
  • die Konfigurationsdateien,
  • diverse Filterprogramme,
  • die CUPS-Schnittstellen-Bibliothek (»Interface Library«),
  • die sogenannten »Backend Interfaces«, Schnittstellen zu den tatsächlichen physischen Druckgeräten
  • und die »Berkley und System V Commands«.

Der in der Dokumentation oder bei Rückmeldungen auf stderr auch als scheduler bezeichnete cupsd ist ein IPP-Server (und bei Bedarf auch ein IPP-Client). Als solcher kann er mit jedem anderen cupsd über das IPP kommunizieren und Druckdaten entgegennehmen oder auch weiterleiten.

Theoretisch sollte er in gleicher Weise mit IPP-Servern und -Clients anderer Hersteller »sprechen« können. Praktisch lässt sich das erst testen, wenn solche Implementierungen fertig sind.

Die Grund-Funktionen des CUPS-Schedulers entsprechen also zunächst einmal einem Druck-Spooling-System. Aber das ist noch nicht alles.

4.3 Der CUPS-»Scheduler«

Der Scheduler ist das CUPS-Herzstück. Er besteht aus einem HTTP-1.1- und IPP-1.1-Server- und -Client-Programm. Diese Doppelfunktion bedürfen näherer Betrachtung.

4.3.1 Der Scheduler als Print-Server

In seiner Rolle als Server bedient alle er IPP-Aufträge seiner Clients. Nach der Installation »sitzt« hinter dem IPP-Standard-Port 631. Dieser Port lässt sich bei Bedarf umstellen.

Der CUPS-Server nimmt nicht nur Druckaufträge entgegen, die via »IPP-POST« an ihn herangetragen werden. Er kann noch mehr.

4.3.2 Der Scheduler als HTTP-Server

Als vollwertiger Webserver stellt er Nutzern eine Online-Hilfe zur Verfügung. Es vermittelt die Status-Überwachung der Drucker-Warteschlangen. Informationen über laufende oder abgeschlossene Druckjobs liefert er an die Clients als HTML-Seite.

Prinzipiell ist er von jedem Punkt im Internet aus ansprechbar. Diese Erreichbarkeit ist natürlich abhängig von seiner eigenen Konfiguration sowie derjenigen einer etwa das LAN abschirmenden Firewall.

4.3.3 Der Scheduler und das »Browsing«

Der Scheduler gibt in seiner Funktion als Server im LAN per UDP-Broadcast bekannt, welche Drucker bei ihm verfügbar sind. In seiner Funktion als Client überwacht er andererseits das LAN auf Drucker-Informationen, die ihrerseits von anderen CUPS-Servern im LAN als Rundspruch gesendet werden. Diese Funktion wird auch als Browsing bezeichnet.

4.3.4 Der Scheduler als Print-Spooler

Und natürlich ist er für die Weitergabe der Druckaufträge an die Ausgabegeräte zuständig. Dabei muss er selbstverständlich dafür sorgen, dass die Daten zuvor die diversen Filter in der richtigen Reihenfolge durchlaufen. Anschliessend wählt er das korrekte Backend, damit der Druck beim richtigen Drucker erfolgt.

4.3.5 Der Scheduler und die CGI-Programme

Ein absoluter Clou sind die in der neuesten CUPS-Version verfügbaren CGI-Programme (Common Gateway Interfaces). Über diese Programme lassen sich vom (berechtigten) Nutzer per Browser nicht nur passive Statusabfragen durchführen. Er kann (auch aus der Ferne, über jeden Browser, von jeder Plattform aus) aktiv auf den CUPS-Server einwirken.

4.3.6 Der Scheduler als Werkzeug des Benutzers

Zu den gegenwärtigen Einwirkungsmöglichkeiten via CGI-Programmen gehören folgende Punkte:

  • Druckaufträge einsehen, anhalten und endgültig löschen;
  • Warteschlangen anhalten, neu starten, für Neuaufträge sperren, modifizieren, neuanlegen und löschen;
  • »Klassen« von Warteschlangen neuanlegen, modifizieren, löschen, anhalten, starten und sperren;

4.3.7 Der Scheduler und Drucker-»Klassen«

Eine Drucker-Klasse besteht aus einer (frei definierbaren) Gruppe von im Netz vorhandenen Druckern. Aufträge können an eine Drucker-Klasse anstelle eines direkt spezifizierten Druckers geschickt werden. In diesem Fall wird der zuerst verfügbare Drucker durch den Scheduler mit dem Auftrag beschickt. Das ist ganz praktisch: es erhöht die Ausfallsicherheit des Gesamtsystems.

4.3.8 Der Scheduler und Server-»Klassen«>

Mehrere CUPS-Server können zu einer ServerKlasse zusammengefasst werde. Aufträge können an über eine Server-Klasse anstelle eines direkt spezifizierten Servers geschickt und abgewickelt werden. Wird ein Druckjob an eine Server-Klasse geschickt, übernimmt der erst verfügbare Server die weitere Verabeitung.

Wenn auf verschiedenen Servern Drucker mit identischen Namen eingerichtet werden, bildet CUPS daraus eine implizite Klasse. Dies wird der schlaue Administrator natürlich ausnutzen, um die Ausfallsicherheit des Gesamtsystems zu erhöhen. Denn wenn dann der Standard-Server eines Benutzers mal streikt oder heruntergefahren ist, werden ohne Benutzer- oder Administrator-Eingriff die Jobs weiterhin ausgedruckt! Unter Umständen bemerkt er den Ausfall des ersten Servers überhaupt nicht, da ein zweiter aus derselben Klasse in die Bresche springt. Dieser druckt den Job mit nur wenigen Sekunden Verspätung auf dem ursprünglich gewählten Drucker aus...

4.3.9 Der Scheduler und Drucker-PPDs

Das grösste: alle in der verwendeten Drucker-PPD vorhandenen Druckereinstellungen lassen sich umkonfigurieren. Wenn man (lokal - oder remote, wenn die Berechtigungen entsprechend gesetzt sind), mit dem Browser auf den URI

  http://meinIPPserver:631/printers/

geht, sieht man eine Seite mit den verfügbaren Druckern. Ein CGI-Programm vermittelt den Zugriff auf die jeweilige Drucker-PPD. Dieses CGI-Programm ist über den Button Configure Printer auf der HTML-Seite zugänglich. In anderen Worten: wenn der Drucker doppelseitig drucken und Papier lochen kann, sind uns diese Optionen nicht mehr verwehrt, sondern voll und ganz nutzbar!

Ebenso ist jede andere Funktion des Druckers in Reichweite, die in der PPD korrekt festgehalten ist. Bei PostScript-Druckern kann die vom Hersteller für Windows- oder Mac-Betriebssysteme gelieferte PPD 1:1 übernommen werden - und der Drucker ist unter Linux genauso funktionsfähig und flexibel ansteuerbar wie unter Windows oder Mac. Dies eröffnet dem Linux-Benutzer erstmals dieselbe Freiheit und Vielfalt bei der Einstellung seiner Druckoptionen wie dem Mac- oder Windows-Anwender.

4.4 Die CUPS-Konfigurationsdateien

Die wichtigsten Konfigurations-Dateien sind folgende:

  • eine Konfigurationsdatei für den IPP-(=HTTP-)Server; 
  • Definitionsdateien für die vorhanden Drucker und Drucker-»Klassen«; 
  • MIME-Type- und MIME-Konversionsregel-Dateien; 
  • PostScript-Printer-Description-Dateien (PPDs). 

4.4.1 /etc/cups/cupsd.conf

Die Konfigurationsdatei für den HTTP-Server /etc/cups/cupsd.conf ist absichtlich ähnlich aufgebaut wie diejenige des Apache-Webservers. In ihr werden auch alle Zugangsberechtigungen zum Server definiert: wer darf drucken? wer darf administrieren?

4.4.2 /etc/cups/printers.conf

Die Drucker-Definitionsdatei /etc/cups/printers.conf listet alle verfügbaren Drucker auf. Zu jedem Drucker gehört ein URI. Der Drucker-URI bringt zum Ausdruck, über welches Protokoll und über welche Schnittstelle/Zieladresse (parallel, seriell, USB, HP JetDirect/AppSocket, Tektronix PhaserShare, Samba/SMB/CIFS, FTP oder gar IPP) der CUPS-Server mit dem physikalischen Drucker kommunizieren soll. In diese Datei schreiben auch das lpadmin-Kommando (siehe unten) und die CGI-Programme - etwa dann, wenn der Drucker umkonfiguriert wird.

4.4.3 /etc/cups/mime.types

Die MIME-Type-Datei /etc/cups/mime.types listet alle unterstützten MIME-Types auf (z.B. text/plain, application/postscript, application/pdf, application/vnd.hp-HPGL, image/gif, image/jpeg, image/png usw.). Ausserdem werden darin die magic rules festgehalten, die das »automagische« Feststellen des Dateiformates erlauben (unabhängig von der Endung, qse trägt!).

Der HTTP-Server wiederum verwendet diese MIME-Types, um das Content-Type-Feld in den GET- und HEAD-Anfragen festzulegen. Der IPP-Request-Handler benutzt sie, um den Dateityp zu bestimmen, wenn bei ihm eine Print-Job-Anfrage eintrifft, bei der das document-format auf application/octet-stream lautet. Jeder Filter ist mit einem fiktiven relativen »Kosten«-Faktor versehen. Bei verschiedenen Möglichkeiten verwendet der Filter-Algorithmus diejenige Filter-Verkettung, die die niedrigsten Gesamt-Kosten verursacht.

4.4.4 /etc/cups/mime.convs

Die Regeldatei für die MIME-Types-Konvertierung /etc/cups/mime.convs listet alle verfügbaren Filter auf. Sie werden ergänzt durch cupsFilter-Einträge in den Drucker-PPD-Dateien. Die zu druckende Datei durchläuft nacheinander die festgelegten Filter. Somit kann das Anwendungs-Programm, das drucken will, die Datei in einem ihr genehmen Format senden. Der Scheduler benutzt den Filter-Mechanismus, um die Datei in genau das Format umzuwandeln, das der Drucker haben will.

Die Dateien mime.cons und mime.types in /etc/cups/ dienen dazu, die richtigen Filter für die korrekte Umwandlung der zu druckenden Dateien in den dem Drucker verständlichen Rasterformat-Typ zu gewährleisten.

4.4.5 /etc/cups/ppd/1_infotec4700MF.ppd

PPD-Dateien beschreiben die Fähigkeiten des jeweils zugehörigen PostScript-Druckers. Es ist jeweils eine PPD-Datei pro Warteschlange und den entsprechenden physikalischen Drucker vorhanden. Die PPD-Dateien im Verzeichnis /etc/cups/ppd/ tragen den gleichen Namen wie der zugehörige Drucker, der in der Drucker-Konfigurationsdatei /etc/cups/printers.conf eingetragen ist.

Der Name des Druckers ist mit wenigen Einschränkungen (etwa Leerzeichen und Bindestriche) frei wählbar. Damit mein Lieblingsdrucker in der Browse-Liste ganz oben erscheint, habe ich seinen Namen mit einer führenden »1« versehen:

  1_infotec4851MF

Er steht in der alfabetisch sortierten Liste solange an erster Stelle, bis ein Kollege auf die Idee kommt, einen Druckernamen zu wählen, der mit »0« beginnt.

4.4.6 /etc/cups/clients.conf

Die /etc/cups/clients.conf legt bei mehreren im Netz verfügbaren CUPS-Servern clientseitig den Standard-Server und den Lieblingsdrucker fest. Wird beim Drucken kein bestimmtes Gerät angegeben, wird benutzt, was in der clients.conf steht.

4.4.7 /etc/cups/classes.conf

Die /etc/cups/classes.conf legt fest, welche Klasse(n) aus den vorhandenen CUPS-Servern gebildet werden. Durch »Klassen«-Bildung kann eine hohe Ausfallsicherheit für das Netzwerk-Drucksystem erreicht werden. Alle Drucker einer Klasse helfen sich gegenseitig aus, wenn einer ausfällt. Klassen lassen sich beliebig anlegen.

Drucker mit demselben Namen, die auf verschiedenen Servern residieren, bilden automatisch eine implizite Klasse (wenn in der cupsd.conf der Schalter auf ImplicitClasses On steht). Bei Ausfall des Standard-Servers springt ein anderer in die Bresche, der einen Drucker gleichen Namens in seiner /etc/cups/printer.conf führt. Er spoolt den Auftrag (bei richtiger Konfiguration) sogar zum ursprünglich gewählten Drucker. Der Anwender merkt eventuell gar nichts vom Ausfall des Servers.

4.5 Die CUPS-Server-Konfigurationsdatei näher betrachtet

Wer bereits einmal einen Apache-Webserver konfiguriert hat, wird sich auf Anhieb in der /etc/cups/cupsd.conf zurechtfinden. Die Konfiguration erfolgt zu 90 Prozent auf die gleiche Weise wie beim Apache, die restlichen zehn Prozent erschliessen sich dem Webmaster sofort. Ein williger Anfänger hat auch nicht besonders viel Mühe, jedenfalls deutlich weniger als mit der /etc/printcap des LPD ;-)

4.5.1 Bekannte Server-Direktiven

Die für die Server-Einstellungen benutzten Direktiven verwenden bekannte Schlüsselworte: Port, ServerName, MaxClients, ServerAdmin, AccessLog, ErrorLog, LogLevel, PageLog, MaxRequestSize, MaxLogSize, Timeout, KeepAlive, KeepAliveTimeout, DocumentRoot, Location sind in der conf-Datei in Kommentaren kurz erklärt und entsprechen der bekannten httpd.conf.

Über die Location /admin/ erfolgt der Browser-Zugriff auf die Verwaltung der Drucker-Warteschlangen (Starten, Stoppen, Anlegen und Löschen von Queues); über die Location /printers/ werden die einzelnen Drucker, über /jobs/ die Druckaufträge bekanntgegeben. Jede Location kann separat abgesichert werden, was den Zugriff betrifft.

4.5.2 Authentifizierung für Nutzer und Administratoren

Die Authentifizierung erfolgt in der derzeitigen Version nur über einen einzigen AuthType, und zwar über den AuthType Basic. Dieses ist die HTTP-Methode AuthType Basic. Demnächst wird zusätzlich Unterstützung für die HTTP-Digest-Authentifizierung eingebaut sein. Bei Basic kann jedoch über die AuthClass differenziert werden in:

  • Anonymous (jeder darf drucken, bzw. administrieren);
  • User (wer einen User-Account auf dem IPP-Server hat oder kennt, hat Zugriff auf die /printers/- oder /admin/-Location;
  • Group (wer zur spezifizierten Gruppe der Druckerbenutzer gehört, hat das Privileg..);
  • System (wer zur Gruppe root gehört, darf ran).

Einzig die Einstellung über AuthClass Anonymous erfordert kein Passwort; User, Group und System müssen sich mit dem jeweiligen Namen und Passwort authentifizieren.

Für jede Location lässt sich eine andere AuthClass einstellen. So ist es denkbar, für die Location /admin/ die AuthClass System einzutragen (dann dürfen nur privilgierte Nutzer administrieren) und für die Location /printers/ die AuthClass Anonymous zu verwenden (dann darf jeder drucken und zwar ohne Passwort).

4.5.3 Zugriffskontrollen beschränken Rechte

Zusätzlich lässt sich der Zugang zum CUPS-.Server natürlich auch noch über eine Liste von zulässigen (»Allow From ...«) und/oder verbotenen (»Deny From...«) Hosts beschränken: hier sind sowohl None, All, IP-Adressen, Subnetze, Domain- und Hostnamen (falls HostNameLookups auf On steht) in beliebigen Kombinationen (auch in Verbindung mit der *-Wildcard) per »Deny«- oder »Allow«-Direktive möglich. Über die jeweilige Zeile »Order Allow,Deny«; bzw. »Order Deny,Allow« wird die Reihenfolge der Auswertung dieser Direktiven gesteuert.

4.5.4 Empfehlung: AuthClass System für Admin-Zugriff

Es empfiehlt sich wärmstens, bei Mehrbenutzer-Systemen die Location /admin/ mit der AuthClass System abzusichern. Sonst ergeht es dem stolzen root wie dem Autor dieses Papiers vor kurzem: die auf das IPP neugierigen und verspielten Kollegen hatten übers Intranet alle funktionierenden Drucker lahmgelegt, gelöscht oder sonstwie unbrauchbar gemacht und dafür ca. 50 neue »Drucker« mit so phantasievollen Namen wie Karola, Max, Hansjoergs_Lieblingsdrucker, Papierschwärzer und Ersatzreisswolf angelegt... Immerhin: in unserem Hause ist jetzt ein gewisses Grundwissen über CUPS und das IPP vorhanden ;-)

4.5.5 »Browsing« stellt Drucker im Netz zur Verfügung

Wer in der zentralen Konfigurationsdatei Browsing On eingetragen hat (das ist nach der Installation voreingestellt), erlaubt es seinem CUPS-Daemon, die Informationen über die bei ihm installierten Drucker an alle anderen CUPS-Server im Netz mittels UDP in den per BrowseInterval eingestellten Sekundenabständen (Voreinstellung 30) an die BrowseAddress zu broadcasten. Diese merken sich diese Informationen so viele Sekunden lang, wie es in der BrowseTimeout-Direktive vermerkt ist (300 ist der Installations-Defaultwert).

Die voreingestellte BrowseAddress ist 255.255.255.255; diese lässt sich natürlich jederzeit auf z.B. das Subnetz 10.160.16.255 beschränken. Sind viele CUPS-Rechner im Netz, die alle einen oder mehrere Drucker eingerichtet haben, kann es ein ein wenig unübersichtlich werden. Wenn im Browser-Fenster alle Drucker auftauchen, sind diese sind alphabetisch geordnet. Drucker auf einenm entfernten Server sind mit einer Zusatz-Information versehen, an welchem CUPS-Server sie hängen. Die Information in der Form »Ersatzreisswolf@transmeta«, »deskjet@kurtsCUPSserver« wird jeder Nutzer richtig deuten können.

Das Browsing lässt sich bei zu vielen Servern im Netz natürlich auch abstellen (Direktive Browsing Off). Fortan kann man in Ruhe seine(n) lokal installierten Drucker nutzen.

4.6 Die CUPS-Filterprogramme

Die folgenden Filter werden bei der gegenwärtigen CUPS-Version mitgeliefert.

4.6.1 /usr/lib/cups/filter/hpgltops

Dateien im HP-GL/2-Format, wie sie Plotter verwenden, können von CUPS gedruckt werden. Wenn sie den hpgltops-Filter durchlaufen haben, ist aus ihnen PostScript geworden. Dann können sie eventuell bereits einem Backend zur Weiterleitung an einen echten PostScript-Drucker übergeben werden. Andernfalls muss ein weiterer Filter ran...

4.6.2 /usr/lib/cups/filter/imagetoraster

imagetoraster wird gebraucht, um beispielsweise JPEG-Bilder ohne einen Umweg über PostScript direkt an den Drucker zu schicken.

4.6.3 /usr/lib/cups/filter/imagetops

Wo der letzte Filter nicht verwendet werden kann, muss ein Umweg über PostScript gegangen werden. Hier kommt imagetops zum Zuge.

4.6.4 /usr/lib/cups/filter/pdftops

Wie der Name schon sagt: aus *.pdf mach' *.ps...

4.6.5 /usr/lib/cups/filter/pstops

Manchmal will ein Benutzer ein Vorliegendes PostScript-File nicht so ausdrucken, wie es vorliegt, sondern beispielsweise verkleinert, 2 Seiten auf 1 Blatt. Für diesen und ähnliche Zwecke kommt der pstops-Filter zum Einsatz.

4.6.6 /usr/lib/cups/filter/pstoraster

CUPS spannt bei Postscript-Eingabe das Ghostscript-Filterprogramm pstoraster vor seinen RIP-Karren, um die Druckdatei in das Druckerformat. umzuwandeln. Seit Version 1.1b2 wird GNU Ghostscript 5.50 verwendet.

4.6.7 /usr/lib/cups/filter/texttops

Liegt eine reine Textdatei vor und soll der Ausdruck etwas verschönert werden (Rahmen, Kopfzeile usw.) ist die Zeit für texttops reif.

4.7 Die CUPS Interface Library

Die CUPS Interface Library enthält CUPS-spezifische Bibliotheksfunktionen. Diese Funktionen steuern verschiedene Dinge:

  • Funktionen zur Beeinflussung von Jobs: Einreihen in Warteschlangen, Anhalten, Löschen usw.;
  • Funktionen zur Beeinflussung von Druckern (=Warteschlangen):starten, stoppen, löschen, anlegen usw.;
  • Funktionen für den Zugang zu Ressourcen via HTTP oder IPP;
  • Funktionen für die Erkennung der MIME-Types und zum Bewerkstelligen ihrer Format-Umwandlung;
  • Funktionen zum Editieren von PPD-Dateien (dadurch werden u.a. die default-Einstellungen eines Druckers gesteuert oder die Job-Optionen eines Druckauftrags festgelegt).

4.8 Die CUPS Backend Interfaces

Mit seinesgleichen unterhält sich der cupsd über das IPP. Was aber ist mit CUPS gewonnen, wenn ich ein Gerät habe, das noch kein IPP versteht? Keine Sorge. Zu den physikalischen Druckern spricht CUPS in verschiedenen Sprachen und über verschiedene Schnittstellen:

  • seriell, parallel, USB, Ethernet - 
  • über das LPR/LPD-Protokoll oder
  • HP JetDirect,
  • Tektronix PhaserShare,
  • FTP,
  • TFTP und natürlich
  • IPP...

Er kann sogar mit Samba-Hilfe über das Protokoll »Server Message Block« (SMB) mit Windows-Rechnern kommunizieren, entweder um deren Druckaufträge entgegenzunehmen oder den Druck bei einem unter Windows freigegebenen Drucker in Auftrag zu geben. (SMB ist das Standard-Kommunikations-Protokoll der MS-Windows-Rechner).IPP-Protokoll zwischen Client und Server - beliebiges Protokoll zwischen Server und Drucker.

Abb.3: IPP-Server und -Client unterhalten sich per IPP. Das Druckausgabe-Gerät wird vom Server so angesprochen, wie dieses es versteht: LPR/LPD, HP JetDirect usw.

CUPS bezeichnet diese unterschiedlichen Protokolle als backends. Es verwendet die Backends, um mit den Ausgabegeräten zu kommunizieren. Um Backends zu definieren wird auch für die klassischen Protokolle eine URI-ähnliche Syntax verwendet:

  backendmethode://[Benutzername:Passwort@]Hostname[:port]/[Ressource]

4.8.1 /usr/lib/cups/backend/http

Das http-Backend ist ein einfacher symbolischer Link auf das ipp-Backend. Er ist bei der Installation bereits vorhanden. Wenn in der nächsten Drucker-Generation das IPP zum Standard geworden ist, wird es das meist verwendete Backend sein.

4.8.2 /usr/lib/cups/backend/ipp

Heute (Mai 2000) können folgende Print Devices bereits per IPP angesprochen werden (Auswahl ohne Anspruch auf Vollständigkeit).

Kleine Printboxen oder Interne Server:

  • Axis: Printserver 5600, 5400, 660, 640;
  • Epson Net10Base und Net10/100Base Interne Printserver;
  • Extended Systems: PocketPro Printserver 100s,100x,100zx,100fx;
  • Hewlett-Packard: JetDirect 300X, 500X, 400N, 600N;
  • i-data: EasyCom 10/100Xpress PlusCom und Pro, LinkCom Eth0 10/100;
  • JCI: JetLAN 3100;
  • Lexmark: Mark Net Print Servers;
  • Tally: TallyCom+ (1-, 3- und 5-Port)

  • .

Drucker mit embedded IPP:

  • Epson: LP-1900N, LP-2400FX/FXN, LP-3600FX/FXN, EM-900CM;
  • Hewlett-Packard: Laserjets 8000/8100 und HP Mopier 240/320 mit der neuer Firmware;
  • IBM: infoprint color 8;
  • Ricoh: IPSiO NX910, imagio PrinterUnits Type V und Type T;
  • Tektronix: Color Serie Phaser 750 + 850;
  • Xerox: DocuPrint N Serie;

Die Device-URI für das IPP-Backend eines HP Mopiers lautet beispielsweise:

  • ipp://10.160.16.102/ipp/port1
  • ipp://HPmopy320/ipp/port1 (bei Namensauflösung)

4.8.3 /usr/lib/cups/backend/lpd

Drucker, die noch den klassischen LPD intus haben, wollen vom CUPS-Server mit folgender URI adressiert werden:

  • lpd://10.160.16.40/PORT1
  • lpd://1_infotec4700MF/PORT1 (bei Namensauflösung)

Achtung! In diesem Beispiel muss die Ressource PORT1 (grossgeschrieben) verwendet werden. Abhängig vom Hersteller und Modell des Druckers sind verschiedene Bezeichnungen für die Ressource erforderlich. Dies ist dem jeweiligen Drucker-Handbuch zu entnehmen.

Einige Beispiele:

  • Apple LaserWriter - »PASSTHRU«
  • Ricoh und infotec - »PORT1«
  • EFI Fiery RIP - »print_modelname«
  • Lexmark - »ps«

Manche Drucker - wie die HP Laserjets 8000/8100 oder Mopier 240/320 - vertragen Phantasiebezeichnungen wie »nudruckhaltschon«...

4.8.4 /usr/lib/cups/backend/socket

Wird als Kommunikationskanal zum Drucker das HP JetDirect-Protokoll verwendet, auch als AppSocket-Protokoll bekannt, muss als Ressource meist eine Portnummer von 9100 bis 9103 zum Einsatz kommen:

  • socket://hpjetdirectprinter:9100

Das zutreffende Handbuch gibt Auskunft!

4.8.5 /usr/lib/cups/backend/parallel

Ein Drucker an der zweiten parallelen Schnittstelle wird wie folgt konfiguriert:

  • parallel:/dev/lp1

(Die Schnittstellenzählung fängt bei »0» an...)

4.8.6 /usr/lib/cups/backend/serial

Bei seriell angeschlossenen Druckern (wer macht das heute noch?!) müssen die Anschluss-Parameter in die URI eingebettet werden:

  • serial:/dev/ttyS0?baud=4800+parity=odd+bits=7+flow=soft

Dieser Drucker ist am seriellen Port Nummer 1 angeschlossen, auf eine Baudrate von 4800 als Startwert eingestellt, mit ungerader Parität und Software-Flusskontrolle (XON/XOFF)... Die Parität kann die Werte none (keine), even (gerade) oder odd (ungerade) annehmen. Flusskontrolle kann hard (CTS/RTS Handshake) oder soft sein (XON/XOF-Handshake).

4.8.7 /usr/lib/cups/backend/usb

Tut mir leid, die USB-Konfiguration ist für mich noch ein Buch mit 7 Siegeln. Laut Dokumentation müsste es in die Richtung

  • usb:/dev/???

gehen. Aber ich weiss es leider nicht definitiv und habe es auch nicht versucht mit »Trial and Error« rauszukriegen...

4.8.8 /usr/lib/cups/backend/smb

Das Samba-Backend für CUPS ist bei der Installation noch nicht vorhanden. Es besteht eigentlich aus dem Utility smbspool, welches seit der Samba-Version 2.0.6 beim Samba-Paket mitgeliefert wird. Frühere Samba-Versionen funktionieren nicht mit CUPS. Damit das Backend eingerichtet ist, muss ein symbolischer Link von /usr/lib/cups/backend/smb nach smbspool gelegt werden. Da die Samba-Installationen auf verschiedenen Plattformen unterschiedlich abgelegt werden, muss dies beim Anlegen des Sym-Links berücksichtigt werden.

Dies wird mit folgendem Befehl erreicht:

  root@transmeta:~ > ln -s `which smbspool` /usr/lib/cups/backend/smb

Wichtig ist es, die Backticks richtig zu machen. Anschliessend sind alle Backends vorhanden:

  root@transmeta:/usr/lib/cups/backend > ls -l
  insgesamt 44
  lrwxrwxrwx 1 root  root     3 May  1 17:38 http -> ipp
  -r-xr-xr-x 1 root  root 11020 Apr 21 15:18 ipp
  -r-sr-x--- 1 root  root  8212 Apr 21 15:18 lpd
  -r-xr-xr-x 1 root  root  6032 Apr 21 15:18 parallel
  -r-xr-xr-x 1 root  root  5916 Apr 21 15:18 serial
  lrwxrwxrwx 1 root  root    17 May  7 16:38 smb -> /usr/bin/smbspool
  -r-xr-xr-x 1 root  root  5780 Apr 21 15:18 socket
  -r-xr-xr-x 1 root  root  6064 Apr 21 15:18 usb

Wenn Samba installiert und diser Link gesetzt ist, kann der CUPS-Rechner Drucker benutzen, die an einen Windows-Rechner angeschlossen und für andere Benutzer freigegeben sind:

  • smb://kurt:meingeheimwort@NTSERVER/druckerfreigabename

Um in die umgekehrte Richtung zu drucken, reicht seit Samba 2.0.6 ein klitzekleiner Eintrag in smb.conf, der zentralen Samba-Konfigurationsdatei:

  printing = cups

Alle anderen Einträge bezüglich der Druck- und Spoolbefehle in der smb.conf können entfallen...

4.8.9 Druck in eine Datei

Wenn CUPS einen Druckjob »in eine Datei« drucken soll, wird folgendes Quasi-Backend definiert:

  • file:/Pfad/zu/Dateiname

Ganz praktisch, wenn man bei der Fehlersuche sehen will, warum der PostScript-Header, den eine selbsteditierte PPD-Datei erzeugt hat, vom Drucker nicht akzeptiert wird...

4.9 Die Log-Dateien von CUPS

CUPS hat drei eigene Log-Dateien, um Zugriffe auf den CUPS-Server, Fehler und andere Meldungen und Daten zum Zwecke der Druck-Buchführung mitzuschreiben.

4.9.1 /var/log/cups/access_log

IPP- und HTTP-Zugriffe auf den CUPS-Server werden in /var/log/cups/access_log notiert. Festgehalten wird IP-Adresse des Clients (oder bei aktivierter Namensauflösung Hostname), Urheber (User-Name, falls nicht AuthClass Anonymous eingestellt ist), Status des Zugriffs, Zeit und genaues Ziel der Anfrage.

Das Format...

4.9.2 /var/log/cups/error_log

Je nach Einstellung in der cupsd.conf (debug, info, warn, error oder none) wird in /var/log/cups/error_log viel oder gar nichts vermerkt. Ein ausführliches Beispiel für einen Vorgang, der im Debug-Level mitge-logged wurde, folgt weiter unten.

4.9.3 /var/log/cups/page_log

In /var/log/cups/page_log laufen alle Informationen über die zu den einzelnen Druckern geschickten Jobs, die Seitenzahl, die Auflage, den Zeitpunkt, die Jobnummer und den Absender zusammen.

4.10 Die Berkeley- und SystemV-Kommandos

CUPS bringt Kommandozeilen-Schnittstellen mit, die in den wichtigsten Teilen kompatibel zu den beiden Hauptströmungen in der Unix-Welt sind: System V (AT&T) und Berkeley (BSD). Mit diesen Kommandos kann das Druck- und Spooling-System auf die gleiche Weise verwaltet werden, wie bisher gewohnt:

  • Jobs können geschickt, gestoppt, wiedergestartet, kontrolliert, werden.gelöscht und umsortiert werden.
  • Drucker (=Warteschlangen) können neu angelegt, modifiziert, gestoppt, gestartet, gesperrt und gelöscht werden.
  • Der gesamte CUPS-Daemon kann von der Kommandozeile aus konfiguriert werden.

Für alle Kommandos sind kurze man pages vorhanden.

4.10.1 /usr/sbin/lpc und /usr/bin/lpstat

4.10.2 /usr/bin/lpr und /usr/bin/lp

4.10.3 /usr/bin/lprm und /usr/bin/lpq

4.10.4 /usr/bin/lpadmin

4.11 Drucker einrichten per Kommandozeile

Um einen Drucker hinzuzufügen, wird das lpadmin-Kommando mit der »-p«-Option benutzt. Die allgemeine Form für diesen Befehl lautet:

    root@transmeta:~ > /usr/sbin/lpadmin -p printer -E -v device -P ppd ENTER

Leerzeichen zwischen dem Optionsbuchstaben und dem Optionswert sind optional. Das Kommando könnte also auch lauten:

    root@transmeta:~ > /usr/sbin/lpadmin -pprinter -E -vdevice -Pppd ENTER

Der Druckername printer (der mit der Option »-p« festgelegt wird) kann bis zu 127 Buchstaben, Zahlen und Underscores enthalten (keine Leerzeichen!). Allerdings ist er nicht case sensitive, also können keine zwei Namen wie z.B. LaserJet und laserjet benutzt werden!

4.11.1 Drucker konfigurieren mit /usr/bin/lpadmin

Mit lpadmin werden Drucker angelegt und konfiguriert. Jeder Drucker braucht eine PPD. Für PostScript-Drucker kann die PPD verwendet werden, die der Hersteller für die Verwendung bei Mac und MS-Windows vorgesehen hatte. Der Pfad zu der verwendeten PPD wird mit der Option -P angegeben. Erfolgt keine PPD-Pfad-Angabe, wird eine Generic PostScript Printer angelegt.
Durch man lpadmin sind weitere Details in Erfahrung zu bringen. Der Befehl lautet in allgemeiner Form (in einer Zeile eingeben, ohne die Backslashs!):

  lpadmin [-h CUPSserverName] -p druckername\

    -v device-URI -L "Standortbeschreibung" -D "Drucker-Info"\

      -E -p /Pfad/zu/printer.ppd

Die Option -h ist nur erforderlich, wenn es mehrere CUPS-Server im Netz gibt. Sie wird verwendet, wenn ein Printer auf einem anderen als dem default server eingerichtet wird. Die Option -E ist wichtig: sie enabled den Drucker sofort und öffnet die Queue, damit sie Jobs akzeptiert. Optionen -L und -D können weggelassen werden. Ich kopiere via Samba alle PPD-Dateien, die ich auf einem unserer Windows-Demoraum-Rechner gefunden habe, in den Ordner /open/ppd/ des Linux-CUPS-Servers.

Starten wir einige Versuch (Eingaben jeweils in 1 Zeile, ohne Backslashs), zuerst als root:

root@transmeta:/home/kurt >  lpadmin  -p Testdrucker_enabled_mit_Details\

                              -v lpd://10.160.16.126/PORT1\

                               -L "Das Schmuckstueck steht neben Kurts Schreibtisch"\

                                -D "Es ist ein Super-duper-Teil, eeeehrlich...!"\

                                 -E\

                                  -p /open/PPD/INFNH703.PPD

Als Backend wird hier der normale LPD eingespannt. Je nach Konfiguration wird man jetzt nach dem UNIX password gefragt. Und weil's so schön war, gleich nochmals, diesmal aber als normaler Benutzer kurt:

kurt@transmeta:~ > /usr/sbin/lpadmin  -p Testdrucker_nichtenabled_ohne_Details\

                    -v ipp://10.160.16.102/ipp/port1\

                     -p /open/PPD/HP8000_6.PPD

Als Backend verwende ich hier das IPP. Denn hinter der genannten IP-Adresse verbirgt sich ein neuer HP Laserjet. Da das lpadmin-Kommando nicht im normalen Benutzerpfad steht, muss es mit kompletter Pfadangabe eingegeben werden. Hier ist ebenfalls nach einem Passwort gefragt. Wer nicht zur Drucker-Administration berechtigt ist, wird abgelehnt.

4.11.2 Was lpadmin in die /etc/cups/printes.conf schreibt

Was ist passiert? Die Kommandos haben Einträge vorgenommen in der /etc/cups/printers.conf. Zum zweiten wurden die gewählten PPDs von /open/PPD/ nach /etc/cups/ppd/ kopiert und dort umbenannt nach Testdrucker_enabled_mit_Details.ppd bzw. Testdrucker_nichtenabled_ohne_Details.ppd. Durch diese Namensgleichheit zwischen verwendeter PPD und Drucker ist auf einfache Weise die richtige Verbindung hergestellt.
Schauen wir die /etc/cups/printers.conf an, wie sie nach diesen Befehlen aussieht. (Leerzeilen und Einrückungen sind zur besseren Übersicht von mir eingefügt):

  
  <DefaultPrinter 1_infotec4700MF>
    Location System-Support
    DeviceURI lpd://10.160.16.126/PORT1
    State Idle
    Accepting Yes
    JobSheets none none
  </Printer>
  
  <Printer Testdrucker_enabled_mit_Details>
    Info Es ist ein Super-duper-Teil, eeeehrlich...
    Location Das Schmuckstueck steht neben Kurts Schreibtisch
    DeviceURI lpd://10.160.16.126/PORT1
    State Idle
    StateMessage
    Accepting yes
    JobSheets none none
  </Printer>
  
  <Printer Testdrucker_nichtenabled_ohne_Details>
    Location
    DeviceURI ipp://10.160.16.102/ipp/port1
    State Stopped
    StateMessage
    Accepting No
    JobSheets none none
  </Printer>

4.11.3 Drucker und System kontrollieren mit /usr/bin/lpstat

Da beim zweiten Beispiel die Option -E (enable) weggelassen wurde, ist der Drucker im State Stopped und die Queue auf Accepting No.
Root kann sich mit lpstat -p Informationen über all Drucker anzeigen lassen:

  root@transmeta:/home/kurt > lpstat -p
  printer 1_infotec4700MF is idle.
  printer 320lokal@10.160.16.55 disabled -
          reason unknown
  printer mop_IPP@10.160.16.55 is idle.
  printer Mopier@10.160.16.55 disabled -
          reason unknown
  printer Testdrucker_mit_Details is idle.
  printer Testdrucker_nichtenabled_ohne_Details disabled -
          reason unknown

Die verfuegbaren Drucker an dem entfernten CUPS-Server 10.160.16.55 werden ebenfalls angezeigt. Der lokale CUPS-Daemon hat über das Browsing von ihnen erfahren. Statusinformationen über das komplette System sind mit der Option -t (=total) zugänglich:

  root@transmeta:/home/kurt > lpstat -t
  scheduler is running
  system default destination: 1_infotec4700MF
  device for 1_infotec4700MF: lpd://10.160.16.126/PORT1
  device for 320lokal@10.160.16.55: /dev/null
  device for mop_IPP@10.160.16.55: /dev/null
  device for Mopier@10.160.16.55: /dev/null
  device for Testdrucker_mit_Details: lpd://10.160.16.126/PORT1
  device for Testdrucker_nichtenabled_ohne_Details: ipp://10.160.16.102:631/ipp/port1
  1_infotec4700MF
  320lokal@10.160.16.55 not accepting requests -
          reason unknown
  mop_IPP@10.160.16.55 now printing 1_infotec4700MF-238.
  Mopier@10.160.16.55 not accepting requests -
          Print file accepted - job ID 1.
  Testdrucker_mit_Details accepting requests
  Testdrucker_nichtenabled_ohne_Details not accepting requests -
          reason unknown
  printer 1_infotec4700MF is idle.
  printer 320lokal@10.160.16.55 disabled -
          reason unknown
  printer mop_IPP@10.160.16.55 is idle.
  printer Mopier@10.160.16.55 disabled -
          Print file accepted - job ID 1.
  printer Testdrucker_mit_Details disabled -
          Wegen Elektro-Arbeiten ist der Drucker z.Zt. ausgeschaltet!
  printer Testdrucker_nichtenabled_ohne_Details disabled -
          reason unknown

4.11.4 Beispiel für eine /etc/cups/printers.conf

Hier ein Beispiel für eine /etc/cups/printers.conf, in der Drucker mit den anderen möglichen Backends angelegt sind (leicht umformatiert):

 <Printer 4700MF_SMB>
   Location Hansjoergs Schreibtisch
   DeviceURI smb://SYSTEMSUPPORT/turbo/4700samba
   State Idle
   StateMessage
   Accepting Yes
   JobSheets none none
 </Printer>
 
 <Printer DANKA_C2000_VOLLFARBE_31SeitenProMinute>
   Location Linuxtag 2000, Danka Document Print Center
   DeviceURI parallel:/dev/lp0
   State Stopped
   StateMessage Wegen Elektro-Arbeiten ist der Drucker z.Zt. ausgeschaltet!
   Accepting No
   JobSheets none none
 </Printer>

 <Printer Digimaster9110>
   Location HV-DemoRaum
   DeviceURI serial:/dev/ttyS3?baud=38400+parity=even+bits=7+flow=hard
   State Idle
   StateMessage
   Accepting Yes
   JobSheets none none
 </Printer>

 <Printer HP-Mopier240>
   Location Kurts Schreibtisch: wg. Tests mit Linux-Drucken mittels CUPS.
   DeviceURI http://mopier240:631/ipp/port1
   State Idle
    StateMessage
   Accepting Yes
   JobSheets none none
 </Printer>

 <Printer HPColorLaserJet4500>
   Location Demo-Raum
   DeviceURI socket://10.160.16.216:9100
   State Idle
   StateMessage
   Accepting Yes
   JobSheets none none
 </Printer>

Anmerkung: Die Konfiguration mit einem seriellen Anschluss wurde nicht getestet, die mit einem parallelen nur wenig.

4.11.5 Beispiele für CUPS-Befehle von der Kommando-Zeile

CUPS (und auch ESP PrintPro, siehe Abschnitt 5) ermöglichen sowohl die SystemV- (»lp«) als auch die Berkeley-Druckbefehle (»lpr«). Um auf den Standard- oder einzigen Drucker des Systems zu drucken, sind folgende beiden Kommandoversionen möglich:

   kurt@transmeta:~ > lp (/Pfad/zu/)Dateiname ENTER
   kurt@transmeta:~ > lpr (/Pfad/zu/)Dateiname ENTER

Wenn ein Drucker namentlich spezifiziert werden soll, muss es folgendermassen geschehen:

   kurt@transmeta:~ > lp -d printername (/Pfad/zu/)Dateiname ENTER
   kurt@transmeta:~ > lpr -P printername (/Pfad/zu/)Dateiname ENTER

Beim »lp«-Kommando steht »-d« für destination, bei lpr steht »-P« für Printer. Weitere Beispielkommandos sind in Listing 2 erläutert.

    root@transmeta:/home/kurt > lpadmin -p 4700SMB -E \

                -v smb://Administrator:geheim@SYSTEMSUPPORT/turbo/4700samba
    root@transmeta:/home/kurt > lpadmin -p 4700SMB -E \

                -v smb:\\\\Administrator:geheim@SYSTEMSUPPORT\\turbo\\4700samba

Diese beiden Kommandos sind gleichwertig; im zweiten Fall dient jeder zweite Backslash der »Maskierung« des anderen. Es wird ein Drucker namens »4700SMB« eingerichtet, per »-E« sofort »enabled« (=gestartet); er wird über Samba (»-v smb«) angesprochen, da es ein Drucker ist, der in der Arbeitsgruppe »Systemsupport« am NT-Rechner »turbo« über den Freigabenamen »4700samba« verfügbar ist, jedoch nur für den dortigen Benutzer »Administrator«, dessen NT-Passwort »geheim« lautet...

    root@transmeta:/home/kurt > lpadmin -p infotec4700MF -v lpd://infotec4700MF/PORT1

Hiermit wird ein Drucker namens »infotec4700MF« eingerichtet; benutzt wird er als LPR/LPD-Printer, dessen hostname »infotec4700MF« in diesem Falle in der /etc/hosts oder über DNS aufgelöst werden muss in die richtige IP-Adresse; er muss (in diesem Falle herstellerspezifisch) über den Queue-Namen »PORT1« adressiert werden. (andere, häufige Queue-Bezeichnungen sind »PASSTHRU« (Apple Laser Writer), »ps« (QMS), »9100« (HP JetDirect), »print_xyz« (EFI Fiery RIPs), »pr1«, »pr2« usw. (diverse Printboxen).

    root@transmeta:/home/kurt > lpadmin -p infotec4700MF -v lpd://10.160.16.126/PORT1

Wie oben, jedoch wird keine Namensauflösung benötigt, da die IP-Adresse direkt eingesetzt wurde.

    root@transmeta:/home/kurt > /etc/software/init.d/cups restart

Neustart des CUPS-daemon nach einer manuellen Umkonfiguration der Datei /etc/cups/cups.conf.

    root@transmeta:/home/kurt > lpadmin -d infotec4700MF

Erklärt den Drucker »infotec4700MF« ab sofort zum Standard-Drucker (»-d« = default). Dieser wird anschliessend von den Druckbefehlen »lp« bzw. »lpr« verwendet, wenn kein anderer Drucker (über die Optionen »-d« für lp bzw. »-p« für lpr) ausdrücklich spezifiziert wurde.

    root@transmeta:/home/kurt > lpadmin -p infotec4700MF \\ 

                -v file://tmp/PostScriptHeaderTest4700

Jedes Druckfile für den Drucker »infotec4700MF« landet ab sofort in der Datei »/tmp/PostScriptHeaderTest4700«, wo es auf PostScript-Fehler analysiert werden kann.

    kurt@transmeta:~ > glp -d Digimaster9110

Das GUI wird aufgerufen und hat als »destination« (»-d«) bereits den Drucker »Digimaster9110« markiert. Es muss über den Auswahldialog noch die zu druckende Datei ausgewählt werden.

    kurt@transmeta:~ > glp -d infotec4700MF /etc/hosts

Wie oben, jedoch ist bereits die zu druckende Datei /etc/hosts ausgewählt und der Drucker ist diesmal infotec4700MF.

    root@transmeta:/home/kurt >lpadmin -x RicohAficio650

Der Drucker »RicohAficio650« wird gelöscht.

    root@transmeta:/home/kurt > reject \\ 

        -r "Gerät wegen Elektro-Installationsarbeiten nicht verfügbar..." infotec4700MF

Für den Drucker »infotec4700MF« werden ab sofort keine Aufträge mehr angenommen, der Grund wird den Benutzern mit der Option »-r« (»reason«) mitgeteilt...

    kurt@transmeta:/home/kurt > lpstat

Zeigt die eigenen, in Verarbeitung befindlichen Jobs an, in der Reihenfolge wie sie gedruckt werden sollen.

    kurt@transmeta:/home/kurt > lpstat -p

Zeigt die Drucker und ihren momentanen Status.

    root@transmeta:/home/kurt >  /usr/bin/disable Digimaster9110
    root@transmeta:/home/kurt >  /usr/bin/enable Digimaster9110

Stoppt bzw. startet die Druckerwarteschlange für den Drucker Digimaster9110 . Ein Drucker kann gestoppt werden, jedoch kann seine Warteschlange trotzdem weitere Jobs akzeptieren. Die Warteschlange kann neue Jobs zurückweisen, während der Drucker weiterhin wartende Aufträge abarbeitet.

    root@transmeta:/home/kurt >  /usr/sbin/reject Digimaster9110
    root@transmeta:/home/kurt >  /usr/sbin/accept Digimaster9110

Lehnt weitere Druckjobs für die Druckerwarteschlange Digimaster9110 ab, bzw. nimmt sie wieder an. Ein Drucker kann gestoppt sein, jedoch kann die Warteschlange trotzdem weitere Jobs akzeptieren. Die Warteschlange kann neue Jobs zurückweisen, während der Drucker weiterhin wartende Aufträge abarbeitet.

    kurt@transmeta:/home/kurt > cancel JOB-ID

Löscht einen eigenen, in Verarbeitung befindlichen Jobs. Die JOB-ID ist so zu benutzen, wie sie durch das lpstat-Kommando ausgegeben wird.

4.12 Verschiedene Back-Ends in Benutzung

  
  [...to be done...]
  

4.13 Drucken per Kommandozeile

  
  [...to be done...]
  

4.14 Zugang über den Web-Browser

  
  [...to be completed...]
  
Abb. 4: Seit neuestem können CUPS-Drucker über einen beliebigen Browser administriert werden: Einträge für installierte Zusatzausstattungen, Default-Einstellungen für beliebige Optionen, usw. sind möglich. Der URI zu dieser Funktion lautet: http://10.160.16.40:631/admin/?op=config-printer&printer_name=1_infotec4651MF."

Seit neuestem können CUPS-Drucker über einen beliebigen Browser administriert werden.

4.15 Die versteckte Datei ~/.lpoptions

  
  [...to be done...]
  

4.16 CUPS und Ghostscript

  
  [...to be done...]
  

5. ESP PrintPro - grafische Benutzoberfläche für CUPS

  
  [...to be done...]
  
Abb. 5: Ausschnitte aus verschiedenen GUI-Fenstern für ESP PrintPro.

5.1 Installation und Lizenzierung

  
  [...to be done...]
  

5.1.1 Derzeit über 2300 Druckertreiber

  
  [...to be done...]
  
Abb. 6: ESP PrintPro liefert derzeit Treiber fü über 2300 Drucker-Modelle.

5.1.2 ESP PrintPro als CUPS-Server besonders ausfallsicher

  
  [...to be done...]
  

5.2 Grafisches User Interface (GUI)

  
  [...to be done...]
  

5.2.1 Der Printer Wizard

  
  [...to be done...]
  
Abb. 7: Printer Wizard-Fenster zur Auswahl des geeigneten »Backends«

5.2.2 Der Printer Manager

  
  [...to be done...]
  
Abb. 8: Printer Manager-Fenster mit Browse-Liste aller verfügbaren Geräte. Hier können Drucker und Drucker-Klassen hinzugefü gelöscht; modifiziert, gestoppt, gestrtet und getestet werden.

5.2.3 Der Print-Panel

  
  [...to be done...]
  
Abb. 9: Printer Panel-Fenster mit Liste aller verfügbaren Drucker. Über den Button »More Options« sind alle Job-Einstellungen erreichbar.

5.2.4 Die PrintPro-Kommandozeile

  
  [...to be done...]
  

Die Kommandozeilen-Befehle von ESP PrintPro gleichen genau denjenigen von CUPS. Es gibt allerdings ein extra Schmankerl: der Befehl /usr/bin/glpoptions.

6. CUPS und ESP PrintPro in praktischer Erprobung

Wenn man sein bisheriges Druck- und Spoolsystem auf ein völlig anderes umstellen soll, treten sicherlich viele Fragen und Zweifel ob diesen Schrittes auf.

6.1 Zuviel Netzlast durch »Browsing«?

In unserer Stuttgarter Linux User Group Mailingliste wurden vor einiger Zeit Befürchtungen geäussert, das Printer-Broadcasting durch die CUPS-Server könnte zu einer erheblichen Netzbelastung führen. Mit dem Protokoll-Analysator ethereal unternahm ich Versuche, dem Netzverkehr nachzugehen. Dabei stellte sich heraus, dass bei den Broadcasts nur Datagramme von ca. 100 Byte pro Drucker verschickt werden. Diese beinhalten nur die URI des Druckers in der Form ipp://kurtsCUPSserver/infotec4700MF

Im Vergleich zu dem Lärm, den diverse MS-Windows-Rechner auf dem Draht veranstalten, wenn sie ihre Master-Browser-Wahlen abhalten, ist das nicht besonders viel. Erst wenn ein Client drucken will, kriegt er vom CUPS-Server die PPD (PostScript Printer Description-Datei, siehe weiter unten) übers Netz zugeschickt.

Meine grösste verwendete PPD hat knapp 100kB. Das anschliessend an den Drucker geschickte PostScript-File umfasst durchschnittlich 2.000 - 10.000 kB, häufig auch mehrere 100.000 kB (bei farbigen Druckjobs z.B.). Somit relativiert sich das Problem doch ziemlich...

Ausserdem lässt sich das Browsing jederzeit abstellen, wenn es nicht erwünscht ist. Dann ist der CUPS-»Server« nur noch für die lokalen Druckaufträge zuständig. Wer ein Netz zusammenstöpselt, muss mit Netzverkehr rechnen. Wer CUPS als Netzwerk-Server laufen lässt, muss Browsing in Kauf nehmen.
;-)

6.2 Installation von ESP PrintPro 4.1b3 auf S.u.S.E 6.4

Auspacken

Nach dem erfolgreichen Herunterladen liegt jetzt die in meinem Fall genau 4.452.579 Byte grosse gepackte (»tar«) und komprimierte (»gz«) Datei mit der Basis-Software in meinem gewählten Download-Verzeichnis vor. Diese gilt es zuerst mal auszupacken. Wir gehen also, wie auf der ESP-Web-Seite beschrieben, dorthin (»cd«), schlüpfen in die Rolle des Super-Users (»su«), geben auf Nachfrage dessen Passwort ein und fangen an: zuerst dekomprimieren (»gunzip«), dann auspacken (»tar«), wie von ESP empfohlen:

   kurt@transmeta:/opt > cd ~/Downloads/
   kurt@transmeta:~/Downloads > su
   Kennwort:
   root@transmeta:/home/kurt/Downloads > gunzip printpro-4.1b3.tar.gz
   root@transmeta:/home/kurt/Downloads > tar xvf printpro-4.1b3.tar

Der letzte Befehl (»tar«) hat uns die aus der .tar.gz (gepackt und komprimiert) entstandene Archiv-Datei .tar (gepackt, aber unkomprimiert jetzt 7.613.440 Bytes gross) vollends ausgepackt und eine Reihe von Dateien beschert. Die im ersten Schritt erzeugte Archiv-Datei printpro-4.1b3.tar ist an die Stelle der .tar.gz getreten und nimmt entsprechend mehr Platz weg. Der tar-Befehl mit den Schaltern xvf extrahiert (»x«) das genannte file (»f«) und gibt voll ausführliche Rückmeldungen (»v«) auf die Konsole.

Wir können das End-Ergebnis der letzten beiden Befehle auch auf einen Rutsch folgendermassen erzeugen:

   root@transmeta:/home/kurt/Downloads > tar xvfz printpro-4.1b3.tar.gz
   printpro.install
   printpro.license
   printpro.readme
   printpro.remove
   printpro.ss
   printpro.sw
   setup
   setup.xpm

Die Optionen xvf haben, wie gehabt, alles extrahiert und rückgemeldet, das zusätzliche z jedoch hat uns die komprimierte Datei im Originalzustand belassen und somit gegenüber der durch die erste Methode entstandenen .tar 2,7 MB Platz gespart. Wir haben jetzt in diesem Verzeichnis die originale .tar.gz-Datei sowie insgesamt 8 zusätzliche neue Dateien.

Installation
Eine davon ist ein Shell-Script, welches wir aufrufen:

   root@transmeta:/home/kurt/Downloads > ./printpro.install

Und dann geht's auch schon los...

   Copyright 1993-1999 by Easy Software Products, All Rights Reserved.
   This installation script will install the ESP PrintPro
   software version 4.1b3 on your system.
   Do you wish to continue?

»y« für yes und ENTER lassen die erste Seite des Software License Agreement for ESP PrintPro auf den Schirm scrollen, mit der Leertaste geht's weiter, bis am Ende die Frage

   Do you agree with the terms of this license? y

wieder mit einem »y« beantwortet wird, worauf folgende Meldungen über den Monitor huschen:

   Backing up old versions of non-shared files to be installed...
   Backing up old versions of shared files to be installed...
   Creating installation directories...
   Installing software...
   Checking configuration files...
   Setting up init scripts...
   cups: scheduler started.
   Installation is complete.
   root@transmeta:/home/kurt/Downloads >

Ich habe es gestoppt: nachdem der Download beendet war, hat es bei mir reine 26 Sekunden gedauert, um das komplette alte Drucksystem auszutauschen (na ja, ich geb's ja zu: ich habe etwas geschummelt und die Lizenzbedingungen überhaupt nicht gelesen, und auch nicht alle Befehle ausgetippt, sondern die »Tab«-Taste zur Kommandozeilen-Ergänzung eingesetzt...;-). Hierbei wurde mein komplettes bestehendes Drucksystem (das SuSE-YaST-Paket lprold) zuverlässig gesichert mitsamt der von mir in mühsamer Handarbeit erzeugten /etc/printcap, welche in meinem Fall 35 konfigurierte und funktionierende Netzwerk-Drucker enthielt.

Backup!
Das war eigentlich ziemlich leichtsinnig von mir. Denn als ich PrintPro in der Version 4.0.1 zum ersten Mal testete, bereits drei oder vier Drucker erfolgreich eingebunden hatte und an einer Stelle nicht klar kam, de-installierte ich in meiner Verzweiflung wieder alles. Erst da fiel mir auf, dass das Installationsprogramm eine völlig neue /etc/printcap angelegt hatte, welche mit meiner bisherigen rein gar nichts zu tun hatte. Diese »Dummy«-printcap ist unter CUPS für diejenigen Anwendungen zuständig, die auf eine /etc/printcap angewiesen sind, um zu funktionieren (z.B. die meisten KDE-Programme wie KLpq oder KView). Meine »neue« printcap sah so aus:

   kurt@transmeta:/home/kurt > less /etc/printcap
   4220MF:
   infotec4700MF:
   4700SMB:
   DANKA_C2000_VOLLFARBE_31SeitenProMinute:
   Digimaster9110:
   HitachiDDP70_1:
   HP-Mopier240:
   HPColorLaserJet4500:
   HPColorLaserJet8500:
   HPMopier320:
   infotec4180:
   is70:
   RicohAficio180PS:

usw.usf. Das konnte ja heiter werden! Mein schönes funktionierendes, mühsam eingerichtetes, bisheriges Druck-System dahin... Aber siehe da: unter der Bezeichnung printcap.O war meine alte Konfigurationsdatei von der ESP-Installationsroutine gesichert worden. PrintPro und CUPS sind selbst nicht mehr auf eine »printcap« angewiesen. Sie legen aber aus o.a. Gründen eine Dummy-printcap an... Es ist in jedem Falle ratsam, »von Hand« eine Sicherung der bisher funktionierenden Druck-Konfigurationsdateien anzulegen. Ich weiss nicht, ob unter anderen Verhältnissen oder Distributionen (anderes Drucksystem bereits vorhanden, z.B. Lprng, PLP, PPR,...) das automatische Backup durch das PrintPro-Installations-Script genauso zuverlässig funktioniert wie bei mir.

De-Installation...
Die De-Installation lief erstaunlich komfortabel ab. Im bereits bekannten Verzeichnis /home/kurt/Downloads/ rief ich das »weg-damit!«-Script auf, um folgende Meldungen vorbeihuschen zu sehen:

   root@transmeta:/home/kurt/Downloads > ./printpro.remove
   Copyright 1993-1999 by Easy Software Products, All Rights Reserved.
   This removal script will remove the ESP PrintPro
   software version 4.1b3 from your system.

   Do you wish to continue? y
   cups: scheduler stopped.
   Cleaning up init scripts...
   Removing/restoring installed files...
   Removal is complete.

(War in 22 Sekunden erledigt, nur falls jemand fragt ;-) Gleich mal nachgeschaut, ob meine alte /etc/printcap noch da ist: alles OK, sie hat sogar ihren richtigen Namen wieder erhalten. Kann ich auch noch drucken wie früher?

   lpr -P4700MF /etc/hosts

Ja, geht, der Drucker nebenan surrt los. (Der Befehl druckt per Kommandozeilen-Befehl die /etc/hosts auf den Drucker 4700MF aus. Man beachte: dieser Drucker hatte in der alten printcap einen anderen Namen als unter CUPS). Und mein inzwischen geliebtes a2ps?

   a2ps -Pis70sys -n 3 --header="Dies ist ein Test!" /etc/smb.conf

Ebenfalls OK. Der Drucker is70sys heult auf. Das Ascii-nach-Postscript-Umwandlungstool funktioniert noch und die Drucker lassen sich auch wieder unter ihren bisherigen Bezeichnungen ansprechen. Nochmals gutgegangen! Die De-Installation lief erstaunlich komfortabel ab. Im bereits bekannten Verzeichnis /home/kurt/Downloads/ rief ich das »weg-damit!«-Script auf, um folgende Meldungen vorbeihuschen zu sehen:

   root@transmeta:/home/kurt/Downloads > ./printpro.remove
   Copyright 1993-1999 by Easy Software Products, All Rights Reserved.
   This removal script will remove the ESP PrintPro
   software version 4.1b3 from your system.

   Do you wish to continue? y
   cups: scheduler stopped.
   Cleaning up init scripts...
   Removing/restoring installed files...
   Removal is complete.

(War in 22 Sekunden erledigt, nur falls jemand fragt ;-) Gleich mal nachgeschaut, ob meine alte /etc/printcap noch da ist: alles OK, sie hat sogar ihren richtigen Namen wieder erhalten. Kann ich auch noch drucken wie früher?

   lpr -P4700MF /etc/hosts

Ja, geht, der Drucker nebenan surrt los. (Der Befehl druckt per Kommandozeilen-Befehl die /etc/hosts auf den Drucker 4700MF aus. Man beachte: dieser Drucker hatte in der alten printcap einen anderen Namen als unter CUPS). Und mein inzwischen geliebtes a2ps?

   a2ps -Pis70sys -n 3 --header="Dies ist ein Test!" /etc/smb.conf

Ebenfalls OK. Der Drucker is70sys heult auf. Das Ascii-nach-Postscript-Umwandlungstool funktioniert noch und die Drucker lassen sich auch wieder unter ihren bisherigen Bezeichnungen ansprechen. Nochmals gutgegangen!

6.3 Installation von ESP PrintPro 4.1b3 auf Solaris 2.7

  
  [...to be done...]
  

6.4 Wie man eine PPD für einen PostScript-Drucker editiert

In diesem Abschnitt nehmen wir an, dass ein PostScript-Drucker benutzt wird. Es sei eine vom Hersteller mitgelieferte PPD-Datei vorhanden. Der Drucker kann doppelseitig drucken und das Papier lochen. Diese Eigenschaften sollen als default-Einstellungen gesetzt werden. Alle Aufträge, die durch die Warteschlange laufen, welche mit dieser PPD beschrieben wird, werden dann doppelseitig und gelocht ausgedruckt, sofern nichts anderes verlangt wird.

Ein bei mir tatsächlich vorhandener Drucker, ein infotec 4700MF, wird als Beispiel benutzt. Die für MS-Windows vom Hersteller gelieferte (dort als infnh704.ppd bezeichnete) PPD wurde von mir nach /etc/cups/ppd/ kopiert und dort zu 1_infotec4700MF.ppd umbenannt. Sie muss in verschiedenen Abschnitten angepasst werden.

6.4.1 Drucker-Grundausstattung

Hier gibt's nix zu editieren. Grundausstattung ist Grundausstattung!

6.4.2 Drucker-Zusatzausstattung

In der PPD muss als erstes die Information über die installierten Zusatzoptionen aktiviert werden. Die Duplex-Einheit, für den doppelseitigen Druck zuständig, ist bei diesem Modell immer vorhanden. Hierzu braucht nichts geändert zu werden.

Die Loch-Vorrichtung ist Teil des »Finishers«. Dieser ist ausserdem für die ebenfalls möglichen Heftungen zuständig. Dieser Finisher ist eine Zusatzkomponente des Models infotec 4700MF. Es muss also die Information über den Finisher aktiviert werden.

In der PPD suchen wir nach einem Abschnitt der etwas über »InstallableOptions« aussagt:

  kurt@transmeta:/usr/share/cups/model > cat infnh704.ppd |grep InstallableOptions
  *OpenGroup: InstallableOptions/Installierte Optionen
  *CloseGroup: InstallableOptions

Die »Sprache« jeder PPD ist Englisch, d.h. alle Schlüsselwörter einer PPD sind in dieser Sprache. Eines der Schlüsselwörter ist »InstallableOptions«. Damit das User Interface leicht angepasst werden kann, sind Wörter, die bei einer grafischen Benutzerschnittstelle angezeigt werden sollen, in der »Iübersetzten« PPD hinter den Schlüsselwörtern, durch einen Schrägstrich abgetrennt ausgeschrieben.

Die zwischen den Schlüsselwörtern *OpenGroup: InstallableOptions und *CloseGroup: InstallableOptions befindlichen Zeilen listen alle installierbaren Zusatzausstattungen auf. In der hier beispielhaft gezeigten PPD sind es folgende Zeilen:

  *OpenUI *Option3/Groraummagazin: Boolean
  *DefaultOption3: False
  *Option3 False/Nicht installiert: ""
  *Option3 True/Installiert: ""
  *CloseUI: *Option3
 
  *OpenUI *Option7/Finisher: PickOne
  *DefaultOption7: None
  *Option7 None/Nicht installiert: ""
  *Option7 Type3000/Typ 3000: ""
  *Option7 Type3000P/Typ 3000 mit Lochung: ""
  *CloseUI: *Option7
 
  *OpenUI *Option8/Mailbox: Boolean
  *DefaultOption8: False
  *Option8 False/Nicht installiert: ""
  *Option8 True/Installiert: ""
  *CloseUI: *Option8
 
  *OpenUI *RIOption11/Ausrichtereinheit: Boolean
  *DefaultRIOption11: True
  *RIOption11 False/Nicht installiert: ""
  *RIOption11 True/Installiert: ""
  *?RIOption11: "save
    currentpagedevice /Jog known {(True)}{(False)} ifelse = flush
    restore"
  *End
  *CloseUI: *RIOption11
 
  *OpenUI *InstalledMemory/Druckerspeicher, gesamt: PickOne
  *DefaultInstalledMemory: 8Meg
  *InstalledMemory 8Meg/8 MB RAM: ""
  *InstalledMemory 16Meg/16 MB RAM: ""
  *InstalledMemory 24Meg/24 MB RAM: ""
  *InstalledMemory 32Meg/32 MB RAM: ""
  *InstalledMemory 40Meg/40 MB RAM: ""
  *InstalledMemory 48Meg/48 MB RAM: ""
  *InstalledMemory 56Meg/56 MB RAM: ""
  *InstalledMemory 72Meg/72 MB RAM: ""
  *?InstalledMemory: "save
    currentsystemparams /RamSize get
    1048576 div round cvi dup 0 lt {pop 0} if
    [
    [(72Meg) 72]
    [(56Meg) 56]
    [(48Meg) 48]
    [(40Meg) 40]
    [(32Meg) 32]
    [(24Meg) 24]
    [(16Meg) 16]
    [(8Meg)   8]
    ]
   {aload pop 2 index le {exit}{pop} ifelse} forall
   = flush pop
  restore"
  *End
  *CloseUI: *InstalledMemory
 
  *CloseGroup: InstallableOptions

Es sind in der PPD ausser dem hier gesuchten Finisher noch ein Grossraummagazin, eine Mailbox, eine Ausrichtereinheit und Zusatz-Druckerspeicher erwähnt.

Es ist leicht zu erkennen, dass jeder installierbaren Option ein eigener Abschnitt gewidmet ist. Diese Abschitte sind »:geklammerte« durch die PPD-Schlüsselbegriffe *OpenUI *<Options-Name> und *CloseUI: *<Options-Name>. Bei jeder Option muss ein Default-Wert angegeben sein, der die tatsächliche Konfiguration der Maschine wiedergeben sollte.

Bei jeder InstallableOption muss eine Auswahl getroffen werden:

  • entweder zwischen True und False (»Boolean«)
  • oder eine von mehreren Alternativen (»PickOne«)

Wir setzen hier in die entsprechenden Zeilen ein:

  *OpenUI *Option7/Finisher: PickOne
  *DefaultOption7: Type3000P
  [...snip...]

und auch noch

  *OpenUI *InstalledMemory/Druckerspeicher, gesamt: PickOne
  *DefaultInstalledMemory: 72Meg
  [...snip...]

da wir dem Lieferschein entnommen haben, dass 72 MB Drucker-RAM installiert sind.

6.4.3 Drucker-Voreinstellung

Als nächstes wollen wir die Voreinstellungen vornehmen, die doppelseitige und gelochte Ausdrucke zustande bringen. In der PPD suchen wir jetzt nach dem Begriff »DefaultOption«...

  kurt@transmeta:/usr/share/cups/model > cat infnh704.ppd |grep Default
  *DefaultOption3: False
  *DefaultOption7: Type3000P
  *DefaultOption8: False
  *DefaultRIOption11: True
  *DefaultInstalledMemory: 72Meg
  *DefaultColorSpace: Gray
  *DefaultResolution: 600dpi
  *DefaultDuplex: None
  *DefaultJog: None
  *DefaultInputSlot: LCT
  *DefaultTraySwitch: True
  *DefaultOutputBin: ExternalTray
  *DefaultRIStaple: None
  *DefaultRIPunch: None
  *DefaultRITonerSaver: False
  *DefaultRIEdgeSmoothing: False
  *DefaultCollate: True
  *DefaultRIIdiomRecognition: True
  *DefaultHalftoneType: 1
  *DefaultScreenProc: Dot
  *DefaultTransfer: Null
  *DefaultPageSize: A4
  *DefaultPageRegion: A4
  *DefaultImageableArea: A4
  *DefaultPaperDimension: A4
  *%DefaultLeadingEdge: Short
  *DefaultFont: Courier
  *DefaultColorSep: ProcessBlack.60lpi.600dpi/60 lpi / 600 dpi

Das Schlüsselwort »Default« kommt also 28 mal vor. Uns interesslieren hier die Teile der PPD, in denen von »*DefaultRIPunch: None« (Punch ist englisch für lochen) und »*DefaultDuplex: None« die Rede ist. Im Falle des Duplex-Schlüsselwortes finden wir folgenden Abschnitt:

  *% === Duplex options ============
  *OpenUI *Duplex/Duplex: PickOne
  *OrderDependency: 50.0 AnySetup *Duplex
  *DefaultDuplex: None
  *Duplex None/Aus: "<> >> setpagedevice"
  *End
  *Duplex DuplexNoTumble/Lange Kante: "<> >> setpagedevice"
  *End
  *Duplex DuplexTumble/Kurze Kante: "<> >> setpagedevice"
  *End
  *?Duplex: "save
   currentpagedevice dup /Duplex known
   {
    dup /Duplex get
    {/Tumble get {(DuplexTumble)} {(DuplexNoTumble)} ifelse}
    {pop (None)}
    ifelse
   } {pop (None)}
   ifelse = flush
  restore"
  *End
  *CloseUI: *Duplex

Und für Punch ist dieses zu finden:

  *% === Punch options ============
  *OpenUI *RIPunch/Lochen: PickOne
  *OrderDependency: 50.0 AnySetup *RIPunch
  *DefaultRIPunch: None
  *RIPunch None/Aus: "<>
    >> setpagedevice"
  *End
  *RIPunch RILL/Links (Querformat):
        "currentpagedevice /OutputType get (Finisher Main Tray) eq
  {<< /OutputType (Finisher Main Tray)>> setpagedevice}
        {<< /OutputType (Finisher Shift Tray)>> setpagedevice}ifelse
  << /Punch 2 /PunchDetails <>
   >> setpagedevice"
  *End
  *RIPunch RILP/Links (Hochformat):
                "currentpagedevice /OutputType get (Finisher Main Tray) eq
  {<< /OutputType (Finisher Main Tray)>> setpagedevice}
        {<< /OutputType (Finisher Shift Tray)>> setpagedevice}ifelse
  << /Punch 2 /PunchDetails <>
    >> setpagedevice"
  *End
  *RIPunch RITL/Oben (Querformat):
        "currentpagedevice /OutputType get (Finisher Main Tray) eq
  {<< /OutputType (Finisher Main Tray)>> setpagedevice}
        {<< /OutputType (Finisher Shift Tray)>> setpagedevice}ifelse
  << /Punch 2 /PunchDetails <>
  >>setpagedevice"
  *End
  *RIPunch RITP/Oben (Hochformat):
        "currentpagedevice /OutputType get (Finisher Main Tray) eq
  {<< /OutputType (Finisher Main Tray)>> setpagedevice}
        {<< /OutputType (Finisher Shift Tray)>> setpagedevice}ifelse
  << /Punch 2 /PunchDetails <>
  >>setpagedevice"
  *End
  *CloseUI: *RIPunch

Es ist zu erkennen, dass der Finisher offensichtlich das Papier an verschiedenen Positionen lochen kann. Damit die sinnvolle Voreinstellung Links (Hochformat) verwendet wird, sollten die Zeilen wie folgt abgeändert werden:

*% === Punch options ============
  *OpenUI *RIPunch/Lochen: PickOne
  *OrderDependency: 50.0 AnySetup *RIPunch
  *DefaultRIPunch: RILP
  [...snip...]

6.4.4 Drucker-Beschränkungen

Hier gibt's nix zu editieren. Beschränkung ist Beschränkung! Wer nicht auf der Kommandozeile versehentlich Optionen angeben will, die sich gegenseitig beissen, liest den Abschnitt einfach aufmerksam durch....

6.5 Wie man eine CUPS-PPD für einen Nicht-PostScript-Drucker schreibt

Hiervon hat der Autor keinerlei Ahnung.
Dieser Punkt muss zum jetzigen Zeitpunkt noch offen bleiben.
Hacker an die Front!

6.6 Wie man mit Job-Optionen druckt

[...to be done...]

6.6.1 Joboptionen auf der Kommandozeile mitgeben

[...to be done...]

6.6.2 Joboptionen über den Browser einstellen

[...to be done...]

6.7 Beispielaufzeichnung aus den CUPS-Logbüchern

An dieser Stelle möchte ich zeigen, wie der CUPS-IPP-Printserver über alle Aktionen Buch führt. Er schreibt in den Dateien error_log, access_log und page_log, die sich im Verzeichnis /var/log/cups/ befinden, die Aktionen mit. Das Format der Mitschrift ist das »Common Log Format«. Dieses Format wird von den meisten Web-Servern für ihre Log-Dateien verwendet. Web Reporting Tools wie der webalizer können dieses Format auswerten.

6.7.1 Vorbereitungen

Um einige Einträge in den Log-Dateien zu erhalten, drucke ich jetzt das Konzept dieses Artikels in einer früheren Fassung aus. Diese habe ich (ohne Illustrationen)in den Netscape geladen. Mit

  kurt@transmeta:~ > tail -f /var/log/cups/access_log
  kurt@transmeta:~ > tail -f /var/log/cups/error_log
  kurt@transmeta:~ > tail -f /var/log/cups/page_log

lassen sich diese drei Dateien in drei verschiedenen xterm-Fenstern »live« beobachten, während ich drucke.

6.7.2 Die Einträge im Access-Log

Hier die Aufzeichnungen aus dem access_log. Die Zeilen sind wegen besserer Lesbarkeit teilweise umgebrochen:

[...access_log...]

  10.160.16.40 - - [06/May/2000:01:37:06 -0100] "GET /ppd/1_infotec4700MF.ppd\

    HTTP/1.1" 200 51670
  127.0.0.1 - - [06/May/2000:01:37:09 -0100] "POST /printers/1_infotec4700MF\

    HTTP/1.1" 200 46594

In der ersten Spalte dieses »Access«-Log ist nachzulesen, welcher Host auf den CUPS-Server zugegriffen hat. Dann folgen Gruppen- und Benutzername an zweiter und dritter Stelle. Bei Gruppenname steht immer ein »-«. Beim Benutzer wird nur dann ein »-« eingetragen, wenn der Zugriff ohne Passwort erfolgen durfte. Ansonsten steht dort der authentifizierte Benutzername des Drucken-Wollenden.

Die erste der beiden Zeilen wurde geschrieben, als ich von einem Host aus auf den CUPS-Server zugriff, der die grafische CUPS-Benutzeroberfläche ESP PrintPro (kommerziell, siehe Abschnitt 5) benutzte. Beim Anklicken des Druckernamens erfolgt eine GET-Anfrage an den Server: der Host 10.160.16.40 will laut Log um 03:37:06 Uhr die PPD-Datei für den Drucker 1_infotec4700MF unter Verwendung des Protokolls HTTP 1.1 vom CUPS-Server abrufen; die »200« besagt, dass die Anfrage erfolgreich bedient wurde und die 51670 gibt die Anzahl der übertragenen Bytes an. (Dass die entsprechende ».ppd«-Datei des gewählten Druckers tatsächlich 51670 Bytes gross ist, wird durch eine kurze Kontrolle bestätigt:

  kurt@transmeta:~ > ls -l /etc/cups/ppd/1_infotec4700MF.ppd
  -rw-r--r-- 1 root root 51670 Mar 28 18:42 /etc/cups/ppd/1_infotec4700MF.ppd)

In der zweiten Access-Log-Zeile ist nachzulesen, dass der CUPS-Server 3 Sekunden später erfolgreich (»200«) genau 46594 Bytes in Empfang genommen hat, die ihm vom Rechner localhost (»127.0.0.1«) mit der POST-Methode übergeben wurden. Dieses war die Druckdatei.

6.7.3 Die Einträge im Error-Log

Nun zum nächsten Log. Es ist die Datei, in welcher auftretende Fehler abgespeichert werden.

[...error_log...]

  I [06/May/2000:01:37:09 -0100] Job 1285 queued on '1_infotec4700MF' by 'kurt'.

Im »Error«-Log ist kein Fehler aufgetreten, obwohl dort der zitierte Eintrag steht. Da in der cupsd.conf der LogLevel info eingestellt ist, der alle Anforderungen und Statusänderungen mitschreibt, steht in der ersten Spalte ein »I«. Anschliessend folgen Aufzeichnungsdatum und -zeit. Und am Ende der Zeile steht die Klartextnachricht über den Vorgang: dass eine Job-Nummer 1285 (Was, so viel habe ich schon gedruckt?!?) des Benutzers kurt für den Drucker 1_infotec4700MF in die Warteschlange eingereiht worden ist. Nichts aufregendes also.

Wer gerne herausfinden will, wie CUPS mit dem IPP umgeht und welche zusätzlichen Funktionen (z.B. das Weitergeben der PPDs an die Clients) einprogrammiert sind, kann in der cupsd.conf den LogLevel auf debug setzen und cupsd (als root) mit dem Befehl /etc/software/init.d/cupsd reload neu starten. Dann wird fast jedes Byte, das sich aufs Netz wagt und vieles von dem, was sich im Server selbst abspielt, mitstenografiert.

6.7.4 Die Einträge im Page-Log

Nun zum »Page Log«. Hier wird säuberlich über jede Druckseite Buch geführt.

[...page_log...]

  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 1 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 2 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 3 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 4 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 5 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 6 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 7 3
  1_infotec4700MF kurt 1285 [06/May/2000:01:37:10 -0100] 8 3

Der Druckjob mit der ID 1285 des Users kurt nimmt insgesamt 8 Zeilen ein - er war auch 8 Seiten lang, wie eine Nachzählung ergibt. Eine Sekunde nachdem er laut Error-Log ge-queued wurde, waren die Seiten zum Drucker 1_infotec4700MF gespoolt. Für jede Seite wird eine eigene Zeile geschrieben. Am Ende jeder Zeile steht die Anzahl der Drucke: ich hatte den Job dreimal angefordert.

6.7.5 Aufzeichnungen mit dem Debug-Level

Wird der LogLevel auf debug gestellt, vergrössert sich der Umfang der mitgeschriebenen Informationen pro Vorgang schlagartig. Der cupsd muss nach jeder Änderung die cupsd.conf neu auslesen:

  root@transmeta:/home/kurt > /etc/software/init.d/cups reload
  cups: scheduler restarted.

Wer die folgenden Zeilen genauer studiert, sieht, wie innerhalb einer Sekunde die folgenden Vorgänge ablaufen:

  • »Browse-Liste der verfügbaren Printer auf dem Laufenden halten«,
  • »Authentifizierung des Benutzers« (hier: Anonymous);
  • »Übertragung einer ASCII-Druckdatei in drei Brocken zu 1737, 1824 und 1049 Bytes (macht zusammen 4160) per IPP vom Client zum Server«
  • »Formatkonvertierung mittels diverser Filter von Text nach PostScript«
  • »Spoolen und Weiterleitung des Druckfiles mittels LPD an das Ausgabegerät«
[...error_log...]

  D [06/May/2000:02:41:12 -0100] UpdateBrowseList: (98 bytes from 10.160.16.40)\

   b0c6 3 ipp://10.160.16.40:631/printers/RicohAficio180PS "" "" "RICOH Aficio 180 PS"
  D [06/May/2000:02:41:13 -0100] accept() 14 from 127.0.0.1:631.
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 POST /printers/1_infotec4700MF\

   HTTP/1.1 D [06/May/2000:02:41:13 -0100] decode_auth() 14 username=""
  D [06/May/2000:02:41:13 -0100] POST /printers/1_infotec4700MF
  D [06/May/2000:02:41:13 -0100] CONTENT_TYPE = application/ipp
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 con->data_encoding = length,\

   con->data_remaining = 4871, con->file = 0
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 REQUEST /var/spool/cups/0000001f
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 writing 1737 bytes
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 con->data_encoding = length,\

   con->data_remaining = 2873, con->file = 16
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 writing 1824 bytes
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 con->data_encoding = length,\

    con->data_remaining = 1049, con->file = 16
  D [06/May/2000:02:41:13 -0100] ReadClient() 14 writing 1049 bytes
  D [06/May/2000:02:41:13 -0100] print_job: auto-typing file...
  D [06/May/2000:02:41:13 -0100] print_job: request file type is text/plain.
  D [06/May/2000:02:41:13 -0100] print_job: requesting-user-name = 'kurt'
  I [06/May/2000:02:41:13 -0100] Job 1293 queued on '1_infotec4700MF' by 'kurt'.
  D [06/May/2000:02:41:13 -0100] Started /usr/lib/cups/filter/texttops (PID 895)\

   for job 1293.
  D [06/May/2000:02:41:13 -0100] Started /usr/lib/cups/filter/pstops (PID 896)\

   for job 1293.
  D [06/May/2000:02:41:13 -0100] Started /usr/lib/cups/backend/lpd (PID 897)\

   for job 1293.
  D [06/May/2000:02:41:13 -0100] Page = 595x842; 6,26 to 575,833
  D [06/May/2000:02:41:13 -0100] Page = 595x842; 6,26 to 575,833
  D [06/May/2000:02:41:13 -0100] CloseClient() 14
  D [06/May/2000:02:41:13 -0100] lpd_command 02 PORT1
  D [06/May/2000:02:41:13 -0100] lpd_command returning 0
  D [06/May/2000:02:41:13 -0100] Control file is:
  D [06/May/2000:02:41:13 -0100] Htransmeta
  D [06/May/2000:02:41:13 -0100] Pkurt
  D [06/May/2000:02:41:13 -0100] ldfA897transmeta
  D [06/May/2000:02:41:13 -0100] dfA897transmeta
  D [06/May/2000:02:41:13 -0100] NdfA897transmeta
  D [06/May/2000:02:41:13 -0100] lpd_command 02 68 cfA897transmeta
  D [06/May/2000:02:41:14 -0100] lpd_command returning 0
  D [06/May/2000:02:41:14 -0100] lpd_command 03 10981 dfA897transmeta
  D [06/May/2000:02:41:14 -0100] lpd_command returning 0
  D [06/May/2000:02:41:54 -0100] UpdateBrowseList: (106 bytes from 10.160.16.40)\

   304e 3\
 ipp://10.160.16.40:631/printers/1_IS70sys "" "" "IS70CPmod1 PPD"

Wie zuverlässig sind die Aufzeichnungen über die Anzahl der verschickten Bytes und der gedruckten Seiten? Zumindest die Dateigrösse lässt sich veifizieren: der zugehörige Eintrag im Access-Log bestätigt, dass es insgesamt 4610 Bytes waren:

  [...access_log...]

  127.0.0.1 - - [06/May/2000:02:41:13 -0100] "POST /printers/1_infotec4700MF\

   HTTP/1.1" 200 4610

6.8 URIs zur Abfrage von CUPS

Wie oben erwähnt, kann jeder Standard-Web-Browser verwendet werden, um mittels des HTTP-Protokolls den cupsd über sein Befinden auszufragen. »Kommandos« hierfür, die dem Server per URI übergeben werden, sind beispielsweise:

  http://10.160.16.40:631/jobs?which_jobs=completed

(zur Anzeige aller abgearbeiteten Jobs)

  http://10.160.16.40:631/admin/?op=add-class

(um eine Klasse von Druckern anzulegen)

  http://10.160.16.40:631/admin/?op=add-printer

(um einen neuen Drucker anzulegen)

  http://10.160.16.40:631/admin/?op=print-test-page&printer_name=1_HPMopier320

(um dem Drucker 1_HPMopier320 eine Testseite zu schicken)

Keine Angst! Diese Kommandos sehen zwar kompliziert aus. Aber man muss sie nicht auswendig lernen. Über Hyperlinks von der Startseite http://CUPSserverName_oder_IP-adresse:631/printers/ lassen sich diese Kommandos per Maus-»Schieben und Klicken« finden und ausführen.

6.9 Einige lpadmin-Kommandos und ihre Ausgaben

  kurt@transmeta:~ > lpstat -p
  printer 1_infotec4700MF is idle.
  printer 1_infotec4700MF/1_infotec4700MF_simplex is idle.
  printer 1_Mopier320_IPP is idle.
  printer 320lokal@10.160.16.55 disabled -
          reason unknown
  printer mop_IPP@10.160.16.55 is idle.

6.10 Warum CUPS die LPR-Kommandos nicht mit SETUID root installiert

Das LPD-Protokoll zwingt die Clients dazu, einen privilegierten Port zu verwenden, um Druckdateien zu schicken oder zu verwalten. Privilegiert sind alle Ports kleiner als 1024. Auf privilegierte Ports darf eigentlich nur root zugreifen. Wenn ein Kommando oder Programm mit »SETUID root« installiert ist, läuft es immer mit root-Rechten. Nutzer ohne root-Rechte können diese Programme ausführen. Dann haben sie auf indirekte Art root-Rechte erlangt. Programme mit SETUID root gelten als anfällig hinsichtlich der Sicherheit von Systemen. Beim LPD-Protokoll müssen die Kommandos lpr, lpq, lprm und lpc mit SETUID root installiert sein, weil sie auf die privilegierten Ports 515 und benachbarte zugreifen müssen.

CUPS basiert auf dem IPP. Das IPP stellt diese Anforderung an die Clients nicht, privilegierte Ports zu verwenden. Deshalb können bei CUPS alle LPR-Programme (d.h. die Client-Programme des LPD) als normal ausführbar installiert sein. SETUID root ist für die Clients nicht erforderlich: eine Verringerung der Sicherheits-Risiken.

Da der CUPS-Server alle Filter und Backends als unprivilegierter User (normalerweise lp) laufen lässt, muss wenigstens das lpd-Backend mit SETUID root installiert sein. Um böswillige Nutzer daran zu hindern, Dateien zu drucken, zu denen ihnen ansonsten der Zugriff (aufgrund der Rechte-Vergabe) verwehrt wäre, wird dieses Backend ohne Lese- oder Ausführ-Recht für normale Nutzer installiert.

7. KUPS als KDE-Frontend für CUPS

Leider bisher erst parallel anzuschliessen. Noch nicht stabil. Noch nicht einsatzfähig.

Wer CUPS und das IPP mit einem Nicht-PostScript-Drucker verwenden will, jedoch keine Lizenz für ESP PrintPro erwerben möchte, sollte sich mal auf

  ftp://cups.sourceforge.net/pub/cups/kups

umschauen. Dort kann man fertige PPDs für EPsons, HPs, Lexmarks usw. finden oder eventuell mit Hilfe von cups-o-matic sich online eine PPD erzeugen lassen... [...to be done...]

8. Troubleshooting und Fehlersuche

Bei SuSE zuerst den lpd abstellen. Sonst wird er beim nächsten Booten wieder neu gestartet. Und dann funktionert CUPS nicht, weil ihm der lpd in's Gehege kommt!
[...to be done...]

9. Zusammenfassung

CUPS ist eine echte Neuerung in der Linux/Unix-Welt.
[...to be done...]

9.1 Wo wird CUPS in nächster Zeit auftauchen?

Debian, KDE, SuSE,????
[...to be done...]

9.2 Druckerhersteller und CUPS

Letzten Endes muss aber der Druck auf die Hersteller wachsen. Sie müssen dafür sorgen, dass eine funktionierende PPD vorliegt für das Gerät, das sie uns verkaufen wollen. Schliesslich ist es für einen Hersteller kein grosser Aufwand, eine PPD zu schreiben, da er ja die Besonderheiten seines Produktes am besten kennt...

Und umgekehrt gilt: diejenigen Hersteller, die als erste begreifen, wie leicht es für sie ist, mit Hilfe von CUPS und dem IPP und durch Zur-Verfügung-Stellung von »PPDs-für-Nicht-PostScript-Drucker« eine umfassende, effektive und kostengünstige Treiberfunktionalität für ihre Drucker anzubieten, werden auf dem expandierenden Linux-Markt die Nase vorne haben. Und Anwender und Administratoren sehen entspannteren Druck-Zeiten entgegen...


mehr Infos

[0]  http://www.cups.org/overview.html
[1]  PostScript Language Reference Manual (2219 kB, 912 Seiten):
     http://www.adobe.com/print/postscript/pdfs/PLRM.pdf
[2]  PostScript Printer Description File Format Specification,
         (617 kB, 236 Seiten):
     http://partners.adobe.com/asn/developers/PDFS/TN/5003.PPD_Spec_v4.3.pdf
[3]  Sammlung von PPDs, geordnet nach Druckerhersteller:
     http://www.adobe.com/products/printerdrivers/winppd.html
[4]  Dokumentation und Support für ESP Print Pro und CUPS:
     http://www.easysw.com/printpro/
[4b] ESP Print Pro Download (Achtung, enthält bereits CUPS, separater
     Download dann nicht erforderlich): http://www.easysw.com/software.html
[4c] Kostenlose 45-Tage-Probe-Lizenz für ESP Print Pro, voll
     funktionsfähig: http://www.easysw.com/license.html
[5]  Dokumentation, Download, FAQs, Mailingliste für CUPS:
     http://www.cups.org/
[6]  Design Goals for an Internet Printing Protocol (April 1999):
     http://www.ietf.org/rfc/rfc2567.txt
[7]  Homepage der Printer Working Group, die das IPP ausgearbeitet hat:
     http://www.pwg.org/ipp/
[8]  http://www.ietf.org/ . Links zu allen RFCs.
[9]  http://www.ietf.org/rfc/rfc2567.txt .
     »Design Goals for an Internet Printing Protocol« (April 1999).
[10] http://www.easysw.com/printpro/pricing.html  . Preisliste für die
     verschiedenen Versionen von ESP PrintPro
[11] http://sourceforge.net/project/?group_id=1797 . CUPS und KUPS
[12] http://www.linux-magazin.de/ausgabe/2000/02/CUPS/cups1.html .
     Erster Teil der Artikel-Reihe.
[13] http://www.cups.org/sam.html . Software Administrators manual für CUPS.
[14] http://www.cups.org/sum.html . Software Users Manual für CUPS.


Über den Autor

Der Autor dieses Papiers ist ein Linux-Anfänger. Er hat beruflich viel mit Druckern zu tun. Da Linux seit neuestem zu seinen Hobbys gehört, hat er sich deshalb natürlich auch (hauptsächlich in seiner Freizeit) mit Drucksoftware für sein Lieblings-Betriebssystem beschäftigt. Derzeit versucht er seinen Arbeitgeber, die Danka Deutschland GmbH (einer der grössten Hersteller-unabhängigen Anbieter für Digitalsysteme zum Kopieren, Drucken, Faxen und Scannen) davon zu überzeugen, ESP PrintPro ins Produkt-Portfolio aufzunehmen.

Der Autor kann keinerlei Gewährleistung für die Richtigkeit all seiner Ausführungen übernehmen. Dieses Papier wurde für den »Linuxtag 2000« geschrieben. Die Veranstalter des Linuxtages erhalten alle Rechte an diesem Papier übertragen, solange seine ursprüngliche Urheberschaft erwähnt und es im Sinne der »Open Source«-Bewegung verwendet wird.

Des Autor wünscht sich vom KDE-Projekt die baldige Fertigstellung von »KUPS«, einem grafischen Frontend für das hier beschriebene CUPS. Vielleicht kann dieses Papier einen Beitrag leisten, indem es CUPS bekannter macht und die Grundlage für ein »CUPS+Linux-HOWTO« bildet.


Anmerkung

Für dieses Papier wurden Arbeiten und Ideen anderer Autoren verwendet. Insbesondere sei auf die RFCs über das IPP verwiesen. Der Artikel »The Internet Printing Protocol« von Carl-Uno Manros diente als erste Anregung. Die Dokumantation von CUPS war eine weitere Quelle. Der Urheber dieses Papiers ist Linux-Anfänger (wenn auch zwischenzeitlich etwas fortgeschrittender..) Eigenes hat der Autor höchstens insofern beigetragen, dass er die Gedanken dritter eventuell falsch wiedergab...Teile dieses Papiers wurden in ähnlicher Form bereits in den Ausgaben 02/2000, 04/2000 und 06/2000 des Linux-Magazin veröffentlicht. Aus diesem Papier werden demnächst »CUPS-Printing-HOWTO« und »CUPS-Printing-HOWTO« entstehen.

  LinuxTag 2000 Konferenz-CD-ROM © 2000 LinuxTag e.V.