CUPS: IPP-Drucker unter Linux (weitgehend) ohne mDNS einrichten

Neuere Netzwerkgeräte veröffentlichen ihren Netzwerkstatus über ein Netzwerkprotokoll namens mDNS (auch Bonjour oder Zeroconf), welches unter Linux clientseitig der Daemon Avahi implementiert. Das betrifft Netzwerkdrucker und seit noch jüngerer Zeit sogar Netzwerkscanner. Im Idealfall führt das dazu, dass man seinen PC nur an ein Netzwerk anschließen muss und schon kann man mit den vorhandenen Geräten drucken oder scannen. Das liegt daran, dass aktuelle Versionen von CUPS, dem Druckermanagement-System von Linux, die Liste gefundener Drucker von Avahi abrufen. Außerdem spielt dabei eine Rolle, dass herstellereigene Druckertreiber zumindest für Netzwerkdrucker seit einiger Zeit zugunsten eines allgemein unterstützten Standardprotokolls namens Internet Printing Protocol (IPP), welches auch in einer TLS-verschlüsselten Variante namens IPPS existiert, verdrängt werden. Da die Linux-Unterstützung von Druckerherstellern meist eher stiefmütterlich war, führt das Vordringen von IPP für Linux zu einer signifikanten Verbesserung der Nutzungsqualität.

So jedenfalls der Idealfall. Probleme entstehen, wenn jeweils für sich auf Benutzerfreundlichkeit getrimmte Programme unabhängig voneinander entwickelt werden. Die Standardlösung zur Verbindung mit Netzwerken unter Linux, der NetworkManager, hat mit Zeroconf nichts am Hut. Das ist zwar aus der Warte dieses auf Netzwerkkonnektivität spezialisierten Programms richtig, führt im Zusammenspiel mit mDNS aber mitunter zu kuriosen Situationen. Um dem Benutzer eine möglichst zuverlässige Verbindung zur Verfügung zu stellen, bucht NetworkManager einen Computer soweit möglich sowohl in ein kabelgebundenes LAN als auch in ein kabelloses WLAN ein. Nun ist es aber – ebenfalls aus Gründen der Usability – so, dass heutzutage WLAN und LAN in Heimnetzwerken üblicherweise auf dem Router in ein einzelnes Netzwerksegment vereinigt werden (Bridge). In Kombination führt dies alles dazu, dass dass derselbe Drucker mehrfach in CUPS auftaucht: einmal für die LAN- und einmal für die WLAN-Schnittstelle.

Das wäre an sich nicht weiter schlimm, wenn das nicht dazu führen würde, dass diese Drucker je nachdem, welches Interface zuerst hochgefahren ist, unterschiedliche Namen bekämen. Manchmal scheint es auch, als ob CUPS schlau genug ist, herauszubekommen, dass es sich um ein und denselben Drucker handelt und legt nur einen Drucker an. Manchmal taucht er aber auch unter einem ganz neuen Namen auf. Kurzum: der Name des Druckers ist damit letztlich bei jeder Verbindung mit dem Netzwerk zufällig. Für automatisiert arbeitende Skripte, die den Druckernamen per Kommandozeilenschalter -d an lp(1) festlegen, ist das nutzlos. Es arbeitet auch nicht gut mit dem Festlegen eines Standarddruckers in CUPS zusammen.

Man kann das Problem umgehen, indem man sich nicht auf die automatische Druckererkennung von CUPS verlässt, sondern den Drucker manuell hinzufügt (im Webinterface von CUPS Verwaltung → Drucker hinzufügen). Dort wählt man den mit „driverless“ gekennzeichneten Netzwerkdrucker aus (nur IPP-Drucker werden so gekennzeichnet) und vergibt ein für allemal einen eigenen Namen. Damit schafft man das Problem aus der Welt. Fügt man den Drucker auf diese Weise hinzu, dann wird er allerdings weiterhin insoweit über mDNS angesprochen, als dass die intern natürlich stets notwendige Feststellung der IP-Adresse des Druckers weiterhin über Avahi abgewickelt wird.

Das kann gewünscht sein, muss es aber nicht. mDNS funktioniert nur, wenn Avahi installiert und aktiv ist, und es kann Gründe geben, Avahi zu deaktivieren. Zu denken ist dabei etwa an große Firmennetzwerke, in denen zahlreiche Netzwerkgeräte mDNS unterstützen und auf diese Weise Avahi derart viel zu tun bekommt, dass der Akkubetrieb des eigenen Laptops darunter leidet. Da man einen Großteil dieser Geräte sowieso nie nutzt (wer will schon auf dem Drucker des Kollegen im Gebäude gegenüber drucken?), schaltet man Avahi schlicht ab. Nur kann man dann gar nicht mehr auf einem mDNS-Drucker drucken.

