Dass der Computeralltag auch unter Linux des Öfteren für Überraschungen gut ist, ist eher eine Binsenweisheit: Immer wieder funktionieren Dinge nicht oder nicht so, wie eigentlich angenommen. Das Answer-Girl im LinuxUser zeigt, wie man mit solchen Problemchen elegant fertig wird.

Im LinuxUser 06/2000 entlockten wir einem SMB-Drucker im Microsoft-Netzwerk an dieser Stelle mit viel Mühe und einem Skript sinnvolle Druckerzeugnisse. Nun mag Unix-verwöhntes Volk jedoch gar nicht einsehen, wieso es ausgerechnet für diesen Drucker eine Ausnahme machen sollte: Alle anderen Drucker lassen sich mit dem lpr-Kommando ansprechen, und nur hier gibt’s ein Extraskript?

Wo bleibt der Druckerspool?

Nicht mit uns: Der SMB-Drucker soll eine ebensolche Druckerwarteschlange bekommen, auf die für ihn bestimmte Druckjobs abgelegt und abgearbeitet werden.

Abbildung 1: Welche Art Drucker soll es sein?

Mit Tools wie Red Hats printtool ist man da natürlich fein raus – einfach Parameter eintragen und fertig (Abbildung 1 und 2). Doch auch sonst ist nicht alles verloren: Der Schlüssel zum Druckerglück liegt in einer Datei mit dem schönen Namen /etc/printcap, der unter man printcap auch eine eigene Manpage gewidmet ist.

Abbildung 2: Ob von Hand oder mit printtool – diese Parameter müssen Sie kennen

Glücklicherweise findet sich nur ausgesprochen selten eine völlig leere printcap, und mit Beispieleintrag, zugehöriger Manpage und vielleicht noch [3] bewaffnet, kann es sich nur um Stunden handeln, bis wir etwas Sinnvolles auf die Beine gestellt bekommen.

Was sofort auffällt, ist die Struktur eines Eintrags:

name_1|name_2|...|name_n: \
        :string_option_1=string_wert_1: \
        :[...]: \
        :num_option_x#num_wert_x: \
        :[...]: \
        :bool_option:

In der ersten Zeile werden, mit dem logischen ODER-Zeichen | voneinander abgetrennt, all jene Namen angegeben, unter denen der Drucker mit lpr -PName datei angesprochen werden kann. Ein printcap-Eintrag sollte (u.a.) lp heißen, wenn man auch ohne die -P-Option bei einem Drucker landen will. Der Doppelpunkt : beschließt das Ende der Namensliste und leitet die Aufzählung von Eigenschaften der entsprechenden Druckerwarteschlange ein.

Wie aus der printcap-Manpage ersichtlich, gibt es Charakteristika dreierlei Art: Optionen, die als Wert eine hinter einem Gleichheitszeichen angegebene Zeichenkette (einen “String”) verlangen, numerische Werte, die vom Optionsnamen durch # getrennt werden, und Ja/Nein- (“Boolsche”) Optionen, die nur dann aufgeführt werden, wenn sie auf “Ja” gesetzt werden sollen: Nicht aufgeschrieben bedeutet hier “woll’n wir nicht”.

Jede Option muss links und rechts von : umrahmt werden. In praxi ist jeder printcap-Eintrag schlichtweg eine lange Zeile; der Übersichtlichkeit halber kann man den Zeilenumbruch jedoch mit \ maskieren. Da allerdings jede Option sozusagen nicht über den Tellerrand der eigenen in der Datei stehenden Zeile hinweg schauen kann, muss man in diesem Fall den letzten : noch einmal am Zeilenbeginn wiederholen.

Das große Ganze

Im Wust der ganzen Optionen findet man sich am besten zurecht, wenn man sich überlegt, wie das Drucken eigentlich vonstatten geht. Zunächst nimmt das Programm lpr (“line printer”) den Druckauftrag entgegen und bringt ihn in der passenden Druckerwarteschlange unter.

Irgendwann kommt dann der Lineprinter-Dämonlpd daher, schnappt sich den ersten wartenden Job aus der Schlange und bereitet ihn auf den Ausdruck vor. Das, was er da tut, haben wir in Heft 06/2000 selbst von Hand durchexerziert: Wir suchten uns einen Filter, der aus den verschiedenen Formaten, die eine auszudruckende Datei haben kann, das Format macht, das der Drucker versteht – in der Regel PostScript oder PCL.

