Das Common UNIX Print System (CUPS) ist mittlerweile sehr populär geworden. Alle großen Linux-Distributionen liefern es als das Standard-Drucksystem aus. Für viele ist es ein mystisches Tool. Meistens funktioniert es einfach. Daher wird es oft als „Black Box“ angesehen, und solange es funktioniert, möchte sich auch niemand damit befassen. Sobald aber ein kleines Problem auftritt, bekommt man Schwierigkeiten damit herauszufinden, wie man mit der Fehlersuche beginnt. Sehr viele Informationen, die auch für CUPS relevant sind, finden Sie im Kapitel „Klassische Druckerunterstützung“.

CUPS bietet einige mächtige und einmalige Möglichkeiten. Neu ist auch die sehr einfache Handhabung der grundsätzlichen Funktionen. Da diese Funktionen anders sind als in den mehr traditionell orientierten Drucksystemen, wenden Sie am besten nicht Ihr bisheriges Wissen bezüglich des Druckens an. Versuchen Sie eher, CUPS von Grund auf zu verstehen. Diese Dokumentation soll dazu beitragen, dass Sie CUPS wirkllich verstehen. Beginnen wir mit den grundsätzlichen Dingen.

CUPS ist mehr als nur ein System für das Printspooling. Es ist ein komplettes Drucker-Management-System, das das neue Internet Printing Protocol (IPP) erfüllt. IPP ist ein IETF-Standard (Internet Engineering Task Force) für das Drucken in Netzwerken. Viele seiner Funktionen können remote oder lokal über einen Webbrowser verwaltet werden (Bereitstellung eines plattformunabhängigen Zugriffs auf den CUPS-Printserver). Zusätzlich hat es die traditionellen Kommandozeilen-Tools und weitere moderne GUI-Schnittstellen (GUI-Schnittstellen von Drittherstellern, wie etwa das überwältigende, in KDE enthaltene KDEPrint).

CUPS erlaubt das Anlegen von „raw“- Druckern (keine Übersetzung der Druckdaten) genauso wie von „smarten“ Druckern (Cups übersetzt das Dateiformat in das benötigte Druckerformat). Dies gibt CUPS auf vielfache Arten ähnliche Fähigkeiten wie dem MS Windows Print Monitoring System. Falls Sie ein CUPS- Verfechter sind, dann werden Sie sicher argumentieren, dass CUPS sogar besser ist! Wie auch immer, lassen Sie uns damit weitermachen, wie man CUPS für eine Zusammenarbeit mit MS Windows-Druckclients über SAMBA konfigurieren kann.

Samba hat eine spezielle Beziehung zu CUPS. Samba kann mit Unterstützung für die CUPS-Library übersetzt werden. Die meisten aktuellen Installationen haben diesen Support bereits per Default in smbd und den anderen Samba-Binaries integriert. Sie können CUPS auch benutzen, wenn Samba nicht gegen die libcups.so gelinkt ist, aber es gibt einige Unterschiede in den benötigten oder unterstützten Konfigurationen.

Wenn Samba mit libcups kompiliert worden ist, verwendet printcap = cups die CUPS-API, um Drucker aufzufinden, Jobs zu übergeben, Queues abzufragen usw. Sonst wird dies mit der zusätzlichen -oraw-Option auf die System V-Druck-Kommandos umgesetzt. Auf einem Linux-System können Sie mit dem Utility ldd nähere Details erfahren (ldd muss nicht auf allen Plattformen vorhanden sein, seine Funktionen können auch in einem vergleichbaren Programm enthalten sein).

root# ldd `which smbd`
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
[....]

Die Zeile libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) bedeutet, dass der CUPS-Support in Samba einkompiliert wurde. In diesem Fall und bei gesetztem printing = cups werden anderweitige manuell gesetzte print-Kommandos in smb.conf ignoriert. Bitte merken Sie sich diesen wichtigen Punkt !

Als Zusammenfassung zeigt das folgende Beispiel ein einfaches drucker-relevantes Setup für smb.conf, um den grundlegenden Support für CUPS zu erhalten:

Das ist alles, was Sie an grundlegenden Einstellungen zum Drucken mit CUPS benötigen. Dies wird alle Grafik-, Text-, PDF- und Postscript-Dateien drucken, die von Ihren Windows-Clients übermittelt werden. Aber die meisten Ihrer Windows-Benutzer würden nicht wissen, wie sie solche Dateien ohne einen grafischen Druckerdialog übermitteln können. Windows-Clients haben meist lokale Druckertreiber installiert, die in den Anwendungen durch den Druck-Button aktiviert werden. Ihre Benutzer drucken auch selten Dateien aus der Kommandozeile. Im Gegensatz zu Unix-Clients senden sie kaum Grafik-, Text- oder PDF- formatierte Dateien direkt zum Spooler. Sie drucken fast ausschließlich aus GUI-Anwendungen über den „Druckertreiber“, der zwischen der nativen Ausgabe des Programms und dem Druckdatenstrom sitzt. Ist das Ausgabegerät kein PostScript-Drucker, so ist der Druckdatenstrom in einem „Binärformat“, das nur der betreffende Drucker versteht. Lesen Sie bitte weiter, um zu verstehen, welche Probleme dabei entstehen und wie Sie diese vermeiden.

Die nächste Konfiguration beschreibt ein etwas komplexeres Drucker-Setup der smb.conf. Es aktiviert generellen CUPS-Druck-Support für alle Drucker, definiert aber einen Drucker, der davon abweichend konfiguriert wird.

Diese spezielle Freigabe ist nur für Testzwecke gedacht. Sie schreibt den Druckauftrag nicht in eine Datei, sondern protokolliert nur die Auftragsparameter, die Samba bekannt sind, in die Datei /tmp/smbprn.log und löscht die Auftragsdatei. Außerdem ist der Parameter printer admin dieser Freigabe „kurt“ (nicht die Gruppe „@ntadmins“), Gast-Zugriff ist nicht erlaubt, die Freigabe wird nicht in der Netzwerkumgebung angezeigt (also müssen Sie wissen, dass es sie gibt), und sie erlaubt nur den Zugriff von nur drei Hosts. Um CUPS daran zu hindern, sich hier einzumischen und die Druckjobs dieser Freigabe zu übernehmen, müssen wir dies setzen: printing = sysv und printcap = lpstat.

Viele kleine Büro- oder Heim-Netzwerke, genauso wie schlecht organisierte größere Umgebungen, erlauben jedem Client einen direkten Zugriff auf verfügbare Netzwerkdrucker. Dies ist im Allgemeinen eine schlechte Idee. Es blockiert oft den Zugriff eines Clients auf den Drucker, wenn der Auftrag eines anderen Clients gedruckt wird. Dies könnte die Applikation des ersten Clients „einfrieren“, während diese darauf wartet, den Auftrag loszuwerden. Es gibt auch immer wieder Beschwerden darüber, dass Aufträge gedruckt werden, deren Seiten miteinander vermischt sind. Ein besseres Konzept ist die Verwendung eines Druck-Servers; er routet alle Aufträge durch ein zentrales System, das unverzüglich antwortet, Aufträge von mehreren verschiedenen Clients zur selben Zeit annimmt und diese danach in der korrekten Reihenfolge an die Drucker weiterleitet.

Die meisten traditionell konfigurierten UNIX-Druck-Server, die für Sambas Windows-Clients arbeiten, zeigen ein wirklich simples Setup. Ihre einzige Aufgabe war die Verwaltung des „raw spooling“ aller Jobs, die ihnen von Samba übergeben wurde. Dieser Ansatz bedeutete, dass von den Windows-Clients erwartet wurde, dass sie die Druckauftragsdatei so vorbereiten, dass diese bereit zum Versenden an das Drucker-Gerät ist. Hier muss ein nativer (vom Hersteller bereitgestellter) Windows-Druckertreiber für das Zielgerät auf jedem einzelnen Client installiert werden.

Es ist möglich, CUPS, Samba und Ihre Windows-Clients in derselben traditionellen und simplen Art zu konfigurieren. Wenn CUPS-Drucker für die Betriebsart RAW-print-through konfiguriert sind, ist es die Verantwortung des Samba-Clients, den Druckauftrag (die Datei) vollständig wiederzugeben. Die Datei muss in einem Format gesendet werden, das passend für die direkte Weitergabe an den Drucker ist. Clients müssen dafür die vom Hersteller bereitgestellten Treiber verwenden, CUPS wird keinerlei Format-Wandlung durchführen.

Die einfachste mögliche Druck-Konfiguration ist die Verwendung von „raw print-through“. Dies wird dadurch erreicht, dass der Drucker so installiert wird, als ob er physisch an den Windows-Client angeschlossen wäre. Sie leiten dann die Ausgabe auf eine raw-Netzwerk-Druck-Warteschlange um. Dazu ist folgendes Vorgehen erforderlich:

Die Druckertreiber auf den Windows-Clients können auf zwei funktional verschiedene Arten installiert werden:

Wir empfehlen, die zweite Methode zu verwenden.

Wenn Sie die erste Variante verwenden (Treiber werden auf Client-Seite installiert), gibt es eine Einstellung, die Sie beachten müssen: CUPS muss mitgeteilt werden, dass es den „raw“-Druck von Binär-Dateiformaten erlauben soll. Die CUPS-Dateien, die korrekt für RAW-Modus-Drucker gesetzt sein müssen, sind:

Beide enthalten Einträge (am Ende der jeweiligen Datei), die auskommentiert werden müssen, um den RAW-Modus-Betrieb zu erlauben. In /etc/cups/mime.types muss folgende Zeile vorhanden sein:

	 application/octet-stream
	

In /etc/cups/mime.convs müssen Sie diese Zeile haben:

		application/octet-stream   application/vnd.cups-raw   0   -
	

Wenn diese beiden Dateien nicht korrekt für RAW-Windows-Client-Druck konfiguriert sind, kann es sein, dass Sie die gefürchtete Meldung Unable to convert file 0 in Ihrer CUPS-error_log-Datei vorfinden.

Hintergrund.  Da CUPS ein sicherheitsbewussteres Drucksystem ist als die traditionellen Systeme, erlaubt es in der Voreinstellung nicht, dass ein Benutzer beliebige (möglicherweise binäre) Daten an Druckgeräte sendet. Dies könnte leicht dazu benutzt werden, einen „Denial of Service“-Angriff auf Ihre(n) Drucker zu starten, was zumindest den Verlust von einer Menge Papier und Tinte nach sich ziehen würde. „Unbekannte“ Daten werden von CUPS als MIME type: application/octet-stream gekennzeichnet, und es wird ihnen nicht erlaubt, zum Drucker zu gelangen. In der Voreinstellung können Sie nur andere (bekannte) MIME-Typen „raw“ senden. Das „raw“-Senden von Daten bedeutet, dass CUPS nicht versucht, die Daten zu konvertieren und sie einfach unangetastet an den Drucker weiterleitet (im nächsten Kapitel finden Sie noch mehr Hintergrund-Erklärungen dazu).

Dies ist alles, was Sie darüber wissen müssen, um die CUPS/Samba-Combo zum „raw“-Drucken von Daten zu bewegen, die von Windows-Clients vorbereitet wurden, deren Herstellertreiber lokal installiert worden sind. Wenn Sie nicht an Hintergrund-Informationen zu erweitertem CUPS/Samba-Drucken interessiert sind, überspringen Sie einfach die restlichen Abschnitte dieses Kapitels.

Dieser Abschnitt beschreibt drei übliche Methoden, zuzüglich einer neuen, mit denen Druckertreiber auf den Server geladen werden können („Upload“).

