RaspberryPi als Printserver für einen HP Laser 107w RAW Drucker

Einführung

In dieser Anleitung nutzen wir einen betagten RaspberryPi (1. Modell) als Printserver.

Ich schreibe hier über den HP Laser 107w. Im Grunde genommen geht es aber um die allgemeine Vorgehensweise, so dass sich die Anleitung auf jeden(!) Drucker anwenden lässt.

Grundgedanken und Motivation dieser Anleitung sind:

1. Es gibt keinen Linux-Treiber für „meinen“ Drucker bzw. es soll kein Treiberbinary auf dem RaspberryPi laufen.
2. Es soll – abgesehen von übereinstimmenden Benutzernamen und Kennwörtern – keine Abhängigkeiten geben.

Aus dem Nähkästchen gplaudert: Warum ich den Laser 107w als RAW-Drucker installiere…

Da mit die WLAN-Anbindung des o.g. Druckers so gar nicht gefiel und ich noch einen alten RaspberryPi (Modell 1, zweite Version) herumliegen hatte, habe ich mir daraus einen kleinen Printserver gebastelt.

Erste Erkenntnis war, dass sich der Drucker meiner Recherche nach nicht auf dem RaspberryPi nutzen lässt – es gibt schlichtweg keine Treiber für dessen historische 32Bit-Architektur.

Eine Analyse des HP-Treibers hat ergeben, dass das Gerät offenbar aus dem Samsung-Portfolio übernommen wurde. Ich behaupte einfach mal, dass es sich um einen umgelabelten Samsung Xpress M2026 handelt 🙂

Dieser Drucker unterstützt allerdings weder Postscript, noch PCL. Die Ansteuerung erfolgt stattdessen über SPL („Samsung Printer Language“?) und mit Hilfe eines im Linux-Treiber enthaltenen Binaries „rastertospl“.

Im aktuellen HP-Treiber ist dieses Binary nur für aktuelle Prozessoren enthalten. Man kann dem Installationsscript zwar eine ARM-Architektur vortäuschen; in Ergebnis wird dann aber lediglich etwas installiert, was nicht gestartet werden kann. ARM ist halt nicht gleich ARM 🙂

Ich habe mir daraufhin die Mühe gemacht, diverse ältere Samsungtreiber zu zerlegen. In irgendeinem Treiber bin ich tatsächlich fündig geworden.

Da sich aber irgendwann die Übergabe oder Anzahl der Kommandozeilenparameter verändert hat und CUPS das Teil aufgrund der falschen Parameterübergabe nicht zum Fliegen bekommt, habe ich mich – zu später Stunde – entschieden, die Druckaufbereitung dem Client zu überlassen.

Sprich: Ich „hatte keine Lust mehr“, der Printserver bleibt „dann halt dumm“ und reicht „nur“ das an den Drucker, was er vom Client geliefert bekommt. Das Rendering, also die Übersetzung in die hardwarespezifische Sprache des Druckers, übernimmt statt des rastertospl Binaries der Client mit dem Windows-Druckertreiber.

Im Nachhinein bin ich da gar nicht mal so unglücklich drüber – gerade an umfangreichen Druckaufträgen hätte der eher mager ausgestattete RaspberryPi ziemlich zu knabbern.

Im Umkehrschluss bedeutet das jedoch und natürlich, dass jeder Client einen Druckertreiber benötigt – dessen Installation sich aber wunderbar vereinfachen lässt. Siehe unten 🙂

CUPS – Vorbereitung

Das Gerät über CUPS abzubilden, bevor man es in irgendeiner Art und Weise im Netzwerk verteilt, hat durchaus Charme. Über das Webinterface von CUPS hat man diverse Möglichkeiten (Start / Stop / Abbruch von Druckjobs usw.), die man schnell nicht mehr missen möchte. Zumindest nicht dann, wenn der eigentliche Drucker wie bei mir eine Etage über dem Client steht.

Wir installieren CUPS – falls noch nicht erfolgt – über die Paketeverwaltung unseres Linux-Distributors:

sudo apt-get install cups

Da Printserver „Headless“ ohne Tastatur und Monitor betrieben werden, erfolgt die Administration über ein Webinterface (Port 631 TCP).