Außerdem kann der lpd noch ein paar Dinge entscheiden: z.B. ob er die Datei überhaupt ausdrucken will, wenn er sieht, dass sie so groß ist, dass der Drucker auf zwei Stunden komplett beschäftigt wäre. Zum guten Schluss schiebt der lpd dem Drucker die Daten zu, sofern der gerade nichts zu tun hat.

Die Printcap muss demnach folgende Informationen enthalten:

• den Namen des Druckers,
• die Gerätedatei, über die er angesprochen werden kann, also den “line printer” selbst: lp=/dev/xxx, wobei xxx für einen lokalen Drucker z.B. die parallele Schnittstelle lp1 sein kann,
• die Warteschlange, also ein Verzeichnis (“directory”), in dem die Druckjobs “aufgespult” werden: sd=/var/spool/lpd/xxx. Der Name des Druckerspools, xxx, ist Ihrer Fantasie überlassen, sinnvollerweise heißt er in etwa so wie Ihr Drucker,
• der “Input-” oder Eingabe-Filter, der am Ende das für den Drucker passende Format ausspuckt: if=/pfad/zum/filter und
• ggf. ein paar Sondereigenschaften wie mx#xxx, wobei xxx die maximale Dateigröße festlegt. Dass diese als Vielfaches eines Kilobytes angegeben wird, bekommt man allerdings erst mit ein wenig Recherche heraus [1,2].

Ganz praktisch – ein neuer Drucker

Listing 1 zeigt ein Beispiel – es ist nicht nur der Übersichtlichkeit halber so einfach wie möglich gehalten: Obwohl sich das ältere lpq/lpr(-BSD)-Printsystem und das neuere lprng auf den ersten Blick nicht in ihren Printcaps unterscheiden, gibt es marginale Unterschiede. Die machen sich in der Durchschnittskonfiguration zwar nicht bemerkbar, im Fehlerfall ist es um ihre Existenz jedoch gut zu wissen. An dieser Stelle vermeiden wir derlei Spitzfindigkeiten lieber…

Leider lässt es sich nicht ganz vermeiden, dass Sie Listing 1 an Ihre Gegebenheiten anpassen (und wenn Sie mit weiteren Optionen experimentieren wollen – nur zu …).

Der dort beschriebene Drucker heißt remote oder hplj4p und ist mangels des Namens lp nicht der Standarddrucker.

remote|hplj4p:\
        :lp=/dev/null:\
        :sd=/var/spool/lpd/ljet4:\
        :sh:mx#0:\
        :if=/home/trish/bin/smbprint:

Als Nächstes gibt die Stringoption lp die lokale Gerätedatei an, über die der Drucker angesprochen werden soll. Da ist guter Rat teuer – denn der SMB-Drucker hängt ja nicht an unserem Rechner, sondern wird über Netzwerk um seine Dienste gebeten. Zudem läuft die gesamte Druckarbeit im smbprint-Skript aus Heft 06/2000 über den smbclient ab (Listing 2a). Kurzum: eigentlich können wir auf ein Gerät verzichten.

Wir zwar, nicht jedoch lpd, denn der muss die ihm anvertrauten Daten ja irgendwo abliefern, selbst wenn er sie einfach wegwerfen darf, da schon alles erledigt. Und wenn er schon entsorgen darf, dann soll er dazu doch einfach den virtuellen Papierkorb /dev/null benutzen.

Haben Sie das unter sd (“spool directory”) angegebene Spoolverzeichnis (hier: /var/spool/lpd/ljet4) ggf. neu angelegt? Auf vielen Systemen ist ein Benutzer namens lp Herrscher über die Druckerschlangenverzeichnisse in /var/spool/lpd. Unterminieren Sie das Sicherheitsbewusstsein Ihrer Distribution nicht, und “verschenken” Sie das neue Spoolverzeichnis mit chown an den passenden User und seine Gruppe.

Als Beispiel für eine Boolsche Option haben wir “Suppress header”, kurz sh, kurzerhand auf “Ja” gesetzt. Manche Drucker sind hardwareseitig so eingestellt, dass sie vor jedem Druckjob eine “Banner-Seite” ausdrucken – in Rechenzentren durchaus eine sinnvolle Option, will man dem bedruckten Papier nachher noch eine Eigentümerin zuordnen. In einer überschaubaren Umgebung ist das jedoch Papierverschwendung. Selbst wenn der Drucker eigentlich keine Banner-Seiten produziert, schadet es nicht, dies explizit in der Printcap zu verneinen.