Wenn Sie im MS-RPC-Stil drucken wollen, müssen Sie die Treiber zuerst auf den Samba-Server hochladen (Freigabe [print$]). Im vorangegangenen Kapitel dieser HOWTO-Sammlung wurde bereits beschrieben, wie man Druckertreiber auf dem Samba-Host ablegt (damit die Windows-Clients diese via „Point'n'Print“ herunterladen und verwenden können. Dort finden Sie Beschreibungen und Referenzen zu drei Methoden, um Druckertreiber auf dem Samba-Server vorzubereiten:

Diese drei Methoden können genauso auf CUPS angewendet werden. Ein neuer und praktischerer Weg, um Windows-Treiber in Samba zu laden, steht zur Verfügung, wenn Sie CUPS verwenden:

cupsaddsmb wird weiter unten im Detail behandelt. Zuerst erkunden wir aber das CUPS-Filter-System und vergleichen die Windows- und UNIX-Druck-Architektur.

Netzwerkdurck ist eine der kompliziertesten und fehlerträchtigsten Alltagsaufgaben, die ein Benutzer oder Administrator zu bewältigen hat. Dies gilt für alle Betriebssysteme. Und hier sind die Gründe dafür:

Bei den meisten Dateiformaten können Sie nicht erwarten, dass die Datei einfach dadurch gedruckt wird, dass Sie sie an den Drucker schicken. Es muss eine Wandlung des Dateiformats stattfinden. Das Problem dabei ist, dass es keinen gemeinsamen Standard für Druck-Datei-Formate gibt, der für alle Hersteller und Druckertypen gelten würde. Während sich PostScript (Handelsmarke von Adobe) und - zu einem gewissen Teil - PCL (Handelsmarke von HP) dadurch zu halb offiziellen „Standards“ entwickelt haben, dass sie die am weitesten verbreiteten PDLs (Page Description Languages) sind, gibt es nach wie vor viele Hersteller, die „ihr eigenes Süppchen kochen“. (Der Grund dafür können inakzeptabel hohe Lizenzgebühren für drucker-interne PostScript-Interpreter sein usw.)

Im Betriebssystem Windows wird die Formatwandlung von den Druckertreibern erledigt. Auf der Windows-Plattform haben alle Anwendungsprogrammierer eine eingebaute API zur Verfügung, das Graphical Device Interface (GDI). Es ist ein Teil und Paket des Betriebssystems selbst, um darauf aufzubauen. Dieser GDI-Kern wird als gemeinsame einheitliche Grundlage für alle Windows-Programme verwendet, um Bilder, Schriften und Dokumente am Bildschirm („on screen“) darzustellen, genauso wie auf Papier („on paper“) (Druck). Daher können Druckertreiber-Hersteller bei ihrem Druckertreiber-Input von einem wohldefinierten GDI-Output ausgehen. Das Erreichen von WYSIWYG („What You See Is What You Get“) ist relativ einfach, weil die On-screen-Grafik-Primitive genauso wie die on-paper gezeichneten Objekte von einer gemeinsamen Quelle stammen. Diese Quelle, die GDI, erzeugt oft ein Dateiformat namens Enhanced MetaFile (EMF). EMF wird vom Druckertreiber verarbeitet und in ein drucker-spezifisches Format konvertiert.

Abbildung 19.1. Windows druckt auf einen lokalen Drucker.

In UNIX und Linux gibt es keine vergleichbare Schicht im OS-Kernel oder dem X-Server (Bildschirm-Darstellungsserver). Jede Anwendung ist für sich selbst verantwortlich, um ihre Druckausgabe zu erzeugen. Zum Glück verwenden die meisten Postscript, und das gibt zumindest etwas gemeinsame Grundlagen. Leider gibt es viele verschiedene Qualitätsstufen für Postscript. Und, was noch schlimmer ist, es gibt einen riesigen Unterschied (und keinen gemeinsamen Ursprung) zwischen der Darstellung desselben Dokuments auf dem Bildschirm und dem Zustand, wie dieses Dokument auf Papier dargestellt wird. WYSIWYG ist schwieriger zu erreichen. Dies stammt aus der Zeit, als vor Jahrezehnten die Vorläufer von X.org beim Entwurf der UNIX-Grundlagen und -Protokolle für GUIs die Verantwortung für die „Papierausgabe“ ablehnten und sich auf „nur on-screen“ beschränkten. (Seit einigen Jahren ist das Projekt „Xprint“ in Entwicklung. Man versucht, Druckunterstützung in das X-Framework zu integrieren, inklusive eines PostScript- und eines PCL-Treibers, aber dieses Projekt ist noch nicht praxistauglich.) Sie können dieses unangenehme Erbe bis heute sehen, wenn Sie sich die verschiedenen „font“-Verzeichnisse auf Ihrem System ansehen; es gibt eigene Schriften für X-Darstellung und andere für den Druck auf Papier.

Hintergrund.  Die Programmiersprache PostScript ist eine „Erfindung“ von Adobe Inc., aber ihre Spezifikationen wurden vollständig veröffentlicht. Ihre Stärke liegt in den mächtigen Fähigkeiten, grafische Objekte zu beschreiben (Schriften, Formen, Muster, Linien, Kurven, und Punkte), deren Attribute (Farbe, Strichstärke) und die Art, diese zu manipulieren (Skalieren, Verzerren, Rotieren, Verschieben). Wegen der offenen Spezifikation kann jeder mit entsprechenden Fähigkeiten damit beginnen, seine eigene Implementation eines PostScript-Interpreters zu schreiben und diesen zu verwenden, um PostScript-Dateien auf dem Bildschirm oder auf Papier darzustellen. Die meisten grafischen Ausgabegeräte basieren auf dem Konzept von „Raster-Bildern“ oder „Pixeln“ (eine zu erwähnende Ausnahme bilden Stift-Plotter). Natürlich können Sie eine PostScript-Datei in seiner Text-Form betrachten und ihren PostScript-Code lesen, also die Sprachbefehle, die von einem Rasterizer interpretiert werden müssen. Rasterizer erzeugen Pixel-Bilder, die von einem Viewer auf dem Schirm dargestellt werden können oder eben von einem Drucker auf dem Papier.

Also fehlt UNIX eine gemeinsame Basis für den Druck und die Bildschirmdarstellung. Trotz dieses ungünstigen Erbes ist das Drucken grundsätzlich ziemlich einfach, wenn Sie PostScript-Drucker zur Verfügung haben. Der Grund dafür ist, dass diese Drucker einen eingebauten PostScript-„Interpreter“ besitzen, der auch Raster Image Processor (RIP) genannt wird. (Dadurch sind diese Drucker teurer als andere Drucker). Wenn Sie diesen Druckern PostScript-Daten schicken, werden diese sie auch drucken. Ihr RIP erledigt all die harte Arbeit des Umwandelns von PostScript-Zeichenbefehlen in ein Bitmap-Bild, wie Sie es auf Papier sehen, in einer Auflösung, wie Sie von Ihrem Drucker unterstützt wird. Dies entspricht dem PostScript-Druck einer Datei aus Windows.

Abbildung 19.2. Drucken auf einen PostScript-Drucker

Jedoch gibt es auch andere Drucker-Typen da draußen. Diese Typen wissen nicht, wie man PostScript druckt. Sie verwenden ihre eigene Page Description Language (PDL, oft proprietär). Das Drucken auf diesen Geräten stellt höhere Anforderungen. Da Ihre UNIX-Anwendungen meistens PostScript erzeugen und da diese Geräte kein PostScript verstehen, müssen Sie die Druckdateien auf dem Host in ein für Ihren Drucker passendes Format konvertieren, bevor Sie diese an den Drucker senden können.

Hier betritt Ghostscript die Bühne. Ghostscript ist der traditionelle (und ziemlich mächtige) PostScript-Interpreter, der auf UNIX-Plattformen verwendet wird. Es ist ein RIP als Software, imstande, viele Datei-Konvertierungen für ein sehr großes Spektrum von Hardware-Geräten bzw. Software-Dateiformaten durchzuführen. Die Ghostscript-Technologie und -Treiber ermöglichen den PostScript-Druck auf nicht-PostScript-fähige Hardware.

Abbildung 19.3. Ghostscript als RIP für nicht-PostScript-fähige Drucker

Während PostScript im Kern eine Seitenbeschreibungssprache (PDL) ist, um das Layout einer Seite auf eine geräte-unabhängige Art darzustellen, werden in der Praxis Druckaufträge letztendlich immer von Hardware mit geräteabhängigen Eigenschaften ausgegeben. Um all die Unterschiede in der Hardware zu berücksichtigen und Innovation zu ermöglichen, hat Adobe eine Syntax und ein Dateiformat für PostScript-Printer-Description-(PPD-)Dateien bestimmt. Jeder PostScript-Drucker wird mit einer dieser Dateien geliefert.

PPDs enthalten all die Informationen über generelle und spezifische Eigenschaften des jeweiligen Drucker-Modells: Welche verschiedenen Auflösungen kann es verarbeiten? Hat es eine Duplex-Einheit? Wie viele Papierschächte gibt es? Welche Arten von Medien und deren Formate kann es verarbeiten? Für jeden Punkt benennen PPDs auch die spezielle Befehlsfolge, die man an den Drucker (meist innerhalb der PostScript-Datei) senden muss, um ihn zu aktivieren.

Die Information in diesen PPDs ist dafür bestimmt, von den Druckertreibern berücksichtigt zu werden. Daher wird als Teil des für einen bestimmten Drucker installierten Windows-PostScript-Treibers die PPD des Druckers installiert. Wo es Sinn macht, werden die PPD-Features in den UI-Dialogen des Treibers dargestellt, um dem Benutzer eine Auswahl von Druck-Optionen zu geben. Abschließend wird die Auswahl des Benutzers in die vom Drucker erstellte PostScript-Datei geschrieben (in der Form spezieller PostScript-, PJL-, JCL- oder herstellerspezifischer Befehle).

CUPS kann mit allen spezifikationsgemäßen PPDs ungehen, wie sie von Herstellern für ihre PostScript-Modelle bereitgestellt werden. Sogar wenn ein Hersteller unser Lieblingsbetriebssystem nicht in seinen Handbüchern und Broschüren erwähnt hat, können Sie sich sicher darauf verlassen: Wenn Sie die Windows NT-Version der PPD erhalten, können Sie diese unverändert mit CUPS verwenden und daher die volle Leistungsfähigkeit Ihres Druckers nutzen, genauso wie ein Windows NT-Benutzer es könnte!

CUPS verwendet auch spezielle PPDs, um mit Nicht-PostScript-Druckern umzugehen. Diese PPDs sind üblicherweise nicht von den Herstellern verfügbar (und, nein, Sie können nicht einfach die PPD eines PostScript-Druckers mit demselben Modellnamen verwenden und hoffen, dass diese auch mit der Nicht-PostScript-Version funktioniert). Um zu verstehen, wie diese PPDs funktionieren, müssen wir zuerst tief in die Architektur der CUPS-Filter und -Dateiumwandlung eintauchen. Bleiben Sie dran.

Die erwähnten „CUPS-Anforderungen“ für Filter sind simpel. Nehmen Sie den Dateinamen oder stdin als Input, und schreiben Sie diesen auf stdout. Die Filter sollten die folgenden fünf bis sechs Argumente verstehen: printer job user title copies options [filename].

Windows-Clients, die auf einen NT-basierenden Druck-Server drucken, haben zwei Möglichkeiten. Sie können:

Die beiden Druck-Möglichkeiten werden in den Flussdiagrammen Treiberausführung auf dem Client und Treiberausführung auf dem Server gezeigt.

Im ersten Fall muss der Druck-Server die Datei als raw behandeln. Das bedeutet, er sollte die Auftragsdatei nicht anrühren oder in irgendeiner Art zu konvertieren versuchen. Dies ist, was ein herkömmlicher UNIX-basierender Druck-Server auch tun kann, und das bei besserer Performance und stabiler als ein NT-Druck-Server. Damit sind wohl die meisten Samba-Administratoren vertraut. Ein Vorteil dieses Setups ist, dass dieser „spooling-only“-Druck-Server sogar verwendet werden kann, wenn kein(e) Treiber für UNIX verfügbar sind. Es genügt, die Windows-Treiber zur Verfügung und auf den Clients installiert zu haben.

Abbildung 19.13. Treiberausführung auf dem Client

Der andere Pfad führt den Druckertreiber auf dem Server aus. Der Client übermittelt Druckdateien im EMF-Format an den Server. Der Server verwendet den PostScript-, PCL-, ESC/P- oder einen anderen Treiber, um die EMF-Datei in die druckerspezifische Sprache zu konvertieren. Es ist UNIX nicht möglich, dasselbe zu tun. Derzeit gibt es kein Programm und keine Methode, um die GDI-Ausgabe eines Windows-Clients auf einem UNIX-Server auf etwas umzuwandeln, das ein Drucker verstehen könnte.

Abbildung 19.14. Treiberausführung auf dem Server

Jedoch ist etwas Ähnliches mit CUPS möglich. Lesen Sie weiter.

Hier ist ein einfaches Rezept, das zeigt, wie Sie zum Nutzen Ihrer druckenden Windows-Clients Vorteile aus den mächtigen Eigenschaften von CUPS ziehen:

Dies erfordert, dass die Clients einen PostScript-Treiber verwenden (sogar, wenn der Drucker kein PostScript-Modell ist). Es erfordert auch, dass Sie einen Treiber auf dem CUPS-Server haben.

Um CUPS-basierendes Drucken per Samba zu aktivieren, sollten zunächst folgende Optionen im Abschitt [global] Ihrer Datei smb.conf gesetzt werden:

Wenn diese Parameter angegeben werden, werden alle manuell gesetzten Druck-Anweisungen (wie print command oder lppause command) in smb.conf (genauso wie in Samba selbst) ignoriert. Stattdessen arbeitet Samba direkt mit CUPS zusammen. Dazu verwendet es dessen „application program interface“ (API), sofern Samba mit Unterstützung der CUPS-Bibliothek (libcups) kompiliert wurde. Wenn Samba nicht mit CUPS-Unterstützung kompiliert wurde und wenn keine anderen Druckbefehle gesetzt sind, wird der Druck den System V-AT&T-Befehlssatz mit der automatisch gesetzten Option „-oraw“ verwenden, womit Druckaufträge einfach weitergegeben werden. (Wenn Sie Ihre selbst definierten Druckbefehle mit einem Samba-Server verwenden wollen, der CUPS-Unterstützung einkompiliert hat, verwenden Sie einfach printing = sysv.)

Abbildung 19.15. Drucken über einen CUPS/Samba-Server

Samba muss sein eigenes Spooling-Verzeichnis verwenden. (Es wird mit einer Zeile wie path = /var/spool/samba im Abschnitt [printers] oder [printername] von smb.conf gesetzt.) Samba empfängt den Auftrag in seinem eigenen Spooling-Verzeichnis und leitet ihn in das Spooling-Verzeichnis von CUPS weiter. (Das CUPS-Spooling-Verzeichnis wird mit der Anweisung RequestRoot in einer Zeile gesetzt, die per Voreinstellung RequestRoot /var/spool/cups lautet). CUPS prüft die Zugriffsrechte und setzt diese bei jdem Neustart auf vernünftige Werte. Wir haben schon ziemlich viele Leute gesehen, die ein gemeinsames Spooling-Verzeichnis verwendet haben und wochenlang mit diesem „Problem“ zu kämpfen hatten.

Ein Windows-Benutzer authentifiziert sich nur gegenüber Samba (mittels dessen, was konfiguriert wurde). Wenn Samba auf demselben Host wie CUPS läuft, brauchen Sie nur dem Rechner „localhost“ das Drucken zu erlauben. Wenn Samba und CUPS auf verschiedenen Maschinen laufen, müssen Sie sicherstellen, dass der Samba-Host Zugriff auf das Drucken auf CUPS hat.

CUPS beschränkt sich in seiner Verwendung von PPDs nicht auf „wirkliche“ PostScript-Drucker. Die CUPS-Entwickler haben die Reichweite des PPD-Konzepts erweitert, um auch verfügbare Geräte- und Treiber-Optionen von Nicht-PS-Druckern durch CUPS-PPDs zu beschreiben.

Dies ist nur logisch, da CUPS einen voll ausgestatteten PostScript Interpreter (RIP) umfasst. Dieser RIP basiert auf Ghostscript. Er kann alles empfangene PostScript (und zusätzlich viele weitere Dateiformate) verarbeiten. Alle CUPS-PPDs für Nicht-PS-Drucker enthalten eine zusätzliche Zeile, die mit dem Schlüsselwort *cupsFilter beginnt. Diese Zeile teilt dem CUPS-Druck-System mit, welcher druckerspezifische Filter zur Interpretation der PostScript-Daten verwendet werden soll. Daher lässt CUPS alle seine Drucker für die Clients als PostScript-Drucker erscheinen, weil es als PostScript-RIP für diese Drucker arbeiten kann.

CUPS-PPDs können auch auf Windows-Clients verwendet werden, auf dem „Rücken“ eines „core“-PostScript-Treibers (derzeit wird der „CUPS PostScript Driver for Windows NT/200x/XP“ empfohlen; Sie können auch den von Adobe verwenden, allerdings mit Einschränkungen). Dieses Feature ermöglicht es CUPS, einige Tricks zu beherrschen, die kein anderer Spooler kann:

Die Verwendung von CUPS-PPDs auf Windows-Clients ermöglicht es diesen, alle Druckauftragseinstellungen so zu kontrollieren, wie es ein UNIX-Client kann.

In Windows NT bringen Drucker-Treiber, die im „Kernel-Modus“ laufen, ein hohes Risiko für die Stabilität des Systems mit sich, wenn der Treiber nicht wirklich stabil und gut getestet ist. Und es gibt eine Menge schlechte Treiber! Speziell berüchtigt ist das Beispiel des PCL-Drucker-Treibers, der ein zusätzliches Sound-Modul ausführte, das die Benutzer via Soundkarte über ihre abgeschlossenen Druckaufträge informierte. Muss ich wirklich erwähnen, dass dies genauso verlässlich „blue screens of death“ verursachte?

PostScript-Treiber sind im Allgemeinen gut getestet. Sie sind nicht dafür bekannt, irgendwelche Probleme zu verursachen, sogar obwohl sie auch im Kernel-Modus ausgeführt werden. Das kann daher kommen, dass es bislang nur zwei verschiedene PostScript-Treiber gab: die von Adobe und den von Microsoft. Beide sind gut getestet und so stabil, wie es unter Windows eben geht. Der CUPS-Treiber ist von dem MS-Treiber abgeleitet.

In vielen Fällen haben Administratoren in dem Bestreben, dieses Problem zu umgehen, die erlaubten Druckertreiber auf ihrem WTS auf einen generischen PCL- und einen PostScript-Treiber beschränkt. Dies schränkt jedoch die Clients im Umfang der ihnen zur Verfügung stehenden Druckoptionen ein. Oft bekommen Sie nicht mehr als Simplex-Druck aus einem Standard-Papierschacht, während Ihre Geräte bei weitem mehr könnten, wenn sie von einem besseren Treiber angesteuert würden!

Das Verwenden eines Postscript-Treibers, der mit einem CUPS-PPD aktiviert wurde, scheint eine sehr elegante Art zu sein, all diese Mängel zu überbrücken. Es gibt, je nach der von Ihnen verwendeten Windows-Version, bis zu drei verschiedene verfügbare Postscript-Treiber: Adobe, Microsoft und CUPS-Postscript-Treiber. Keiner der drei ist bekannt dafür, größere Instabilitäten auf WTS zu verursachen (auch nicht, wenn viele verschiedene PPDs verwendet werden). Die Clients werden (wieder) imstande dazu sein, Papierschächte auszuwählen, Duplexdruck und andere Einstellungen auszuführen. Dies hat jedoch auch seinen Preis: Ein CUPS-Server, der als PostScript-RIP für seine Clients arbeitet, erfordert mehr CPU und RAM, als wenn er nur als „raw spooling“-Server arbeitet. Außerdem ist dieses Setup noch nicht ausführlich getestet, wobei die ersten Rückmeldungen sehr vielversprechend aussehen.

Aktuellere Drucker-Treiber unter W200x und XP laufen nicht mehr im Kernel-Modus (anders als unter Windows NT). Beide Betriebssysteme können jedoch die NT-Treiber verwenden, die im Kernel-Modus laufen. (Sie können grob bestimmen, welcher Treiber zu welchem System gehört, da die Treiber im Unterverzeichnis „2“ des Verzeichnisses „W32X86“ die „alten“ sind.) Wie zuvor gesagt wurde, sind weder die Adobe-Treiber noch die von MS dafür bekannt, irgendwelche Stabilitätsprobleme zu verursachen. Der CUPS-Treiber wurde vom MS-Treiber abgeleitet. Es gibt einen einfachen Grund dafür: Das MS DDK (Device Development Kit) für Windows NT (das für Lizenznehmer von Visual Studio ohne Kosten verfügbar war) beinhaltet den Quelltext des MS-Treibers, und die Lizenznehmer von Visual Studio dürfen diesen verwenden und ihn für eigene Treiber-Entwicklungen modifizieren. Das haben die CUPS-Entwickler getan. Die Lizenz erlaubt ihnen nicht, den gesamten Quelltext zu veröffentlichen, sie haben jedoch das „diff“ unter der GPL veröffentlicht, und wenn Sie Besitzer eines „MS DDK for Windows NT“ sind, können Sie den Treiber selbst prüfen.

Das Werkzeug cupsaddsmb (das mit allen aktuellen CUPS-Versionen ausgeliefert wird) ist eine alternative Methode, um Druckertreiber in die Samba-Freigabe [print$] zu transferieren. Zur Erinnerung: Diese Freigabe ist der Ort, an dem Clients nach hinterlegten und konfigurierten Treibern suchen, um diese herunterzuladen und zu installieren. Dies macht das Verteilen von jeglichen (oder allen) installierten CUPS-Druckern ziemlich einfach. cupsaddsmb kann den Adobe PostScript-Treiber genauso verwenden wie den neu entwickelten CUPS-PostScript-Treiber für Windows NT/200x/XP. cupsaddsmb funktioniert NICHT mit beliebigen Druckertreibern, sondern nur mit exakt den Treiber-Dateien, die in seiner Manpage angegeben sind.

Der CUPS-Druckertreiber ist auf der CUPS-Download-Seite verfügbar. Sein Paketname ist cups-samba-[version].tar.gz. Er wird den Adobe-Treibern vorgezogen, da er einige Vorteile hat:

Derzeit werden jedoch nur Windows NT, 2000 und XP von den CUPS-Treibern unterstützt. Sie brauchen auch die entsprechenden Teile des Adobe-Treibers, wenn Sie Windows 95-, 98- und ME-Clients unterstützen müssen.

Vor dem Ausführen von cupsaddsmb müssen Sie die Einstellungen in smb.conf wie im nächsten Beispiel setzen:

CUPS-Anwender können die genau gleichen Pakete von http://www.cups.org/software.html beziehen. Dies ist ein separates Paket von CUPS-Software-Dateien, das als „CUPS 5.0rc3 Windows NT/200x/XP Printer Driver for Samba“ bezeichnet wird. Der Dateiname für den Download ist cups-samba-5.0rc3.tar.gz. Nach dem untar und unzip zeigen sich folgende Dateien:

root# tar xvzf cups-samba-5.0rc3.tar.gz
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss

Diese Dateien wurden mit der ESP-Meta-Packer-Software EPM gepackt. Die Dateien *.install und *.remove sind einfache Shell-Skripten, die die Datei *.ss entpacken (die Datei *.ss ist nichts als ein tar-Archiv, das auch mit „tar“ entpackt werden kann). Dann kopiert sie deren Inhalt in /usr/share/cups/drivers/. Dieser Inhalt enthält drei Dateien:

root# tar tv cups-samba.ss
cupsdrvr.dll
cupsui.dll
cups.hlp

Das Shell-Skript cups-samba.install ist einfach anzuwenden:

root# ./cups-samba.install
[....]
Installing software...
Updating file permissions...
Running post-install commands...
Installation is complete.     

Das Skript sollte die Treiber-Dateien automatisch ins Verzeichnis /usr/share/cups/drivers/ kopieren.

root# cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/

Dieser neue CUPS-PostScript-Treiber ist derzeit nur binär verfügbar, ist aber kostenlos. Es wird (noch) kein vollständiger Quelltext zur Verfügung gestellt. Der Grund ist, dass er mit Hilfe des Microsoft Driver Developer Kits (DDK) entwickelt und mit Microsoft Visual Studio 6 kompiliert wurde. Die Treiber-Entwickler dürfen nicht den gesamten Quelltext als freie Software vertreiben. Die CUPS-Entwickler haben jedoch das „diff“ unter der GPL veröffentlicht, somit kann jeder mit einer Lizenz für Visual Studio und einem DDK den Treiber selbst kompilieren.

Die CUPS-Treiber unterstützen die älteren Systeme Windows 95/98/Me nicht, nur die Client-Systeme Windows NT/2000/XP.

Windows NT, 2000 und XP werden unterstützt von:

Adobe-Treiber sind für die älteren Systeme Windows 95/98/Me genauso verfügbar wie für Windows NT/2000/XP. Die Dateien sind für die einzelnen Plattformen verschieden.

Windows 95, 98 und ME werden unterstützt von:

Windows NT, 2000 und XP werden unterstützt von:

Das Beschaffen der Adobe-Treiber-Dateien scheint für viele Anwender unerwartet schwierig zu sein. Sie sind nicht als einzelne Dateien auf der Adobe-Website erhältlich, und die selbstentpackende und/oder selbstinstallierende Windows-.exe-Datei ist auch nicht einfach zu finden. Möglicherweise müssen Sie den enthaltenen Installer verwenden und die Installation einmal auf einem Client durchführen. Dies installiert die Treiber (und einen generischen PostScript-Drucker) lokal auf dem Client. Wenn diese installiert sind, geben Sie den generischen PostScript-Drucker frei. Danach enthält die Freigabe [print$] des Clients die Adobe-Dateien, von wo aus Sie sie mittels smbclient auf den CUPS-Host holen können.

Die Anwender der Software ESP Print Pro können ihr Samba-Treiber-Paket für diesen Zweck ohne Probleme installieren. Beziehen Sie die Treiber-Dateien aus dem normalen Download-Bereich der ESP Print Pro-Software unter http://www.easysw.com/software.html. Sie müssen den Link namens „SAMBA“ unter Download Printer Drivers for ESP Print Pro 4.x finden und das Package herunterladen. Sobald es instaliert ist, können Sie jeden Treiber vorbereiten, indem Sie einfach den Drucker im Drucker-Manager-GUI markieren und die Funktion Export Driver... aus dem Menü wählen. Natürlich müssen Sie Samba zuerst für den Umgang mit den Treiber-Dateien vorbereitet haben, also die Freigabe [print$] angelegt haben und so weiter. Das Paket ESP Print Pro beinhaltet die CUPS-Treiber-Dateien genauso wie ein (lizenziertes) Set von Adobe-Treibern für die Windows 95/98/Me-Client-Familie.

Sobald Sie das Install-Skript ausgeführt haben (und eventuell die Datei cups.hlp manuell nach /usr/share/cups/drivers/ verschoben haben), kann der Treiber in die Samba-Freigabe [print$] gelegt werden (die oft auf das Verzeichnis /etc/samba/drivers/ zeigt und einen Unterverzeichnis-Baum mit den Verzeichnissen WIN40 und W32X86 enthält). Sie tun dies, indem Sie cupsaddsmb ausführen (sehen Sie dazu auch man cupsaddsmb, für alle CUPS-Releases seit 1.1.16).

Sobald die Treiber-Dateien in der Freigabe [print$] liegen und initialisiert sind, können sie von den Windows NT/200x/XP Clients heruntergeladen und installiert werden.

Interessiert Sie ein Vergleich des CUPS- und des Adobe-Treibers? Für unsere Zwecke sind dies die wichtigsten Punkte, die für den CUPS-Treiber sprechen:

Der Befehl cupsaddsmb kopiert die benötigten Dateien in Ihre Freigabe [print$]. Zusätzlich wird das mit dem Drucker assoziierte PPD von /etc/cups/ppd/ in [print$] kopiert. Dort warten diese Dateien auf praktische Windows-Client-Installationen via Point'n'Print. Bevor wir den Befehl erfolgreich ausführen können, müssen wir sicher sein, dass wir uns am Samba-Server authentifizieren können. Wenn Sie ein kleines Netzwerk haben, verwenden Sie möglicherweise User-level-Sicherheit (security = user).

Hier ein Beispiel für ein erfolgreich ausgeführtes cupsaddsmb:

root# cupsaddsmb -U root infotec_IS2027
Password for root required to access localhost via Samba: ['secret']

Um alle Drucker und Treiber freizugeben, verwenden Sie den Parameter -a anstatt des Drucker-Namens. Da cupsaddsmb die Druckertreiber an Samba „exportiert“, sollte es offensichlich sein, dass es nur für Queues funktioniert, mit denen ein CUPS-Treiber assoziiert ist.

Vielleicht wollen Sie ja sehen, was passiert. Verwenden Sie den Parameter -v, um einen vollständigeren Report über das Geschehene zu erhalten. Das folgende Beispiel wurde zwecks besserer Lesbarkeit editiert; alle „\“ an den Zeilenenden zeigen an, dass ich einen zusätzlichen Zeilenumbruch samt Einrückung hinzugefügt habe:

root# cupsaddsmb -U root -v infotec_2105
Password for root required to access localhost via GANDALF:
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
    -c 'mkdir W32X86; \
    put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \
	put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \
    put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \
    put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd
putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll
putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll
putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp

Running command: rpcclient localhost -N -U'root%secret'
   -c 'adddriver „Windows NT x86“   \
   „infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
    RAW:NULL“'
cmd = adddriver „Windows NT x86“ \
   „infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
	RAW:NULL“
Printer Driver infotec_2105 successfully installed.

Running command: smbclient //localhost/print\$ -N -U'root%secret' \
-c 'mkdir WIN40; \
    put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \
	put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;   \
    put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \
    put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \
    put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \
	put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \
	put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
  added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
  Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
  NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
  putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD
  putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM
  putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV
  putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP
  putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD
  putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL
  putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL

  Running command: rpcclient localhost -N -U'root%secret' \
   -c 'adddriver „Windows 4.0“      \
   „infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \
   PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \
    ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL“'
	cmd = adddriver „Windows 4.0“ „infotec_2105:ADOBEPS4.DRV:\
	infotec_2105.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\
	infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\
	ICONLIB.DLL“
  Printer Driver infotec_2105 successfully installed.

  Running command: rpcclient localhost -N -U'root%secret'  \
   -c 'setdriver infotec_2105 infotec_2105'
  cmd = setdriver infotec_2105 infotec_2105
  Successfully set infotec_2105 to driver infotec_2105.

Wenn Sie genau hinsehen, werden Sie entdecken, dass Ihr root-Passwort unverschlüsselt übers Netz übertragen wurde, also geben Sie Acht! Wenn Sie weiterlesen, entdecken Sie Fehlermeldungen wie NT_STATUS_OBJECT_NAME_COLLISION . Diese treten auf, weil die Verzeichnisse WIN40 und W32X86 bereits in der Freigabe [print$] existiert haben (von einer früheren Treiber-Installation). Diese Meldungen sind in diesem Zusammenhang harmlos.

Was ist passiert? Was hat cupsaddsmb gemacht? Es gibt fünf Stufen in dieser Prozedur:

root# cupsaddsmb -H sambaserver -h cupsserver -v drucker

Sie müssen immer überprüfen, dass das Werkzeug in allen Bereichen erfolgreich gearbeitet hat. Sie brauchen zumindest diese drei Meldungen in der Ausgabe von cupsaddsmb:

Diese Meldungen sind eventuell nicht ganz leicht in der gesamten Ausgabe zu erkennen. Wenn Sie cupsaddsmb mit dem Parameter -a ausführen (der versucht, alle aktiven CUPS-Druckertreiber für den Download vorzubereiten), könnten Sie übersehen, dass einzelne Druckertreiber Probleme bei der Installation hatten. Hier hilft eine Umleitung der Ausgabe bei der nachträglichen Analyse der Ergebnisse.

Wenn Sie Folgendes erhalten:

SetPrinter call failed!
result was WERR_ACCESS_DENIED

bedeutet das, dass Sie eventuell use client driver = yes für diesen Drucker gesetzt haben. Setzen Sie dies auf „no“, das wird das Problem lösen. Sehen Sie sich man samba(5) für die Erklärung des Parameters use client driver an.

Schaffen Sie es nicht, den Standard-Befehl cupsaddsmb auf einem Samba-PDC erfolgreich auszuführen? Werden Sie immer und immer wieder nach dem Passwort gefragt, und wird der Befehl nicht einmal gestartet? Versuchen Sie eine dieser Varianten:

root# cupsaddsmb -U MITTELERDE\\root -v druckername
root# cupsaddsmb -H SAURON -U MITTELERDE\\root -v druckername
root# cupsaddsmb -H SAURON -U MITTELERDE\\root -h cups-server -v druckername

(Beachten Sie die zwei Backslashes: Der erste wird benötigt, um das „escaping“ des zweiten zu bewirken).

cupsaddsmb-Flussdiagramm(((Abbildung Nummer?))) zeigt eine grafische Darstellung der Abläufe, Befehlsketten und Datenflüsse des Befehls cupaddsmb. Nochmals zur Erinnerung: cupsaddsmb ist nicht für Raw-Queues gedacht und arbeitet nicht mit Raw-Queues!

Abbildung 19.16. cupsaddsmb-Flussdiagramm

Nachdem cupsaddsmb beendet wurde, ist Ihr Treiber vorbereitet, um von den Clients verwendet zu werden. Hier sind die Schritte, die Sie durchführen müssen, um den Treiber via Point'n'Print herunterzuladen und zu installieren. Auf dem Windows-Client wählen Sie den CUPS/Samba-Server:

Ein paar Sekunden später sollte es einen neuen Drucker im lokalen Ordner Drucker und Faxgeräte Ihres Clients geben. Unter Windows XP wird er der Namenskonvention von DruckerName auf SambaServer entsprechen. (In meinem momentanen Fall ist es „infotec_2105 auf kde-bitshop“). Wenn Sie diesen Drucker testen wollen und Ihren ersten Auftrag aus einer Anwendung wie Winword senden wollen, erscheint der neue Drucker als Eintrag # \\SambaServer\DruckerName im Dropdown-Menü der verfügbaren Drucker.

cupsaddsmb arbeitet nur zuverlässig mit CUPS-Versionen ab 1.1.15 und Samba-Versionen ab 2.2.4. Wenn es nicht funktioniert oder wenn der automatische Drucker-Download auf die Clients nicht erfolgreich verläuft, können Sie den CUPS-Treiber immer noch manuell über den Adobe-PostScript-Treiber auf den Clients installieren. Dann lassen Sie, wenn Sie die CUPS-Netzwerk-RIP-Funktionalitäten nutzen möchten, die Queue auf die Samba-Freigabe zeigen, um eine UNC-Verbindung zu erreichen:

C:\> net use lpt1: \\sambaserver\druckerfreigabe /user:ntadmin

(Beachten Sie, dass der Benutzer „ntadmin“ ein gültiger Samba-Benutzer mit den erforderlichen Rechten sein muss.) Dies installiert die Druckerverbindung in klassischer LanMan-Weise (und verwendet dabei kein MS-RPC).

Das Drucken funktioniert, aber es gibt immer noch Probleme. Die meisten Aufträge drucken sehr gut, aber einige drucken gar nicht. Manche Aufträge haben Probleme mit den Schriftarten, die nicht besonders gut aussehen. Manche Aufträge werden schnell gedruckt, manche sind unglaublich langsam. Viele dieser Probleme können minimiert oder überhaupt komplett beseitigt werden, wenn Sie ein paar Richtlinien befolgen. Denken Sie an Folgendes: Wenn Ihr Drucker nicht PostScript-befähigt ist, beschicken Sie Ihre Ghostscript-Installation auf Ihrem CUPS-Host mit dem Output, den die Einstellungen des Treibers auf Ihrem Client erzeugen. Behandeln Sie Ghostscript gut:

Lassen Sie uns zuerst die Manpage zu rpcclient prüfen. Hier sind zwei relevante Abschnitte:

adddriver <arch> <config>: Führe ein AddPrinterDriver()-RPC aus, um den Druckertreiber auf dem Server zu installieren. Die Treiber sollten bereits in dem Verzeichnis existieren, das von getdriverdir zurückgegeben wird. Mögliche Werte für arch sind dieselben wie für getdriverdir. Der Parameter config ist wie folgt definiert:

Long Printer Name:\
Driver File Name:\
Data File Name:\
Config File Name:\
Help File Name:\
Language Monitor Name:\
Default Data Type:\
Comma Separated list of Files

Alle leeren Felder sollten als String „NULL“ angegeben werden.

Samba muss das Konzept der Druck-Monitore nicht unterstützen, da dieses nur auf lokale Drucker anzuwenden ist, deren Treiber eine bidirektionale Verbindung zur Kommunikation mit dem Drucker nutzen können. Dieses Feld sollte „NULL“ sein. Auf einem entfernten NT-Druck-Server muss der Druck-Monitor für einen Treiber bereits installiert sein, bevor man den Treiber hinzufügt, oder das RPC wird scheitern.

setdriver <printername> <drivername>: Führe einen Befehl SetPrinter() aus, um den mit einem Drucker assoziierten Treiber zu aktualisieren. Der Druckertreiber muss bereits korrekt auf dem Druck-Server installiert sein.

Beachten Sie auch die Befehle enumprinters und enumdrivers für das Abfragen einer Liste von installierten Druckern und Treibern.

Das exakte Format wird nicht allzu klar von der Manpage beschrieben, da Sie einige Parametern benutzen müssen, die Leerzeichen enthalten. Hier ist eine bessere Beschreibung dafür. Wir haben den Befehl mit Zeilenumbrüchen versehen und die Umbrüche mit „\“ gekennzeichnet. Üblicherweise würden Sie diesen Befehl ohne die Umbrüche in einer Zeile eingeben:

 adddriver „Architecture“ \
           „LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
           LanguageMonitorFile:DataType:ListOfFiles,Comma-separated“

Was die Manpage als ein simples <config>-Schlüsselwort bezeichnet, besteht in Wirklichkeit aus acht durch Doppelpunkte getrennten Feldern. Das letzte Feld kann mehrere (in manchen sehr ausgefallenen Fällen bis zu 20 zusätzliche) Dateinamen enthalten. Dies mag anfangs sehr verwirrend klingen. Was die Manpages als „LongPrinterName“ bezeichnen, sollte in der Realität als „Driver Name“ bezeichnet werden. Sie können es bezeichnen, wie Sie wollen, solange Sie diesen Namen später im Befehl rpcclient ... setdriver wieder verwenden. Aus praktischen Gründen empfiehlt es sich, den Treiber so zu benennen wie den Drucker.

Es ist überhaupt nicht einfach. Ich höre Sie fragen: „Wie weiß ich, welche Dateien ‚Driver File‘, ‚Data File‘, ‚Config File‘, ‚Help File‘ und ‚Language Monitor File‘ im jeweiligen Fall sind?“ Um eine Antwort zu finden, können Sie sich ja mal ansehen, wie eine Windows NT-Maschine mit einem freigegebenen Drucker uns diese Dateien anbietet. Erinnern Sie sich, dass diese ganze Prozedur vom Samba-Team durch Abhören des Verkehrs, der von Windows-Computern im Netzwerk verursacht wird, entwickelt werden muss. Wir können uns nun genauso einer Windows-Maschine zuwenden und auf sie von einer UNIX-Workstation aus zugreifen. Wir werden sie mit rpcclient abfragen, um zu sehen, was sie uns erzählt, und versuchen, die Manpage klarer zu verstehen, die wir gerade gelesen haben.

Wir könnten rpcclient mit einem getdriver- oder getprinter-Sub-Befehl (in Level-3-Ausführlichkeit) an die Windows-Maschine absetzen. Setzen Sie sich einfach an eine UNIX- oder Linux-Workstation mit installierten Samba-Werkzeugen, und tippen Sie folgenden Befehl:

root# rpcclient -U'user%secret' NT-SERVER -c 'getdriver printername 3'

Aus dem Ergebnis sollte klarwerden, welche Detai welche ist. Hier ein Beispiel aus meiner Installation:

root# rpcclient -U'Danka%xxxx' W200xSERVER \
	-c'getdriver „DANKA InfoStream Virtual Printer“ 3'
 cmd = getdriver „DANKA InfoStream Virtual Printer“ 3

 [Windows NT x86]
 Printer Driver Info 3:
         Version: [2]
         Driver Name: [DANKA InfoStream]
         Architecture: [Windows NT x86]
         Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL]
         Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD]
         Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL]
         Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP]

         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []

         Monitorname: []
         Defaultdatatype: []