CUPS lauscht hier üblicherweise nur auf Verbindungen vom localhost. Das ändern wir wie folgt:

sudo cupsctl --remote-admin

Zusätzlich benötigen wir zur Vorbereitung einen administrativen Benutzer, der im Idealfall mit dem Benutzernamen eventueller Windows-Installationen identisch ist. In meinem Fall und somit im weiteren Verlauf dieser Anleitung ist das der Benutzer „altmetaller“.

Dieser Benutzer bekommt das Recht, den Drucker zu verwalten. Später bekommt er auch noch das Recht, Druckertreiber auf dem Printserver abzulegen…

CUPS kennt hierfür die Gruppe „lpadmin“. Es reicht somit, den Benutzer „altmetaller“ der Gruppe „lpadmin“ hinzuzufügen:

sudo usermod -aG lpadmin altmetaller

Jetzt sollten wir in der Lage sein, uns mit diesem Benutzernamen im CUPS anzumelden. Die URL vom CUPS lautet:

http://ip.adresse.des.raspberry.pi:631/admin/

Kleiner Tipp: Wer hier die Meldung „Ungültige Anfrage“ erhält, hat versehentlich den Hostnamen statt der IP-Adresse eingegeben 🙂

CUPS – Drucker hinzufügen

Wir rufen also die URL auf und klicken unter „Verwaltung“ auf „Drucker hinzufügen“. Spätestens jetzt werden wir als Zugangsdaten gefragt und geben die Zugangsdaten des Linux-Users ein, den wir zuvor der Gruppe „lpadmin“ hinzugefügt haben.

Der Drucker ist über USB angeschlossen und taucht (nach dem Einschalten) bereits als „Lokaler Drucker“ auf. Wir markieren den entsprechenden Eintrag und klicken auf „Weiter“.

Den Haken bei „Drucker im Netzwerk freigeben“ setzen wir nicht(!). Die Freigabe soll einzig und alleine über SAMBA erfolgen. Es wäre zwar möglich, zwei Freigaben parallel einzurichten – allerdings bestünde dann immer die Gefahr konkurrierender Druckaufträge. Und letztendlich wiederspräche es auch meiner persönlichen Sicherheitsphilosophie „so wenig wie möglich aktivieren“.

CUPS erkennt den Hersteller anhand der USB-ID und bietet uns eine Auswahl aller in CUPS enthaltenen HP-Druckertreiber an.

Unser Drucker ist aufgrund der Eingangs erwähnten Problematik nicht dabei.

Wir klicken daher auf „Anderen Hersteller/Marke wählen“…

…wählen als Hersteller „raw“…

…und als Druckermodell „Raw Queue (en)“ aus.

Dieser imaginäre Treiber macht nichts Anderes, als die Daten vom Windows-Client 1:1 zum Drucker durchzuschieben.

Mit anderen Worten: Das Rendering (also die Umwandlung der Druckdaten in die herstellerspezifische SPL-Befehlssprache) erfolgt später über den (Windows-)Druckertreiber. Zu dem Zeitpunkt, wo CUPS den Druckauftrag erhält, ist dieser bereits vollständig für den Drucker aufbereitet. Unser CUPS dient letztendlich nur als eine Art imaginärer Medienwandler zwischen den Netzwerkdaten und der USB-Schnittstelle.

„Banner“ wären übrigens Titel- und Endseiten, die automatisch zu Anfang und Ende jedes Druckjobs ausgedruckt werden. Wer ’s braucht…

In der abschließenden Übersicht lassen sich diverse Wartungs- und Verwaltungsaufgaben anstoßen.

Bitte daran denken, dass es nicht möglich ist, hier eine Testseite zu drucken. CUPS kann zwar Daten zum Drucker schieben, hat aber keine Möglichkeit, Inhalte für den Drucker aufzubereiten.

SAMBA Konfiguration

SAMBA installieren wir „wie gehabt und falls noch nicht sowieso schon vorhanden“ aus den Paketquellen unserer Linux-Distribution:

sudo apt-get install samba