Bei der numerischen Option mx (“maximum filesize”) legen wir selbstbewusst fest, dass wir schon wissen, was wir ausdrücken wollen, und setzen den Wert auf 0 wie “unbegrenzt”.

Noch mehr Gefilter

Das Wichtigste zum Schluss: if, das eigentliche Kernstück der ganzen Konfiguration. Im Fall unseres SMB-Druckers liegt auf seiner Schulter die volle Last von der Konvertierung bis zum Ausdruck selbst.

#!/bin/sh
cat $* | /etc/magicfilter/ljet4l-filter | \
        smbclient \\\\server\\drucker \
        -W workgroup \
        -U "username%passwort" \
        -c 'translate; print -'

Mit dem Skript smbprint aus Heft 06/2000 (Listing 2a) haben wir schon die gröbste Vorarbeit geleistet, indem wir heraus gefunden haben, wie wir die Konvertierung ins Druckerformat hinbekommen (Stichwort: magicfilter), dafür sorgen, dass bei Textdateien keine Treppenstufen auftreten (smbclient-Befehl translate) und letztlich mit dem smbclient-Kommando print dem Drucker Arbeit verschaffen.

Was wir aus dem Skript nicht mehr brauchen, ist das cat, das erstmal die zu druckende Datei in die Filter-Pipeline schickte. Das erledigt jetzt lpd für uns: Der if-Filter bekommt die Daten auf der Standardeingabe angeliefert und soll nichts weiter tun, als sie aufzubereiten. Normalerweise gelangt die Ausgabe dieses Filters an die Gerätedatei. Da wir aber schon im “Filter” ausdrucken, werfen wir alles, was am Ende noch übrig bleibt, wie beschrieben nach /dev/null.

#!/bin/sh
logfile=/var/log/smb-print.log
/bin/date >> $logfile
/etc/magicfilter/ljet4l-filter \
|/usr/sbin/smbclient //server/drucker \
        -W workgroup \
        -U "username%passwort" \
        -c "translate; print -" >>$logfile

Nix mit interaktiv

Problematisch ist eigentlich nur, dass das Inputfilterskript keinerlei Interaktivität zulässt – man kann aus dem Hintergrund nicht eben mal nachfragen, ob der ausdruckende Nutzer auch tatsächlich einen SMB-Usernamen vor- und sich mit dem richtigen Passwort ausweisen kann.

Wollten wir das nachprüfen, wären wir ein paar Answer-Girls beschäftigt, und so nehmen wir seufzend in Kauf, dass wir davon ausgehen müssen, dass auf unserem Rechner niemand wirklich Drucker-Unbefugtes einen Account besitzt.

Schlimmer noch als die Schwierigkeit mit dem SMB-User wiegt die Tatsache, dass wir das SMB-Passwort im Klartext abspeichern sollen. Zwar könnten wir das if-Skript beliebig um das Auslesen und Dekodieren eines verschlüsselt abgespeicherten Passworts verkomplizieren. Doch da auch das keine Sache von zwei Zeilen ist, schieben wir den Schwarzen Peter unserem Windowsadministrator zu: Soll der doch ein Konto einrichten, das wirklich nur zum Drucken auf dem entsprechenden Gerät genutzt werden kann. Wir unsererseits sorgen (beispielsweise mit 511 smbprint) zumindest dafür, dass lediglich der Besitzer Leserechte auf die Filterdatei erhält (Schreibrechte sind sowieso out).

Die Besitzerin des Skripts in Listing 1 bin immer noch ich, doch eigentlich würde ich die Bürde gern los werden: Wieso soll ausgerechnet bei einem linuxrechnerweit verfügbaren Drucker ein Skript ausgeführt werden, das in meinem Homeverzeichnis liegt?

Eine vom Red-Hat-printtool (vgl. Kasten “printtool und Co.”) erzeugte /etc/printcap weist den Weg: Hier kommt zwar nicht unser schönes selbst gestricktes if-Skript zum Einsatz, sondern ein ähnliches namens – hätten Sie’s gedacht? – smbprint (bei SuSE heißt es übrigens samba_print), doch das macht ja nichts.