Manche Druckertreiber listen zusätzliche Dateien unter der Bezeichnung Dependentfiles auf, und diese würden im letzten Feld ListOfFiles,Comma-separated angeführt werden. Für den CUPS-PostScript-Treiber brauchen wir keine (und auch für die Adobe-Treiber würden wir keine brauchen), daher erhält dieses Feld den Eintrag „NULL“.

Aus der Manpage (und der oben zitierten Ausgabe von cupsaddsmb) wird klar, dass Sie bestimmte Bedingungen erfüllen müssen, um das manuelle Hochladen und Initialisieren von Treibern erfolgreich zu ermöglichen. Die beiden Sub-Befehle rpcclient und (adddriver und setdriver) müssen folgende Bedingungen erfüllen, um erfolgreich ausgeführt zu werden:

Wir werden jetzt einen Druckertreiber installieren, indem wir manuell alle erforderlichen Befehle ausführen. Da dies zuerst als ziemlich komplizierter Prozess erscheinen mag, gehen wir die Prozedur Schritt für Schritt durch, und erklären jede einzelne Aktion, die vorkommt.

Der Befehl setdriver wird scheitern, wenn in Sambas „Bewusstsein“ die Queue noch nicht vorhanden ist. Sie hatten viel versprechende Meldungen wie

 Printer Driver ABC successfully installed.

