(28. März 2007 — tk)

Druckprobleme abseits Helios

Zwei Klassiker aus der Reihe »beliebte Fehler, die einen gerade kurz vor knappen Terminen bevorzugt in den Wahnsinn treiben«… Im Folgenden betrachten wir zwei Problemszenarien, die zwar eigentlich gar nichts direkt mit Helios zu tun haben aber trotzdem regelmäßig nerven und die Produktionssicherheit nachhaltig gefährden:

Problem 1 manifestiert sich in Druckjobs, die nie beim Server ankommen. Am Mac-Client wird aus einer beliebigen Anwendung heraus losgedruckt, das Ganze dauert bei großen Druckjobs auch durchaus seine Zeit… aber der Job kommt nie am Helios-Server an. Kein Eintrag in den Logs, nichts, einfach weg…
Problem ist meistens die eingesetzte PPD, die seit MacOS X 10.2 vom Drucksystem des Macs grundsätzlich anders gehandhabt wird als vorher. Denn seit 10.2 ist CUPS wesentlicher Bestandteil des MacOS’ Drucksystems (und hat am Mac so seine Besonderheiten). Und CUPS erweitert die Rolle von PPDs (»*PostScript* Printer Description«) dahingehend, daß einerseits PPDs auch für nicht PostScript-fähige Drucker zum Einsatz kommen und andererseits Definitionen über den Werdegang eines Druckjobs bereits fix in der PPD kodiert werden können.

Normalerweise bestimmt den Weg, den ein Druckjob unter MacOS X nimmt, alleine die CUPS Filter Chain , die durch nach Prioritäten gestaffelte Einträge in den *.convs- und *.types-Dateien unterhalb /etc/cups definiert wird. Allerdings kann schon direkt in der PPD darauf Einfluß genommen werden — durch »*cupsFilter«-Einträge wie bspw.

*cupsFilter: "application/vnd.cups-postscript 0 fierycupsfilter"

Kommt eine solche PPD zum Einsatz, so muß unbedingt auch im CUPS’ Filter-Verzeichnis der entsprechende fierycupsfilter liegen — unter MacOS X also in /usr/libexec/cups/filter. Tut er das nicht, so wird der Druckjob beim Versuch, durch diesen Filter (der nur reine Accounting-Aufgaben übernimmt, also für das Druckergebnis irrelevant ist) geschleift zu werden, einfach ins Nirvana umgeleitet. Genau das passiert oftmals, wenn man ein Drucksystem mit Fiery-RIP (oder auch OKI, da wird auf /usr/libexec/cups/filter/OKJAfilter verwiesen) auf einem Mac einrichtet nur unter Zuhilfenahme der PPD ohne den originären Installer, der dann ggf. auch die Filter unterhalb /usr/libexec/cups/filter installieren würde.

Dummerweise wird das erstmal nirgendwo deutlich. Um darauf einen Hinweis zu bekommen, müsste man zuerst mal CUPS’ LogLevel hochsetzen , damit dann in /var/log/cups/error_log ein Hinweis zu finden ist (einsehbar per »Konsole.app« oder mittels tail -f /var/log/cups/error_log in Terminal.app).

Also: Verschwinden Druckjobs generell oder nur von vereinzelten Rechnern ohne daß davon auch nur Spuren am Helios-Server erkenntlich sind (siehe »Drucker Log-Datei« in HELIOS Admin bzw. nicht mal »papsrv«-Einträge in der »Server Log-Datei«), so sollte die PPD, die am Client eingesetzt wird, genauer betrachtet werden. Zeilen, die mit *cupsFilter beginnen, müssen unbedingt ein entsprechendes Pendant in Form eines sog. »CUPS Filter« unterhalb /usr/libexec/cups/filter haben, da andernfalls der Druckjob in den Weiten des MacOS X’ Drucksystems versandet.

Problem Nr. 2 hat ebenfalls mit PPDs zu tun. Ein neuer Drucker wird angeschafft, der Admin richtet dafür eine OPI-fähige Queue am Helios-Server ein, die ersten Druckjobs laufen problemlos… bis irgendwer auf die Idee kommt, mal eine A4-Doppelseite gedreht auf dem neuen Drucker auszugeben (wohlgemerkt mit aktivem OPI auf dem Server). Auffälliges Resultat: Die Bilder sind teils weg, teils angeschnitten.

Ursache ist dabei eine simple Einstellung in der PPD, die die Rotation des Seiteninhalts bei der Anwahl von Querformat-Ausgabe betrifft — die Einstellung nennt sich *LandscapeOrientation:. Und es gibt zwei Alternativen: Minus90 und Plus90. Anwender, bei denen letzteres in der PPD auftritt, haben erstmal oben beschriebenes Problem. Abhilfe: Fix der PPD, so daß es *LandscapeOrientation: Minus90 lautet (siehe auch den entsprechenden Artikel in der Quark Knowledge Base )

Problem bei beiden Phänomenen, wenn viele Clients im Spiel: Die PPDs liegen bereits auf den Macs (unterhalb /etc/cups/ppd), so daß ein Fix beider Probleme es notwendig macht, ggf. auf allen Macs im Netz Nachforschungen bzgl. PPDs zu betreiben (Helios stellt erst mit einer »demnächst« erscheinenden Erweiterung ihres »TCP/SLP Druckertreiber« die Möglichkeit in Aussicht, daß PPD-Updates vom Server Richtung Client signalisiert werden können — wie üblich ohne konkrete Zeitangabe ;-)