##PRINTTOOL3## SMB ljet4 600x600 a4 {} LaserJet4 Default 1
remote|hplj4p:\
        :sd=/var/spool/lpd/ljet4:\
        :mx#0:\
        :sh:\
        :if=/var/spool/lpd/ljet4/filter:\
        :af=/var/spool/lpd/ljet4/acct:\
        :lp=/dev/null:

Warum platzieren wir es nicht einfach im Spoolverzeichnis des betreffenden Druckers (/var/spool/lpd/ljet4 in Listing 1) und ändern den if-Eintrag in der Printcap von :if=/home/trish/bin/smbprint: auf :if=/var/spool/lpd/ljet4/smbprint:? Die Besitzverhältnisse in diesem Directory weisen dann (hoffentlich!) schon darauf hin, dass der Druckermanager möglichst ein eigener Benutzer namens lp o.ä. ist.

Es muss nicht immer root sein

Manche Distributionen tragen hier allerdings root ein, was sicherheitstechnisch gesehen totaler Overkill ist: Wer Dinge, die sich auch ohne rootsche Allmächtigkeit von speziell berechtigten Usern ausführen lässt, der Systemadministratorin zuschustert, handelt im Allgemeinen grob fahrlässig.

Und wenn wir schon einmal sicherheitsbewusst denken, so schreiben wir nicht nur den Namen des im Skript verwendeten Programms smbclient hinein, sondern auch den Pfad (/usr/sbin) dahin. So schließt man aus, dass ggf. ein unerwünschtes, jedoch ebenfalls im Suchpfad liegendes smbclient benutzt wird.

Wie dem auch sei – aufmerksame Leser(innen) haben schon bemerkt, dass Listing 2b noch zwei Änderungen zur Version aus Heft 06/00 (Listing 2a) enthält: Statt den Windows-typischen Backslashes \ als “Verzeichnistrenner” im Share-Namen \\server\drucker, die zudem noch zu \\\\server\\drucker “escapt” werden mussten, lässt smbclient auch die “unixoide” Schreibweise mit / statt \ zu. Da der einfache Slash gemäß seiner Sonderbedeutung als “Verzeichnistrennzeichen” eingesetzt wird, brauchen wir hier keine Fluchtzeichen.

Schließlich wird noch ein logfile als Variable definiert, eine Datei namens smb-print.log im Verzeichnis /var/log, in dem Systemprogramme, normalerweise unterstützt vom System-Log-Dämon syslogd, mitprotokollieren, was ihnen im Laufe ihres Arbeitslebens so alles widerfährt.

Durch Voranstellen eines $ holen wir uns ganz am Ende den Inhalt der Variablen, also /var/log/smb-print.log, um ans Ende dieser Datei durch den “Doppelpfeil” >> all das anhängen zu lassen, was smbprint an Meldungen von sich gibt. Da wir im Laufe unserer Tests schon festgestellt haben, dass dazu keine Zeitangabe gehört, lassen wir uns die durch das Kommando date voranstellen.

• rpm -qa | lpr z.B. bei SuSE, Caldera, Red Hat und Derivaten
• dpkg -l | grep lpr bei Debian und Abkömmlingen Einen Hinweis auf lprng erhält man u.U. auch vom ps-Kommando. Spuckt ps -auxw | grep lpd in der ersten Spalte aus, dass der Lineprinter-Dämon nicht von root, sondern beispielsweise dem Benutzer lp gestartet wird, haben Sie’s auf jeden Fall mit dem “next generation”-lpd zu tun. lprng wurde u.a. auch deshalb entwickelt, damit man den lpd nicht mehr mit root-Rechten starten muss.

Warum diese Leere?

Nach all diesen Vorarbeiten schlägt endlich die Stunde der Wahrheit: Mit lpr -Premote testdatei schicken wir eine testdatei an den eingerichteten Drucker remote. Wer jetzt mit schnöden Fehlermeldungen abgespeist wird, wird