Hier ein Beispiel, wie meine /etc/smb.conf aussieht. Die bereits bestehende Datei dient uns als Vorlage, Kommentarzeilen habe ich zwecks Übersichtlichkeit weggelassen.

In diesem Zusammenhang sei erwähnt, dass SAMBA diverse Dienste eines Windows-Servers anbietet: Unter anderem funktioniert die Software als File- und Printserver sowie – wenn konfiguriert – als Domain Controller. In meinem Fall beschränken wir uns auf eine einfache Workgroup-Funktionalität. Wer SAMBA nutzt, sollte sich natürlich über diese Anleitung hinaus mit seiner Konfiguration auseinandersetzen. Hier geht es nur um den Drucker!

[global]
   workgroup = ALTMETALLER
   log file = /var/log/samba/log.%m
   max log size = 1000
   logging = file
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user

[homes]
   comment = Home Directories
   browseable = yes
   read only = no
   create mask = 0600
   directory mask = 0700
   valid users = %S

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no
   write list = root, @lpadmin 

Sicher sehen gewisse Teile der Datei bei Ihnen etwas anders aus. Letztendlich entspricht vieles der Default-Konfiguration des Linux-Distributors. Zu überprüfen bzw. sicherzustellen wären zumindest die farblich hinterlegten Einstellungen.

Das wären:

workgroup = ALTMETALLER

Die klassische Windows-Arbeitsgruppe. Also genau die, die wir auch auf den Windows-Rechnern nutzen.

write list = root, @lpadmin

Die Zugriffsberechtigungen für die Treiberfreigabe.

Hintegrund: Jeder Windows-Printserver verfügt über eine versteckte Freigabe mit der Bezeichnung print$ (genau genommen sorgt das $-Zeichen am Ende dafür, dass diese nicht direkt angezeigt wird und „versteckt“ ist). In dieser Freigabe liegen die Druckertreiber, die später an die Clients verteilt werden.

Ich habe hier die Gruppe lpadmin hinzugefügt. Das bedeutet, dass unser Benutzer „altmetaller“, den wir vorhin der Gruppe lpadmin hinzugefügt haben, schreibend auf diese Freigabe zugreifen und somit Druckertreiber hinterlegen darf.

Dieses Privileg ist mit einer gewissen Verantwortung verbunden!

Die Treiber werden den Clients installiert und laufen dort mit administrativen Rechten. Es wäre also möglich, dass ein Benutzer aus dieser Gruppe Schadsoftware hinterlegt, die dann nach und nach auf den Clients installiert wird und spätestens beim Drucken gestartet wird.

Wer ein Problem damit hat, setzt die „write list“ später wieder auf root zurück. Es bietet sich aber an, den Benutzer weiterhin in der Gruppe lpadmin zu belassen, da dieser ja auch das CUPS steuert.

SAMBA nutzt eine eigene Passwortdatenbank. Unsere lokalen Linux-Benutzer tauchen dort noch nicht auf. Das ändert man, indem man mit smbpasswd ein Kennwort für den jeweiligen Nutzer festlegt.

Selbiges machen wir für den Benutzer, der die Drucker verwalten soll. In meinem Fall also für den Benutzer „altmetaller“:

sudo smbpasswd -a altmetaller

Zusätzlich bekommt der Benutzer „root“ ebenfalls ein Kennwort verpasst:

sudo smbpasswd -a root

Warum root auch ein SAMBA-Konto benötigt?

Ganz einfach: Wir benötigen administrativen Zugriff auf die SAMBA-Datenbank, um dem Benutzer altmetaller ein zusätzliches Privileg zu gewähren. Der Root-Account wird also für diesen Befehl genutzt:

sudo net rpc rights grant altmetaller SePrintOperatorPrivilege -U root

Mit diesem Befehl gewähren wir dem Benutzer „altmetaller“ das Recht, die Drucker mit der Windows-Managementshell zu verwalten.

Der Befehl fragt noch ein Kennwort ab. Abgefragt wird natürlich das SAMBA-Kennwort, dass wir gerade für den Benutzer „root“ vergeben haben.

Noch einmal zusammengefasst: Unser Benutzer „altmetaller“ hat aufgrund seiner Zugehörigkeit zur Gruppe lpadmin drei Privilegien:

