Cups-PDF druckt nicht richtig.

[KBDCALLS]

Cups-PDF schreibt beim drucken immer ein PDF mit einer Größe von 2286 Bytes. Versucht man das zu lesen bekommt man nur eine leere Seite zu sehen. Vor längerer Zeit hab ich Cups so eingerichtet das die PDFs ins /var/spool/cups nicht gelöscht werden. Und die sind OK . Also die vom richtigen Drucker (Kyocera 6230CDN ) und auch die von Cups-PDF Hat da jemand eine Idee was dahinterstecken könnte ? Ob mir da apparmor reinpfuscht?

Ich habe ein aktuelles Testing.

[DeletedUserReAsG]

Ob mir da apparmor reinpfuscht?

Möglich. Hat AppArmor nicht so ’nen Audit-Modus, oder wie das da genannt wird, in dem statt zu blocken erstmal geloggt wird?

[KBDCALLS]

Ob apparmor einen audit Modus hat muß ich mal checken. Der einzigen Hinweis auf apparmor war im Log von aptitude das am 11.9 eine neue Datei usr.sbin.cupsd installiert wurde. Und seitdem macht cups-pdf die Sperenrzchen.

[eggy]

apt-cache show printer-driver-cups-pdf in sid sagt :

Beachten Sie, dass AppArmor die Ausgabe von PDF-Dokumenten
in nicht standardmäßige Verzeichnisse verhindert. Daher muss
</etc/apparmor.d/usr.sbin.cupsd> ebenfalls bearbeitet werden,
wenn die oben genannten Standardeinstellungen in
</etc/cups/cups-pdf.conf> geändert werden.
.
In Fällen, in denen das System Basisverzeichnisse von anderen
Pfaden als </home/> bereitstellt, bearbeiten Sie stattdessen
</etc/apparmor.d/tunables/home>.
.
Desktopnutzer finden vielleicht die Verwendung der von GTK+ und
QT bereitgestellten Funktion »In Datei drucken« oder der Funktion
»Exportieren nach PDF« von LibreOffice einfacher.

siehe auch https://packages.debian.org/de/sid/prin ... r-cups-pdf

[KBDCALLS]

Ich muß mal die beiden ausgetauschten Dateien miteinander vergleichen. Auch wenn ich an Konfig von cups-pdf geändert habe kanns nicht an den Verzeichnissen liegen. Das Problem tritt ja auch mit der Originalkonfig von cups-pdf auf. Mal sehen ob ichda den richtigen Riecher habe, das Teil mal komplett disablen. Und dann mal sehen was passiert.

[MSfree]

Mir erscheint es unlogisch, daß es mit AppArmor zusammenhängt. Wenn eine 2286 Bytes lange Datei erstellt werden kann, warum sollte AppArmor den Rest des Inhalts verhindern?

Ich hatte in der Vergangenheit immer mal wieder nach Upgrades Probleme mit dem CUPS-PDF-Printer. Das war allerdings noch unter Jessie. Da hatte es immer geholfen, den PDF-Printer im CUPS-Webinterface zu entfernen und danach neu hinzuzufügen.

[eggy]

@msfree: Ich nehme an, erstellen ist ok, modizifieren nicht. Das würde erklären, dass das Grundgerüst immer da ist, der Rest aber scheitert. Vielleicht muss man auch bei gs suchen (der Drucker war doch auf ghostscript Basis oder irre ich da)? Bei einigen von den PDF-Tools (convert etc) gabs ja in den letzten Monaten/Jahren immer wieder pseudoSecurity, die dafür gesorgt hat, dass man an das "ja, mir ist klar, dass das ne dumme Idee ist"-Flag explizit setzen musste.

[KBDCALLS]

Mittlerweile ist der Übeltäter doch gefunden. Es war Ghostscript. Nach apparmor hatte ich noch Cups im Verdacht . Aber die warens beide nicht. Bin ich aber auch erst drauf gekommen nachdem ich mir ältere schon erstellte PDFs und den Krüppel mit view angesehen habe, und da mal nach PRODUCER gesucht haben.

• pdf:Producer='GPL Ghostscript 9.53.3'
  
  %%Invocation: path/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=? -dAutoR otatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress ? ? -f ?
  
  ===============================================================================
  
  pdf:Producer='GPL Ghostscript 9.54.0'
  
  %%Invocation: path/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=? -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress ? ?

Übrigens hatte ich mir noch beide Konfigfiles usr.sbin.cupsd mit diff angesehen. Der einzige Unterschied war das eine Zeile für lentsencrypt eingefügt worden ist.