• ggf. nochmal das Filterskript einzeln testen,
• sich mit lpq -Premote über den Zustand der Druckerwarteschlange informieren,
• ggf. den Lineprinter-Dämonen lpd neu starten: Möglicherweise hat der die /etc/printcap schlichtweg nicht neu eingelesen. Dazu sucht man sich in dem Verzeichnis, in dem die Systeminitialisierungsskripte liegen (/etc/init.d, /etc/rc.d, /etc/rc.d/init.d o.ä.), jenes namens lpd aus. Beim alten lpr/lpd-System (re)startet es root selbst (etwa: /etc/init.d/lpd restart), bei lprng legt root seine Sonderrechte beiseite und startet das Initialisierungsskript als spezialisierter User lp ( - lp /etc/rc.d/init/lpd restart). Sollte sich der Parameter restart als falsch erweisen, muss man sich leider das Initialisierungsskript auf distributionsspezifische Eigenheiten hin näher ansehen.
• nachprüfen, ob das Spoolverzeichnis existiert. Da wir hier das smbprint-Skript liegen haben, ist das zwar wahrscheinlich, aber vielleicht stimmt der Name nicht mit dem überein, was in der /etc/printcap steht.
• nach den Rechten am Spoolverzeichnis schauen. Orientieren Sie sich dabei ggf. an Spoolverzeichnissen, die Ihr Distributor Ihnen z.B. bei der Installation eingerichtet hat. Sinnvoll ist in diesem Zusammenhang auch die Verwendung des Set-Group-ID-Bits mit chmod g+s spoolverzeichnis, sodass Dateien, die dahinein geschrieben werden (z.B. Lockdateien), automatisch in den Besitz der Gruppe übergehen, der das Spoolverzeichnis gehört (beispielsweise lp).

Sie halten glücklich einen Ausdruck in den Händen? Herzlichen Glückwunsch! Um zu kontrollieren, ob auch wirklich alles geklappt hat, werfen wir einen Blick in die Logdatei /var/log/smb-print.log.

Schmerz lass nach – warum ist nichts? So nah am Ziel, und dann das… Also gut, raffen wir uns nochmal auf…

Da lediglich unser smbprint-Inputfilter in die Logdatei schreibt, können wir unsere Fehlersuche auch auf diesen Schritt begrenzen. Versuchen wir also einmal, lpd “per Hand” zu spielen: Der schnappt sich schließlich auch nur eine Datei aus dem Spoolverzeichnis und jagt sie als User lp durch den Inputfilter.

Wir sind bescheidener und nehmen eine beliebige testdatei, um sie von /var/spool/lpd/ljet4/smbprint behandeln zu lassen. Doch zunächst machen wir uns als root zu lp:

lillegroenn:/# su - lp
lp@lillegroenn:/$ cat testdatei | /var/spool/lpd/ljet4/smbprint
./smbprint: /var/log/smb-print.log: Permission denied
./smbprint: /var/log/smb-print.log: Permission denied

Kein Wunder, dass es das Logfile nicht gibt, wenn die zwei Schreibzugriffe (von date und smbclient) verweigert werden. Nur warum? Ein Blick auf das Logverzeichnis /var/log spricht trotz der Kürze Bände (die ls-Option -d bewirkt, dass das Verzeichnis selbst, nicht aber sein Inhalt aufgelistet wird):

lillegroenn:/$ ls -ld /var/log
drwxr-xr-x    8 root     root         3072 May  9 22:48 /var/log

Lediglich root hat im Verzeichnis Schreibrechte. Verständlich, dass lp darin keine neue Datei anlegen darf. Da jedoch alle Benutzer nach /var/log wechseln dürfen, kann root darin mit touch die Logdatei namens smb-print.log anlegen und lp mit chown schenken. Wenn lp Schreibrechte an diesem seinem File hat, so kann das Skript darin auch die Fehlermeldungen ablegen.

root löst das Problem also folgendermaßen:

lillegroenn:/# touch /var/log/smb-print.log
lillegroenn:/# chown lp:lp /var/log/smb-print.log
lillegroenn:/# exit
trish@lillegroenn:/$ ls -al /var/log/smb-print.log
-rw-r--r--    1 lp       lp            0 May  9 22:48 /var/log/smb-print.log

Wunderbar, nun sollte doch alles klappen…

Die Last der Vielfältigkeit

… oder auch nicht: Obwohl fast alle Distributionen auf lpr/lpd bzw. lprng setzen, herrscht leider gerade bei den Print-Spoolsystemen fröhliche Verschiedenheit. Das macht es unmöglich, wirklich alle Eventualitäten in einem Artikel abzudecken. Die hier beschriebenen Fallen sind zwar alle der Realität entnommen, doch es ist sehr wohl möglich, dass ausgerechnet Ihr Problem nicht dabei war. Dann bleibt Ihnen lediglich, selbst auf die Suche zu gehen – vielleicht konnte das Answer-Girl immerhin Gedankenpfade vorbereiten.