nach dem Abschnitt mit adddriver? Aber Sie sehen auch eine enttäuschende Meldung wie diese hier?

result was NT_STATUS_UNSUCCESSFUL

Es reicht nicht aus, dass Sie mit dem Befehl lpstat -p ir85wm die Queue in CUPS sehen können. Ein Bug in den neueren Versionen von Samba verhindert ein ordnungsgemäßes Update der Queue-Liste. Die Erkennung von neu installierten CUPS-Druckern scheitert, bis Sie Samba neu starten oder ein HUP an alle smbd-Prozesse senden. Um zu prüfen, ob dies der Grund dafür ist, dass Samba den Befehl setdriver nicht erfolgreich ausführt, prüfen Sie, ob Samba den Drucker „sieht“:

root# rpcclient transmeta -N -U'root%xxxx' -c 'enumprinters 0'|grep ir85wm
        printername:[ir85wm]

Ein anderer Befehl könnte der hier sein:

root# rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' 
        cmd = getprinter ir85wm
        flags:[0x800000]
        name:[\\transmeta\ir85wm]
        description:[\\transmeta\ir85wm,ir85wm,DPD]
        comment:[CUPS PostScript-Treiber for Windows NT/200x/XP]

Übrigens, Sie können diese Befehle (sowie einige weitere) natürlich auch dazu verwenden, Treiber auf entfernten Windows-NT-Druckservern zu installieren!

