Das CUPS-Drucksystem und der Windows-Server

Einen Linux-Client mit z.B. aktuellem Gnome-Desktop mit einem fernen Drucker auf einem Windows-System zu verbinden kann sehr tückisch sein.

Folgende Situation: Ein im Internet erreichbarer PDF-Formular-Drucker soll via https (= mit Verschlüsselung) von Linux-Clienten angesprochen werden.

Die Ziel-URL lautet: https://printserver.secure.company/printers/UberPrinter/.printer

Grundproblem: Das Ziel versteht nur IPP v1.0
=> Der Default von CUPS ist seit einer Weile v1.1 oder gar v2.0

Problem 2: Viele Distibutionen bringen in Ihrer aktuellen Version kein CUPS backend mit das SSL unterstützt
(Fehlen von "ipps" und "https" in /usr/lib/cups/backends/)
Ein anderer Test zur Überprüfung ist:
ldd /usr/lib/libcups.so | grep ssl
Ist das Ergebnis leer, wird kein SSL unterstützt.

=> Lösung: Distributionsspezifisch selber kompilieren.

Problem 3: Selbst wenn nun - die selbstkompilierte oder das "hauseigene" Paket - SSL unterstützen ist der Erfolg noch nicht garantiert.
Oftmals tritt das hier beschriebene Phänomen auf:
http://permalink.gmane.org/gmane.comp.printing.cups.general/29589

D.h. der Job wird ggf. erfolgreich übermittelt, nur bekommt CUPS kein sinnvolles Feedback.
Was in Version CUPS 1.4 zum Abbruch und ab Version 1.5 (von CUPS) zu einer Schleife führt.

Allgemein zu beachten ist noch, das CUPS nicht zwingend automatisch den Fallback auf Version IPP 1.0 schafft.

Dem kann man mit einem Anhängsel in der URL vorbeugen:
https://printserver.secure.company/printers/UberPrinter/.printer?version...

Fazit: Alles in Allem scheint es keine allgemeingültige Lösung für diese Aufgabenstellung zu geben. Am besten ist es wohl wenn man sich auf Ziele beschränken kann die wenigstens Version 1.1 des IPP Protokolls sprechen.