• Er kann mit http://ip.adresse.des.raspberry.pi:631/admin/ das CUPS verwalten um z.B. Druckaufträge zu löschen, Drucker hinzuzufügen usw. Siehe vorangegangenes Kapitel 🙂
• Er hat, wie in diesem Kapitel beschrieben, Schreibzugriff auf das Verzeichnis mit den Druckertreibern. Wer das ausprobieren möchte, kann testweise auf einem Windows-Client die Freigabe \ip.adresse.des.raspberry\print$ aufrufen und dort testweise einen leeren Ordner anlegen (…und im Anschluss wieder löschen).
• Er hat das „SetPrintOperatorPrivilege. Wozu das dient – siehe nächstes Kapitel 🙂

Hinzufügen des Druckertreibers über die MMC

Zur Vorbereitung benötigen wir den Treiber in einem entpackten Format. Bei allen Geräten lässt sich der Treiber in Form einer ausführbaren Datei herunterladen.

Die .EXE Datei lässt sich – wie ein .ZIP Archiv – mit einem entsprechenden Programm entpacken. Ich benutze dafür 7-Zip.

Als Ergebnis erhalten wir einen Ordner, in dem die entsprechenden Treiber und die benötigten .INF Dateien vorhanden sind. Wir suchen die .INF Dateien und merken uns, wo diese abgelegt sind.

Die Installation des Treibers erfolgt nicht auf unserem System, sondern auf dem Printserver. Genau genommen wir der Treiber nicht auf dem Server installiert, sondern lediglich in der Freigabe PRINT$ abgelegt.

Hierfür bemühen wir uns der Microsoft Management Concole (MMC). Wir drücken Windows-R, geben mmc.exe in und klicken auf „OK“ um das Programm zu starten.

Über „Datei Snap-In hinzufügen/entfernen“ (Strg-M) erhalten wir eine Auswahl der zur Verfügung stehenden Snap-Ins:

Im linken Bereich wählen wir „Druckerverwaltung“.

Wir klicken auf „Hinzufügen >“, die Druckerverwaltung taucht dann zusätzlich im rechten Bereich unter „Konsolenstamm“ auf und wir werden gefragt, welchen Druckserver wir verwalten möchten.

Im Feld unter „Server hinzufügen“ geben wir den Hostnamen unseres Printservers ein und klicken auf „Zur Liste hinzufügen“. In diesem Beispiel heißt mein Printserver raspberrypi.lan.tux-net, anstelle des eigenen Hostnames kann natürlich auch eine IP-Adresse angegeben werden.

Falls die Daten, mit denen wir uns unter Windows angemeldet haben von den Zugangsdaten des Linux-Systems abweichen, werden wir nach Zugangsdaten gefragt. Hier gegben wir die Daten von einem (Linux-)Nutzer an, den wir der Gruppe „lpadmin“ hinzugefügt haben. Im vorherigen Kapitel war das der (Beispiel-)Benutzer „altmetaller“.

Wenn das geklappt hat, sehen wir unseren Druckserver im Konsolenstammbaum abgebildet.

Zuerst widmen wir uns den Treiber. Wir klappen unseren Printserver auf, klicken auf „Treiber“ und sehen eine – vermutlich leere – Übersicht aller auf dem Printserver installierten Drucktreiber.

Zusätzliche Treiber installieren wir, in im Treiberbereich mit der rechten Maustaste klicken und im Kontextmenü „Treiber hinzufügen“ auswählen.

Windows startet daraufhin einen Assistenten:

Wir wählen die Architekturen: x86 wäre ein 32-Bit-Windows, x64 wäre ein 64-Bit-Windows.

Bitte bachten: Es handelt sich nicht um die Architektur unseres Printservers, sondern um die Architekturen, für die unser Printserver Treiber vorhalten soll.

Mit x86 und x64 sollten wir also ganz gut bedient sein.

Eine der wenigen Sachen, die unter Windows 10 immer noch so aussehen wie unter Windows 95, sind die pottenhässlichen und unübersichtlichen Dialoge zur Installation von Gerätetreibern 🙁