Ein Windows NT-(Druck-)Server führt Buch über alle benötigten Informationen, die er zur Erfüllung seiner Pflichten gegenüber den Clients benötigt, indem er Einträge in der Windows-Registrierung speichert. Client-Anfragen werden beantwortet, indem aus der Registrierung gelesen wird, und Administrator- oder Benutzer-Konfigurationseinstellungen werden gespeichert, indem in die Registrierung geschrieben wird. Samba und UNIX haben natürlich keine solche Registrierung. Samba führt stattdessen Buch über alle client-bezogenen Informationen, indem es eine Reihe von *.tdb-Dateien verwendet. (TDB = Trivial Data Base). Diese sind oft in /var/lib/samba/ oder /var/lock/samba/ abgelegt. Die druck-bezogenen Dateien sind ntprinters.tdb, printing.tdb, ntforms.tdb und ntdrivers.tdb.

*.tdb-Dateien sind nicht für den Menschen lesbar. Sie sind in einem binären Format geschrieben. „Warum nicht in ASCII?“, könnten Sie fragen. „ASCII-Dateien sind doch eine gute und bewährte Tradition unter UNIX.“ Der Grund für diese Design-Entscheidung ist hauptsächlich die Performance. Samba muss schnell laufen; es führt für jede Client-Verbindung einen separaten smbd-Prozess aus, in manchen Umgebungen viele Tausende davon. Manche smbds könnten Schreibzugriff auf dieselbe *.tdb-Datei zur gleichen Zeit brauchen. Das Dateiformat der *.tdb-Dateien von Samba erlaubt dies; viele smbd-Prozesse können gleichzeitig in dieselbe *.tdb-Datei schreiben. Dies wäre mit reinen ASCII-Dateien nicht möglich.