D.h. bisserl Skripting seitens des Admins vor Ort… oder aufwändiges manuelles Austauschen der PPDs (das unbedingt von einem Neustart des Macs bzw. des CUPS-Drucksystems — killall -SIGHUP cupsd — begleitet werden sollte). Der Autor dieses Artikels hat allerdings für obige Aufgabenstellung (inkl. Update der PPDs auf den Clients bei Änderung am Server) bereits Werkzeuge in der Schublade :–)

Geht es nur um das Identifizieren potentieller PPD-Störenfriede, so helfen die beiden folgenden Kommandos, die in »Terminal.app« auf dem jeweiligen Mac abzusetzen sind:

Der folgende ätzende Bandwurm (copy&paste-tauglich aber ohne Gewähr :-) findet alle PPDs, die die CUPS Filter Chain verbiegen wollen ohne daß die entsprechend nötigen Filter auf dem Mac vorhanden sind (Problemlage Numero uno weiter oben):

grep "^*cupsFilter" /etc/cups/ppd/* | while read ppd ; do \
MyFilter=$(echo ${ppd} | awk -F" " '{print $4}' | sed 's/\"$//'); \
ls /usr/libexec/cups/filter/${MyFilter} >/dev/null 2>&1 || \
basename $(echo "${ppd}" | cut -d":" -f1) .ppd ; done | sort | uniq

Die Ausgabe erfolgt anhand des »internen« CUPS-Queue-Namens auf dem Mac, der aber hinreichend aussagekräftig sein sollte, um den Spooler an sich zu identifizieren.

Und das Folgende entlarvt Spooler-Definitionen auf dem Mac, deren PPD bei Verwendung per OPI zu Problemen führt:

grep "Plus90" /etc/cups/ppd/* | cut -d":" -f1 | while read -r ppd ; \
do basename ${ppd} .ppd; done | sort | uniq

Nicht wundern, wenn da relativ viel auftaucht. Aber MacOS X’ interne Queues à la »Internes Modem« und Konsorten sind schlichtweg uninteressant, da nur Queues von Bedeutung sind, mit denen auch Richtung ImageServer gedruckt wird, da nur dann die Diskrepanz zwischen OPI-Spezifikationen und »beliebiger Rotationsrichtungen« in der PPD zum Tragen kommt.

Finalmente: Es gibt Druckprobleme, die auf den ersten Blick kausal verknüpft mit der lokal existenten Helios-Installation scheinen, es dann aber bei näherer Betrachtung doch nicht sind, weil deren Ursprung rein PPD-bedingt am Client zu lokalisieren ist. Nervig ist das ganze allemal… und der Schuldige scheint auch automatisch festzustehen, da der Kram ja nur »mit Helios« auftritt :-)

Aber ganz so einfach ist es eben (fast) nie ;-)

Grundsätzlich bei Druckproblemen die PPDs im Auge behalten und neben Blick in MacOS X’ /var/log/cups/error_log auch Helios’ »Server Log-Datei« (hier sind die papsrv-Einträge spannend — fehlen die, kommt der Druckjob nicht mal bis zum Server) und »Drucker Log-Datei« immer auch mal mit »neutralen« PPDs gegentesten und gucken, ob das spezifische Problem nicht schon alleine damit aus der Welt zu schaffen bzw. dessen Ursache in Form einer maladen PPD ausfindig zu machen ist.

Anbei noch beide obige Checks der Bequemlichkeit halber als kleines Applet zum Download, das gleich die eigentlichen Druckernamen wie aus dem »Drucker Dienstprogramm« bekannt ausgibt (das allerdings dazu ein Administrator-Kennwort braucht, damit es lesend auf die Definitionen in /etc/cups/printers.conf zugreifen kann. Der Code des Applet wie folgt:

#!/bin/bash

GetFilterProblems() {
    grep "^*cupsFilter" /etc/cups/ppd/* | while read ppd ; do 
        MyFilter=$(echo ${ppd} | awk -F" " '{print ${4}}' | \
        sed 's/\"$//')
        ls /usr/libexec/cups/filter/${MyFilter} >/dev/null 2>&1 \
        || basename $(echo "${ppd}" | cut -d":" -f1) .ppd
    done | sort | uniq | while read -r printer ; do 
        grep -A2 "<<-End-of-Skript
    tell app "System Events"
        activate
        display dialog "${ErrorMsg}"
    end tell
End-of-Skript

Copyright © Thomas Kaiser, 2008 (erstellt Mittwoch, 28. März 2007)

Dieser Beitrag kann durch jedermann gemäß den Bestimmungen der Lizenz für die freie Nutzung unveränderter Inhalte genutzt werden. Die Lizenzbedingungen können unter http://www.uvm.nrw.de/opencontent abgerufen oder bei der Geschäftsstelle des Kompetenznetzwerkes Universitätsverbund MultiMedia NRW, Universitätsstraße 11, D-58097 Hagen, schriftlich angefordert werden.