Wie klicken auf „Datenträger…“ und hangeln uns mit dem Explorer zu dem Verzeichnis, in dem wir den Treiber entpackt haben. Dort markieren wir die passende INF-Datei und klicken auf „Öffnen“.

Es folgt eine Übersicht aller Gerätetreiber in dem entpackten Archiv. Hier markieren wir den Drucker und klicken zuerst auf „Weiter >“…

…und danach auf „Fertig stellen“.

Die Meldung „Installation abgeschlossen“ ist etwas irreführend. Der Treiber wird auf den Printserver in die Freigabe print$ kopiert, aber sicher nicht auf dem Printserver installiert^^

Dieser Vorgang erfolgt unter Umständen mehrfach – je nachdem, wie viele Architekturen wir im Assistenten ausgewählt haben.

Der Inhalt der MMC wird häufig nicht sofort aktualisiert, spätestens mit Klick auf den „Aktualisieren“ Button sehen wir dort aber eine Übersicht aller vorhandenen Treiber:

Den Namen des Druckers (inklusive aller Leer- und Sonderzeichen) bitte akribisch auswendig lernen oder – noch besser – notieren.

Wir klicken links im Konsolenstamm auf „Drucker“ und finden eine Liste aller Netzwerkdrucker, die unser Printserver anbietet. Mein Screenshot ist etwas irreführend – vermutlich hat Ihr Drucker noch gar keinen Namen.

Im Kontextmenü des Druckers gehen wir auf „Eigenschaften…“

Die Meldung, dass auf unserem PC noch kein Treiber installiert ist, kann ignoriert werden. Hier darf man ausnahmsweise mal auf „Nein“ klicken.

Auf der Seite „Allgemein“ tragen wir im ersten Eingabefeld den Namen des Druckertreibers ein; und zwar minutiös so, wie wir ihn gerade notiert haben. Also ebenfalls inklusive aller Leer- und Sonderzeichen.

Wir erinnern uns: Im CUPS wird unser Drucker als „RAW“ angesprochen und über einen (USB-)Anschluss abgebildet. Das sind gleich zwei Dinge, die unser Windows-Client nicht kennt.

Auf der Seite „Anschlüsse“ setzen wir also den Haken, der unseren Printserver anzeigt. Somit weiß der Client schon einmal, wohin er die Druckdaten schubsen soll.

Was noch fehlt, ist das passende Rendering.

Auf der Seite „Erweitert“ wählen wir dann noch den passenden Treiber aus, den wir im vorherigen Abschnitt mit dem Assistenten auf dem Server kopiert haben.

Wir klicken auf „OK“ und sind „eigentlich“ fertig.

Eine Kleinigkeit wäre allerdings noch zu erledigen: Microsoft hat irgendwann im Dunstkreis um Windows 8 / Windows Server 2012 eine Option in Druckerfreigaben eingeführt, die „Druckauftragsaufbereitung auf dem Client durchführen“ heißt. Diese ist standardmäßig nicht gesetzt.

Das heißt: Unser lokales Client-Windows geht grundsätzlich solange davon aus, dass die Druckaufbereitung auf dem Server erfolgt, bis der Server anderswünschiges mitteilt.

Diese Mitteilung kann Samba nicht senden.

Wir müssen also etwas beherzt in die Registry unseres Windows-Clients eingreifen und dem PC sagen, dass er die Druckaufträge selber rendern und lediglich „rohe“ Druckdaten zum SAMBA-Server schieben soll.

Der entsprechende Registry-Key lautet:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers]
"ForceCSREMFDespooling"=dword:00000000

…das Ergebnis. Oder: Warum wir den ganzen Zinober veranstaltet haben… 🙂

In der Netzwerkübersicht sehen wir – sobald wir den SAMBA-Server aufrufen – den Drucker.

Um den Drucker auf unserem System zu installieren, wählen wir im Kontextmenü verbinden…

…bestätigen den kurzen Vertrauensbeweis mit „Installieren“…

…und – sind fertig! Der Treiber wird auf dem Rechner installiert und wir können im Anschluss sofort „losdrucken“.

Selbstverständlich funktioniert diese Form der Installation auch mit etablierten Mechanismen zur Verteilung von Druckern wie Gruppenrichtlinen usw…