Auch hierfür gibt es aber eine Lösung. IPP funktioniert ja nicht nur über mDNS, sondern auch mit herkömmlicher DNS-Auflösung. Dazu fügt man den Drucker in CUPS manuell als IPP-Netzwerkdrucker hinzu und wählt als Treiber den Eintrag mit den Worten „driverless, cups-filters“ aus. Diess führt dem Debian-Wiki zufolge dazu, dass CUPS auf Basis der IPP-Spezifikation eine PPD-Datei generiert und – anders als der Treiber „IPP Everywhere“ – noch einen Filter davorschaltet, der einige typische Bugs von IPP-Implementierungen von Druckern auffängt und einige weitere Funktionalität hinzufügt. Anders formuliert: Der Treiber „IPP Everywhere“ konvertiert den Druckauftrag direkt in IPP-Format und verschickt ihn dann unmodifiziert an den Drucker, wohingegen der Treiber „driverless, cups-filters“ noch den Auftrag etwas kuratiert, bevor er an den Drucker über IPP abgeschickt wird.

Als Verbindungs-URI gibt man im CUPS-Webinterface folgendes an:

ipp://hostname:631/rpath

Die Portnummer ist auf 631 standardisiert und sollte daher nicht geändert werden. Statt ipp:// kann man – wenn man sicher ist, dass der Zieldrucker ein gültiges und vom eigenen System anerkanntes TLS-Zertifikat verwendet – auch ipps:// verwenden, um eine verschlüsselte Verbindung zu erreichen. Gerade in kleinen Heimnetzen ist der Vorteil, Druckaufträge verschlüsselt über das Netzwerk zu versenden, aber ein eher theoretischer.

Bei hostname handelt es sich um den Host-Namen des Druckers, wie er dem DNS-Server des lokalen Netzwerkes vorliegt; alternativ kann auch eine IP-Adresse angegeben werden, wenn man sichergestellt hat, dass diese sich niemals ändert. Dies lässt sich entweder durch statische IP-Adress-Konfiguration im Drucker oder durch Konfiguration des Routers derart, dass er dem Drucker stets dieselbe IP-Adresse zuweist, erreichen.

Mehr Probleme als der Hostname bereitet der URI-Bestandteil rpath. Wie instruktiv das Debian-Wiki ausführt, wurde dieser sogenannte “resource path” nie standardisiert. Theoretisch dient er wohl dazu, dass professionelle Druckmaschinen mehrere Pfade anbieten könnten, aber im praktischen Heimgebrauch wird man auf solche Drucker wohl niemals stoßen. Wählt man für rpath einen falschen Wert, erhält man folgende nichtssagende, weil auf das Pfadproblem in keiner Weise Bezug nehmende Fehlermeldung in /var/log/cups/error_log:

W […] Backend returned status 7 (retry job immediately)
E […] Der Druckauftrag wurde nicht angenommen.

Den korrekten Pfad entnimmt man im Idealfall der wohlgepflegten Dokumentation des eigenen Druckers. Da erfahrungsgemäß eine solche meistens nicht vorliegt, kann man stattdessen entweder raten – das Debian-Wiki, anders als das auch hier wenig hilfreiche CUPS-Webinterface, schlägt für aktuelle Geräte /ipp/print vor – oder man benutzt avahi-discover. Dieses Programm wertet die mDNS-Bekanntmachungen im lokalen Netzwerk über Avahi aus und zeigt sie in einer graphischen Benutzeroberfläche an. Dort sucht man den gesuchten Druckereintrag für „Internet Printer“ (IPP) oder „Secure Internet Printer“ (IPPS) heraus und notiert sich die Werte für Address und TXT rp (Abb. 1). Für diesen Vorgang ist es notwendig, Avahi einmalig zu starten; danach kann er wieder deaktiviert werden.

Der Wert von TXT rp ist der gesuchte Ressourcenpfad. Im gezeigten Beispiel lautet er tatsächlich /ipp/print. Daraus ergibt sich folgende URI für CUPS:

ipp://hostname:631/ipp/print

Mit dieser Konfiguration sollte der Drucker nun auch ohne Avahi funktionieren.

Man kann IPP-Drucker unter Linux mit CUPS auf drei Arten betreiben: erstens mit vollständig automatischer Erkennung durch CUPS und Avahi, was sich nur für die einfachsten Fälle anbietet. Zweitens durch halbautomatische Einrichtung, indem man in CUPS einen eigenen, unveränderlichen Druckernamen vergibt, man sich für die konkrete Namensauflösung aber weiterhin auf die automatischen Dienste von Avahi verlässt. Endlich drittens durch vollständig manuelle Konfiguration, die auf Avahi – vom einmaligen Abrufen der Parameter abgesehen – im laufenden Betrieb vollständig verzichten kann. Alle drei Methoden stellte dieser Beitrag vor und gab eine kurze Übersicht, wie sie miteinander zusammenhängen und welche Rolle CUPS, Avahi und IPP dabei spielen.