Es ist sehr wichtig, dass alle *.tdb-Dateien über alle Lese- und Schreibzugriffe hinweg konsistent bleiben. Es kann jedoch passieren, dass diese Dateien beschädigt werden. (Ein kill -9 `pidof smbd' während eines Schreibzugriffs könnte genauso gut dafür verantwortlich sein wie ein Stromausfall etc.). Im Falle von Schwierigkeiten kann das Löschen der alten druckbezogenen *.tdb-Dateien die einzige Möglichkeit sein. Danach müssen Sie alle druckbezogenen Einstellungen wieder herstellen, oder Sie haben rechtzeitig ein Backup der relevanten Dateien erstellt.

Samba enthält ein kleines Hilfsmittel, das dem root-Benutzer Ihres Systems hilft, die *.tdb-Dateien zu sichern. Wenn Sie es ohne Argumente ausführen, gibt es Auskunft über seine Verwendung:

root# tdbbackup
 Usage: tdbbackup [options] <fname...>

 Version:3.0a
   -h            this help message
   -s suffix     set the backup suffix
   -v            verify mode (restore if corrupt)

Hier sehen Sie, wie ich meine Datei printing.tdb gesichert habe:

root# ls
.              browse.dat     locking.tdb     ntdrivers.tdb printing.tdb
..             share_info.tdb connections.tdb messages.tdb  ntforms.tdb
printing.tdbkp unexpected.tdb brlock.tdb      gmon.out      namelist.debug
ntprinters.tdb sessionid.tdb

root# tdbbackup -s .bak printing.tdb
 printing.tdb : 135 records

root# ls -l printing.tdb*
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb.bak

Heutzutage verwenden die meisten Linux-Distributionen die Werkzeuge von Linuxprinting.org, um ihre druckerspezifische Software aufzubauen (die übrigens auch auf allen UNIX-Versionen und auch auf Mac OS X oder Darwin läuft). Es ist nicht so bekannt, wie es sein sollte, dass es auch ein sehr benutzerfreundliches Interface hat, das einfache Updates von Treibern und PPDs für alle unterstützten Drucker, alle Spooler, alle Betriebssysteme und alle Paketformate erlaubt (weil es keines gibt)(((?))). Seine Geschichte reicht schon einige Jahre zurück.

Erst unlängst hat Foomatic den erstaunlichen Meilenstein von 1000 gelisteten Druckermodellen geschafft. Linuxprinting.org speichert alle wichtigen Fakten über Druckertreiber und unterstützte Modelle sowie Informationen darüber, welche Optionen für die verschiedenen Treiber/Drucker-Kombinationen verfügbar sind, in seiner Foomatic-Datenbank. Momentan gibt es 245 Treiber in der Datenbank. Viele Treiber unterstützen verschiedene Modelle, und viele Modelle können mit verschiedenen Treibern betrieben werden Sie haben die Wahl!

Hier sind die erforderlichen Schritte, um einen von foomatic-rip betriebenen LaserJet 4 Plus-kompatiblen Drucker in CUPS zu installieren. (Beachten Sie, dass aktuelle Distributionen von SuSE, UnitedLinux und Mandrake möglicherweise mit einem kompletten Package von Foomatic-PPDs geliefert werden, plus dem Werkzeug foomatic-rip. Der Besuch von Linuxprinting.org stellt sicher, dass Sie die aktuellsten Treiber und PPD-Dateien haben.)

Sobald Sie in eine Queue drucken, die mit dem Foomatic-PPD installiert wurde, fügt CUPS die entsprechenden Befehle und Kommentare in die resultierende PostScript-Datei ein. foomatic-rip kann diese lesen und mit ihnen umgehen, und verwendet einige speziell codierte Foomatic-Kommentare, die in die Auftragsdatei eingebettet sind. Diese werden wiederum dazu verwendet (transparent für Sie, den Anwender), um die komplizierte Ghostscript-Befehlszeile zu konstruieren, die dem Druckertreiber exakt mitteilt, wie die ausgegebenen Rasterdaten auszusehen haben und welche Druckerbefehle in den Datenstrom einzubetten sind. Sie brauchen:

Dies ist ein Beispiel, wie root ein Druck-Quotum in CUPS einrichten könnte, unter der Annahme, dass es einen Drucker namens „quotadrucker“ gibt:

root# lpadmin -p quotadrucker -o job-quota-period=604800 \
	-o job-k-limit=1024 -o job-page-limit=100

Dies würde jeden einzelnen Benutzer darauf beschränken, 100 Seiten oder 1024 KB (was auch immer zuerst eintrifft) innerhalb der letzten 604800 Sekunden (entspricht einer Woche) zu drucken.

Damit CUPS richtig zählt, muss die Druckdatei durch den CUPS-pstops-Filter laufen; ansonsten verwendet es einen Ersatzwert von „eins“. Manche Druckdateien passieren diesen Filter nicht (z.B. Bilddateien), jedoch sind diese ohnehin meist einseitige Aufträge. Das bedeutet: Aufträge von proprietären Treibern (die auf den Clients laufen), die von CUPS/Samba als „raw“ weitergegeben werden (also ohne Filterung), werden auch als einseitige Aufträge gezählt!

Sie müssen PostScript von den Clients senden (d.h., dort einen PostScript-Treiber ausführen), um eine Chance auf korrekte Abrechnung zu bekommen. Wenn der Drucker ein Nicht-PS-Modell ist, müssen Sie CUPS die Wandlung der Auftragsdatei in ein druckfertiges Format für den Zieldrucker durchführen lassen. Dies funktioniert derzeit für ungefähr eintausend verschiedene Druckermodelle. Linuxprinting hat eine Treiber- Liste.

Vor CUPS 1.1.16 hatten Sie nur diee Option, den Adobe-PostScript-Treiber auf den Windows-Clients zu verwenden. Die Ausgabe dieses Treibers wurde auf der Seite von CUPS/Samba nicht immer durch den pstops-Filter geschleust und daher auch nicht korrekt gezählt. (Das lag daran, dass oft, abhängig vom verwendeten PPD, ein PJL-Header vor das tatsächliche PostScript gesetzt wurde, was CUPS zum Überspringen von pstops veranlasste und es direkt zum pstoraster-Schritt brachte).

Seit CUPS 1.1.16 können Sie den CUPS-PostScript-Treiber für Windows NT/200x/XP-Clients verwenden (der im Download-Bereich von http://www.cups.org/ als cups-samba-1.1.16.tar.gz zu finden ist). Er funktioniert nicht für Windows 9x/ME-Clients, garantiert jedoch:

Sie können mehr über das Setup dieser Kombination in der Manpage für cupsaddsmb lesen (die nur vorhanden ist, wenn CUPS installiert ist, und nur aktuell seit CUPS 1.1.16 ist).

CUPS protokolliert in page_log für jede Seite eines Auftrags folgende Punkte:

Hier sehen Sie einen Auszug aus der Datei page_log meines CUPS-Servers, um das Format und die enthaltenen Begriffe zu illustrieren:

tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33

Dies war die Auftrags-ID 401, die auf tec_IS2027 vom Benutzer kurt gedruckt wurde: ein 64-Seiten-Auftrag, der in 3 Kopien gedruckt, #marketing in rechnung gestellt und von der IP-Adresse 10.160.50.13. gesendet wurde. Der nächste Auftrag hatte die ID 402, wurde vom Benutzer boss von der IP-Adresse 10.160.51.33 gesendet, druckte von einer Seite 440 Kopien und soll finance-dep in Rechnung gestellt werden.

Welche Mängel gibt es bei diesem Quota-System?

Dies ist das beste derzeit verfügbare System, und es gibt bedeutende Verbesserungen, die in Entwicklung für CUPS 1.2 sind:

Einige wichtige Parameter in der CUPS-Konfigurationsdatei cupsd.conf sind:

(Es gibt auch noch zusätzliche Einstellungen für MaxJobsPerUser und MaxJobsPerPrinter...)

Damit alles so funktioniert wie besprochen, brauchen Sie drei Dinge:

Wenn Sie Dinge manuell tun wollen, ersetzen Sie printing = cups durch printing = bsd. Dann kann Ihr manuell gesetzter Befehlssatz funktionieren (ich habe das nicht getestet), und print command = lp -d %P %s; rm %s könnte das tun, was Sie brauchen.

Für Windows 9x/ME benötigen die Clients Druckernamen, die maximal acht Zeichen lang sind (oder „8 plus 3 Zeichen Suffix“); andernfalls werden die Treiberdateien nicht übertragen, wenn Sie sie von Samba herunterladen wollen.

Verwenden Sie security = user? Haben Sie smbpasswd verwendet, um root ein Samba-Konto zu geben? Sie können zwei Dinge tun: ein anderes Terminal öffnen und smbpasswd -a root ausführen, um das Konto anzulegen und im ersten Terminal damit fortfahren, das neue Passwort dort einzugeben. Oder Sie brechen die Schleife ab, indem Sie zweimal ENTER drücken (ohne zu versuchen, ein Passwort einzugeben).

Wenn der Fehler „tree connect failed: NT_STATUS_BAD_NETWORK_NAME“ lautet, haben Sie vielleicht vergessen, das Verzeichnis /etc/samba/drivers anzulegen.

Die Verwendung von „cupsaddsmb“ führt zur Meldung „No PPD file for printer...“, obwohl die Datei vorhanden ist. Was kann das Problem sein?

Haben Sie die Drucker-Freigabe in CUPS aktiviert? Das heißt, haben Sie einen Abschnitt <Location /printers>....</Location> in der Datei cupsd.conf Ihres CUPS-Servers, die dem Host, von dem aus Sie „cupsaddsmb“ auszuführen versuchen, den Zugriff erlaubt? Es könnte ein Problem sein, wenn Sie cupsaddsmb übers Netz oder mit dem Parameter -h verwenden: cupsaddsmb -H sambaserver -h cupsserver -v printername.

Ist die Anweisung TempDir in cupsd.conf auf einen gültigen Wert gesetzt und schreibbar?

Verwenden Sie smbstatus, um zu prüfen, welcher Benutzer Sie aus der Sicht von Samba sind. Haben Sie die Rechte, um in die Freigabe [print$] zu schreiben?

Sobald Sie als falscher Benutzer verbunden sind (z.B. als nobody, was oft geschieht, wenn Sie map to guest = bad user gesetzt haben), wird der Windows Explorer es nicht akzeptieren, wenn Sie sich als ein anderer Benutzer anzumelden versuchen. Nicht ein Byte wird zu Samba übertragen werden, aber Sie werden immer noch eine dumme Fehlermeldung sehen, die Sie glauben lässt, dass Samba den Zugriff verweigert hat. Verwenden Sie smbstatus, um nach aktiven Verbindungen zu sehen. Killen Sie die PIDs. Sie können sich noch immer nicht neu verbinden und bekommen die gefürchtete Meldung You can't connect with a second account from the same machine, sobald Sie es versuchen. Und Sie sehen kein einziges Byte bei Samba ankommen (sehen Sie sich die Logs an; verwenden Sie „ethereal“), das einen neuerlichen Verbindungsversuch anzeigt. Schließen Sie alle Explorer-Fenster. Das lässt Windows vergessen, was es in seinem Speicher als aufgebaute Verbindungen gepuffert hat. Dann verbinden Sie sich neu als der „richtige“ Benutzer. Die beste Methode ist es, ein DOS-Terminal-Fenster zu verwenden und zuerst net use z: \\GANDALF\print$ /user:root auszuführen. Überprüfen Sie mit smbstatus, dass Sie mit einem anderen Konto angemeldet sind. Jetzt öffnen Sie den Folder Drucker und Faxgeräte (auf dem Samba-Server in der Netzwerkumgebung), klicken Sie mit der rechten Maustaste auf den betreffenden Drucker und wählen Verbinden...

Sie sehen per smbstatus, dass Sie als der Benutzer nobody angemeldet sind; dabei wollen Sie root sein oder printer admin. Das kommt eventuell von map to guest = bad user, das Sie stillschweigend unter dem Gästekonto angemeldet hat, als Sie (vielleicht unabsichtlich) einen falschen Benutzernamen angegeben haben. Entfernen Sie map to guest, wenn Sie dies vermeiden wollen.

Diese Information stammt aus einem Posting in der Mailing-Liste, das Probleme beim Upgrade von den Adobe-Treibern auf die CUPS-Treiber auf Microsoft Windows NT/200x/XP-Clients beschrieb.

Löschen Sie zuerst alle alten Drucker, die die Adobe-Treiber verwenden. Dann löschen Sie alle alten Adobe-Treiber. (Unter Windows 200x/XP klicken Sie mit der rechten Maustaste in den Hintergrund des Ordners Drucker und Faxgeräte, wählen Servereigenschaften, Treiber und löschen hier die alten Drucker).

Verwenden Sie den „nackten“ root-Benutzernamen? Versuchen Sie es so: cupsaddsmb -U DOMAINNAME\\root -v druckername (Beachten Sie die beiden Backslashes: der erste wird benötigt, um das „escaping“ des zweiten zu bewirken.)

Das Löschen eines Druckers auf dem Client löscht nicht gleichzeitig den Treiber (zur Überprüfung rechtsklicken Sie in den Hintergrund des Ordners Drucker und Faxgeräte und wählen Servereigenschaften, Treiber). Dieselben alten Treiber werden wiederverwendet, wenn Sie versuchen, einen Drucker mit demselben Namen zu installieren. Wenn Sie auf einen neuen Treiber aktualisieren wollen, löschen Sie zuerst die alten. Das Löschen ist nur möglich, wenn kein anderer Drucker denselben Treiber verwendet.

Lokale Sicherheitsrichtlinien können eventuell die Installation unsignierter Treiber verhindern. Sie können sogar generell die Installation von Druckertreibern verbieten.

Windows XP behandelt SMB-Drucker auf einer „per-user“-Basis. Das bedeutet, dass jeder Benutzer den Drucker selbst installieren muss. Um einen Drucker zu haben, der für jeden verfügbar ist, möchten Sie vielleicht die integrierten IPP-Client-Fähigkeiten von Windows XP nutzen. Fügen Sie einen Drucker mit dem Druck-Pfad http://cupsserver:631/printers/druckername hinzu. Wir suchen nach wie vor nach einer Lösung dieses Problems. Vielleicht könnte ein Anmelde-Skript automatisch Drucker für alle Benutzer installieren.

For print change, notify functions on NT++ clients.(((übersetzen))) Diese müssen zuerst den Server-Dienst ausführen. (In XP wurde er in Datei- & und Druckerfreigabe für Microsoft-Netzwerke umbenannt).

Win XP-SP1 führte eine Point-and-Print-Beschränkungsrichtlinie ein (diese Beschränkung gilt nicht für die Benutzergruppen „Administrator“ oder „Power User“). Im Gruppenrichtlinien-Editor gehen Sie auf Benutzerkonfiguration -> Administrative Vorlagen -> Systemsteuerung -> Drucker. Diese Richtlinie ist automatisch aktiviert und auf Benutzer können Point and Print nur für Computer in der eigenen Gesamtstruktur verwenden gesetzt. Sie müssen dies eventuell auf Deaktiviert oder Point and Print nur mit folgenden Servern setzen, um Treiber-Downloads von Samba zu ermöglichen.

Wie machen Sie das? Ich wette, auf die falsche Art (es ist auch nicht einfach herauszufinden). Es gibt drei verschiedene Arten, Sie zu einem Dialog zu bringen, der scheinbar all diese Dinge setzen kann. Alle drei Dialoge sehen gleich aus, jedoch tut nur einer das, was Sie beabsichtigen. Sie müssen Administrator oder Druck-Administrator sein, um dies für alle Benutzer tun zu können. Hier sehen Sie, wie ich das in XP mache:

Sehen Sie irgendeinen Unterschied? Ich auch nicht. Wie auch immer: Nur der letzte Dialog, zu dem Sie nach Befolgung von Variante „C“ gelangt sind, wird all die Einstellungen dauerhaft speichern und zu Voreinstellungen für neue Benutzer machen. Wenn Sie wollen, dass alle Clients dieselben Voreinstellungen erhalten, müssen Sie diese Schritte als Administrator (printer admin in smb.conf) durchführen, bevor ein Client den Treiber herunterlädt (die Clients können später ihre per-user-Standards setzen, indem sie die obigen Prozeduren A oder B befolgen).

Verwenden Sie nicht Optimize for Speed, sondern verwenden Sie stattdessen Optimize for Portability (Adobe-PS-Treiber). Verwenden Sie nicht Page Independence: No, sondern verwenden Sie immer Page Independence: Yes (Microsoft PS-Treiber und CUPS-PS-Treiber für Windows NT/200x/XP). Wenn es irgendwelche Probleme mit Schriften gibt, verwenden Sie Download as Softfont into printer (Adobe-PS-Treiber). Wählen Sie für TrueType Download Options Outline. Verwenden Sie PostScript Level 2, wenn Sie Probleme mit einem Nicht-PS-Drucker haben und Sie die Wahl haben.

Symptom: Der letzte Befehl von cupsaddsmb schließt nicht erfolgreich ab. Wenn cmd = setdriver printername printername NT_STATUS_UNSUCCESSFUL zurückgibt, dann wurde der Drucker eventuell noch nicht erfolgreich von Samba erkannt. Erscheint er in der Netzwerkumgebung? In rpcclient hostname -c `enumprinters'? Starten Sie smbd neu (oder senden Sie ein kill -HUP an alle von smbstatus angezeigten Prozesse), und versuchen Sie es erneut.

Haben Sie aus Versehen das CUPS-Spool-Verzeichnis auf dasselbe Verzeichnis gesetzt (RequestRoot /var/spool/samba/ in cupsd.conf oder path im Abschnitt [printers] in smb.conf)? Diese Verzeichnisse müssen unterschiedlich sein. Setzen Sie RequestRoot /var/spool/cups/ in cupsd.conf und path = /var/spool/samba im Abschnitt [printers] von smb.conf. Andernfalls wird cupsd die Berechtigungen seines Spool-Verzeichnisses bei jedem Neustart bereinigen, und das Drucken wird nicht verlässlich funktionieren.

In diesem Fall schluckt eine Druck-Queue namens „lp“ periodisch Aufträge und spuckt komplett andere Dinge aus, als an sie gesendet wurden.

Es ist eine schlechte Idee, irgendeinen Drucker „lp“ zu nennen. Das ist der traditionelle UNIX-Name für den Standard-Drucker. CUPS kann so eingerichtet werden, dass es automatisch „Implicit Classes“ anlegt. Das bedeutet, alle Drucker mit demselben Namen zu einem Geräte-Pool zu gruppieren und eine Lastverteilung unter ihnen nach der „Round-robin“-Methode durchzuführen. Die Wahrscheinlichkeit, dass jemand anderes auch einen Drucker namens „lp“ hat, ist hoch. Es kann sein, dass Sie seine Aufträge empfangen und Ihre Aufträge an seinen Drucker senden. Um strenge Kontrolle über die Druckernamen zu haben, setzen Sie BrowseShortNames No. Das stellt jeden Drucker als druckername@cupshost dar und gibt Ihnen einen besseren Überblick darüber, was in einem großen Netzwerk passieren kann.

Verwenden Sie smbclient, um sich mit irgendeiner Windows-Maschine mit einem freigegebenen PS-Drucker zu verbinden: smbclient //windowsbox/print\$ -U guest. Sie können ins Unterverzeichnis W32X86/2 vordringen, um mittels mget ADOBE* die Dateien zu erhalten, oder ins Verzeichnis WIN40/0. Eine andere Möglichkeit ist es, die Dateien als *.exe-Package von der Adobe-Website herunterzuladen.

Dieses Kommando versuchte in den Versionen vor Samba-3.0.1 automatisch zu erkennen, welchen Druckertreiber-Typ es installieren sollte: Version '2' oder Version '3'. Seit 3.0.1 können Sie die Version explizit angeben.

Windows NT kennt nur die sogenannten 'Version 2'-Treiber. Diese laufen im Kernel-Modus und installieren sich in das Unterverzeichnis '2' der [print]-Freigabe. 'Version 2'-Drucertreiber können wegen ihrer Ausführung im Kernelmodus das komplette Windows-System mit in den Abgrund ziehen, wenn sie abstürzen. Besonders berüchtigt sind hier manche Billigdrucker-Treiber. Hingegen sind dies Adobe- wie auch die Microsoft-PostScript-Treiber der 'Version 2' gut getestet. Sie machen bekanntermassen keinerlei Schwierigkeiten, obwohls sie (auch unter 2K/XP) im Kernelmodus laufen.

Mit Windows 2000 führte Microsoft die 'Version 3'-Treiber ein. Diese laufen im 'Userspace-Modus'. Ein Treiberproblem bringt deshalb nicht mehr den kompletten Rechner zum Absturz. (Windows 2000 und XP können allerdings die älteren 'Version 2'-Treiber in einem 'Kompatibiltätsmodus' ausführen. Dies ist allerdings nur bedenkenlos für die Adobe- oder Microsoft-PS-Treiber zu empfehlen. Falls Sie die Wahl haben, wählen Sie immer die 'Version 3'-Treiber. Diese laufen allerdings nicht auf Windows NT Workstations. Ein Samba-Printserver, der NT-Clients zu bedienen hat, muss die 'Version 2'-Treiber vorrätig halten, damit sie per 'Point'n'Print' installierbar sind.

Der 'rpcclient adddriver' Befehl hat eine leicht geänderte Syntax. Als letzten Parameter übergeben Sie ihm jetzt die Treiber-Version. '3' für Win2000/XP, '2' für WinNT und '0' für Win95/98/ME.

CUPS verschafft Ihnen einige Annehmlichkeiten, die andere Drucksysteme nicht bieten können. Innerhalb von Samba erspart es Ihnen sogar die Angabe eines 'print command = ....'-Eintrags in der smb.conf. Denn CUPS macht das automatisch richtig...

Mit 'printing = cups' legen Sie in pre-3.0.3-Versionen global fest, dass Ihr Samba-Server CUPS verwenden soll. Dieses gilt dann für alle Drucker und Druckerwarteschlangen.

Da viele Administratoren jedoch gerne einige 'Spezialdrucker' verwenden wollen, die einen eigenen Druckbefehl erfordern, war diese Einschränkung zu unflexibel. Insbesondere die vielen im Umlauf befindlichen 'Virtuellen PDF-Drucker', die mit Hilfe von Ghostscript ihren Windows-Clients PDF-Dateien erzeugen und diese dem Anwender ins eigene Verzeichnis wieder ablegen, waren dadurch nicht ohne 'Klimmzüge' mit CUPS zu verwenden.

Seit 3.0.3 können Sie jeder Druckerwarteschlange ihre eigene Einstellung zuordnen. Denn 'printing = ....' ist jetzt ein sogenannter 'service level'-Paramter, und kein 'globaler' mehr.

Sie können aber nach wie vor 'printing = cups' in die [global]-Sektion der smb.conf schreiben. (Sie dürfen alle 'service level' Paramter in den Rang eines globalen befördern -- Sie dürfen nur nicht globale Parameter in den service leveln ((()))? verwenden). Ein 'printing = cups' Eintrag in der [global]-Sektion gilt automatisch für alle Drucker -- solange für den Drucker nicht ein anderes Drucksystem spezifiziert wird.

Beispiel:

 [global]
     printing = cups
     printcap name = cups
     load printers = yes
 [printers]
    comment = Alle Drucker
    path = /var/spool/samba
    public = yes
    guest ok = yes
    writable = no
    printable = yes
    printer admin = root, @ntadmins
 [PDF-Printer]
    printing = bsd
    comment = PDF creator
    path = /var/tmp
    printable = Yes
    print command = /usr/bin/smbprngenpdf -J '%J' -c %c -s %s -u '%u' -z %z
    create mask = 0600
 

Wie Sie sehen, definieren wir zwar in der [global]-Sektion mit 'printing = cups' und 'load printers = yes' eine Einstellung definieren. ((( voriger Abschnitt unverständlich))) Dies bewirkt, dass wie bisher alle CUPS-Drucker von Samba automatisch gefunden und verwendet werden. Für diese Drucker braucht Samba kein 'print command'. Darüber hinaus definieren wir eine spezielle Druckerfreigabe namens 'PDF-Printer'. Für diese verwenden wir einen selbst-gestrickten Druckbefehl, den wir Samba auch mitteilen. ('smbprngenpdf' ist ein Bash-Script, das in neueren SuSE-Versionen integriert ist. Es setzt das Utility ps2pdf von Ghostscript ein, um PDFs aus PostScript zu generieren. Sie können mit demselben Mechanismus jederzeit ihre eigenen Skripte in das CUPS-/Samba-System einbinden).

Dieser neue Paramter wird nur wirksam, wenn zugleich 'printing = cups' (für dieselbe Druckfreigabe) gesetzt ist. 'cups options' ist ebenfalls ein service level Parameter. (((auszeichnen?)))

Sein Wert kann einer beliebigen Kombination von Druckoptionen bestehen. Diese Optionen übergibt Samba direkt an CUPS. Sie dürfen beliebige Optionen aus dem CUPS-Anwenderhandbuch verwenden, oder druckerspezifische, die in der Drucker-PPD definiert sind. Die druckerspezifischen Optionen verrät Ihnen z.B. der Befehl 'lpoptins -p druckername -l' (gilt nicht für 'raw'-Drucker).

Ein Anwendungsfall könnte auch darin bestehen, dass Sie allen Druckjobs eine IPP-Option mitgeben, z.B. 'job-hold-until=indefinite'. Diese bewirkt, dass der Job innerhalb des CUPS-Spoolers auf 'Warten' gesetzt wird, bis eine manuelle Freigabe (z.B. über das CUPS-Webinterface) erfolgt.

Eins andere Möglichkeit: eine Kopfseite ('banner page') die für jeden Anwender unterschiedlich ist und der schnelleren Identifikation der eigenen Druckjobs dient.

Beispiele:

 [global]
     printing = cups
     printcap name = cups
     load printers = yes
 [printers]
    comment = Alle Drucker
    path = /var/spool/samba
    public = yes
    guest ok = yes
    writable = no
    printable = yes
    printer admin = root, @ntadmins
 [Teurer_Farblaser]
    cups options = 'job-hold-until=indefinite'
 [Abteilungsdrucker_1]
    cups options = 'job-sheets=none,%$USER-banner' 

Wie Sie sehen, verwendet der 'Abteilungsdrucker_1' eine Kopfseite, deren Name '%$USER' enthält. Das '%$' veranlasst Samba, nach der Umgebungsvariable '$USER' zu suchen, diese zu expandieren und zu ersetzen. Falls der momentane Anwender 'kpfeifle' heisst, wird dem Job also der Befehl '-o job-sheets=none,kpfeifle-banner' mitgegeben. Sie müsen lediglich dafür sorgen, dass auf Seiten von CUPS nun auch tatsächlich eine Datei namens 'kpfeifle-banner' in '/usr/share/cups/banners/' liegt und druckbar ist....

Dieser Parameter steuert, wie häufig Samba die Datei printcap einliest, um nachzuschauen, ob sich in der Druckerliste Änderungen ergeben haben. Die Voreinstellung ist 'printcap cache time = 0'. Sie verhindert, dass Samba zur Laufzeit die printcap neu einliest. Ein CUPS neu hinzugefügter Drucker ist somit für Samba nicht sofort nutzbar. Wollen Sie diesen trotzdem 'sehen' und nutzen (ohne Samba komplett neu starten zu wollen), müssen Sie allen smbd-Prozessen ein 'HUP'-Signal schicken: 'kill -HUP `pidof smbd`'.

Um eine fortlaufende automatische Aktualisierung der Samba-Druckerliste zu erzwingen,sollten Sie einen Wert in Sekunden eintragen, etwa 'printcap cache time = 60'. Damit stellen Sie sicher, dass alle neuen CUPS-Drucker nach spätestens 1 Minute in Samba ebenfalls sichtbar sind.

Dieses neue 'rpcclient' Sub-Kommando verleiht einem Unix-Drucker einen neuen Künstlernamen für seinen Auftritt in der Windows-Welt.

Dies ist z.B. dann nützlich, wenn Sie Ihren Anwender künftig mit einem Samba-Printserver dienen wollen, ohne sie von den gewohnten Windows-Namen für Drucker (die unter Umständen Leerzeichen enthalten können) entwöhnen zu müssen.

Dieser neue Parameter erlaubt es Ihnen erstmals, Samba- und CUPS-Server auf zwei verschiedenen Maschinen laufen zu lassen. 'cups server = ....' ist ein Paramter, der nur in der [global]-Sektion auftauchen darf.

Weiterhin können Sie damit verschiedenen „virtuellen Samba-Daemons“ unterschiedliche CUPS-Druckserver zuordnen, etwa nach Arbeitsgruppen getrennt.

Zum Einsatz mit verschiedenen CUPS-Servern für unterschiedliche virtuelle smbd-Prozesse müssen Sie diesen Parameter daher per 'include' in die jeweilige smb.conf einbinden. Näheres lesen Sie bitte in den Manual-Seiten der smb.conf nach.

Mit dem 'VampireDriverFunctions' hat ein neues Migrationstool in die Samba-Scriptsammlung Einzug gehalten. Dieses ist aus der Not geboren: der Autor hatte die berufliche Aufgabe, im Kundenauftrag einen Windows-NT-Printserver auf eine stärkere Maschine unter Windows XP Professional (!) zu migrieren.

Kein Problem, sagen Sie? Die Praxis sah anders aus:

Der Autor nahm sich vor, einer solchen Aufgabe nie wieder unvorbereitet gegenübertreten zu müssen. Er schrieb das Script 'VampireDriverFunctions'. Dieses verwendet Samba's Befehle rpcclient'- und smbclient, nebst einigen Unix-Utilities wie 'sed', 'awk', 'sort' 'uniq' und einigen anderen, um von einem bestehenden (Samba- oder Windows-)Printserver die Treiberdateien abzusaugen und in einer Verzeichnisstruktur geordnet abzulegen.

Das Skript funktioniert so gut, dass (in einem anderen Fall) die ähnlich grosse Aufgabe, 78 Druckertreiber von einem Server auf einen anderen zu übertragen, bereits nach 23 Minuten erledigt war. (Dieses Mal ging die Migration allerdings nicht von WinNT nach WinXP, sondern Richtung Linux/Samba ;-) )

'VampireDriverFunctions' selbst ist modular aufgebaut und in verschiedene Funktionen gegliedert.

Bedenken Sie, dass 'VampireDriverFunctions' nicht die Druckerwarteschlangen installiert. Diese müssen nach wie vor mit Hilfe des CUPS-'lpadmin'-Befehls (oder entsprechend anderen Methoden) angelegt werden. Auch ordnet das Skript keine der frisch installierten Windows-Treiber den entsprechenden CUPS-Druckerwarteschlangen zu. Dies bleibt einer Serie von 'rpcclient ...setdriver...'-Befehlen vorbehalten. Allerdings ist dies selbst bei einer Zahl von mehr als hundert Druckern innerhalb von 2 Stunden erledigt, wenn erstmal die Treiber in der [print$]-Share bevorratet sind.

'VampireDriverFunctions' ist selbstdokumentierend. Starten Sie es mit dem Befehl 'source VampireDriverFunctions' in einer Bash-Shell. Die Shell liest jetzt die beinhalteten Funktionen ein und listet sie auf:

       NOTE: run the listed functions in the same order as listed below.
    EXAMPLE: „knoppix@ttyp6[knoppix]$ helpwithvampiredrivers“

       HELP: the „--help“ parameter prints usage hints regarding a function.
    EXAMPLE: „knoppix@ttyp6[knoppix]$ fetchenumdrivers3listfromNThost --help“

   function vampiredrivers_readme()
   function enumallfunctions()
   function helpwithvampiredrivers()
   function fetchenumdrivers3listfromNThost()  # repeat, if no success at first
   function createdrivernamelist()
   function createprinterlistwithUNCnames()    # repeat, if no success at first
   function createmapofprinterstodrivers()
   function splitenumdrivers3list()
   function makesubdirsforW32X86driverlist()
     function splitW32X86fileintoindividualdriverfiles()
     function fetchallW32X86driverfiles()
     function uploadallW32X86drivers()
   function makesubdirsforWIN40driverlist()
     function splitWIN40fileintoindividualdriverfiles()
     function fetchallWIN40driverfiles()
     function uploadallWIN40drivers()

Jede dieser Funktionen zeigt Ihnen an, wie sie zu benutzen ist und welche Voraussetzungen Sie schaffen müssen, damit Sie sie erfolgreich ausführen können. Um z.B. die Hilfe für die Funktion 'createdrivernamelist()' zu sehen, geben Sie bitte 'createdrivernamelist --help' ein. Führen Sie jedoch bitte zuerst den Befehl 'vampiredrivers_readme' aus.

Dabei werden Sie erfahren, dass das Script 6 zusätzliche Parameter einlesen muss: die beiden Rechnernamen (Quelle und Ziel), sowie die beiden Benutzernamen und die Passwörter. Als Variablen sind diese mit $nthost, $ntprinteradmin und $ntadminpasswd (für den Quellrechner) sowie $smbhost, $smbprinteradmin und $smbadminpasswd (für den Zielrechner) bezeichnet. (Anmerkung: auf dem 'Zielrechner' brauchen Sie Rechte als 'Druck-Administrator').

Für die Treiber der 'WIN40'-Architektur (also für Win95/98/ME) sind anologe Funktionen vorhanden.

Wenn Sie die aufgelisteten Funktionen jetzt nacheinander manuell ausführen, holen Sie die Treiber von einem Server A (Samba oder Windows, in dem Skript allerdings immer als '$nthost' bezeichnet) und laden diese Anschliessend auf Server B (Samba oder Windows, im Skript jeweils '$smbhost') hoch. Sie können dies leicht in einem sehr einfachen Skript automatisieren. Dieses muss zuerst die 'VampireDriverFunctions' einlesen ('sourcen') sowie die Parameter für Quell- und Ziel-Rechner und anschliessend einfach die betreffenden Funktionen nacheinander aufrufen::

 #!/bin/bash
 
 $nthost=„10.11.12.13“            # adapt to your own environment
 $ntprinteradmin=Administrator    # adapt to your own environment
 $ntadminpasswd=secret            # adapt to your own environment
 
 $smbhost=„samba.localdomain.de“  # adapt to your own environment
 $smbprinteradmin=root            # adapt to your own environment
 $smbdminpasswd=topsecret         # adapt to your own environment
 
 source VampireDriverFunctions
 
 fetchenumdrivers3listfromNThost  # repeat, if no success at first
 createdrivernamelist
 createprinterlistwithUNCnames    # repeat, if no success at first
 createmapofprinterstodrivers
 splitenumdrivers3list
 makesubdirsforW32X86driverlist
 splitW32X86fileintoindividualdriverfiles
 fetchallW32X86driverfiles
 uploadallW32X86drivers

Die Knoppix-CD beinhaltet seit der Release 3.4 (CeBIT 2004) eine funktionierende Vorläufer-Version dieses Scripts. Es trägt hier allerdings den Namen 'print-utils-get-functions.sh'. Sie können dieses Tool auch von der laufenden Knoppix-CD aus benutzen, sollten dabei allerdings genügend Hauptspeider haben, um die Treiber zeitweilig in der RAM-Disk speichern zu können (oder ein 'permanentes Homeverzeichnis für den Benutzer Knoppix' auf der Festplatte einrichten).

'VampireDriverFunctions' finden Sie im Verzeichnis 'examples/printing/' der Samba-Quellen.