Cups a remote printing v F20

Servery a sítě
1

Do F19 vsechno fungovalo. Pokud v F20 tisknu na vzdaleny F20 server, tak tisk skonci s

SpliX Cannot open job

(tiskarna je samsung). V logu serveru jsem nasel

PID 31631 (/usr/lib/cups/filter/rastertoqpdl) stopped with status 4.

takze jsem hodnou chvili hledal, jak se ten filter vlastne pousti, protoze samozrejme k tomu zadna dokumetnace neni

gs -dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS -sDEVICE=cups -dcupsCompression=14 -sOUTPUTFILE=reference.raster reference.pdf
PPD=/etc/cups/ppd/Samsung-SCX-4500-Series.ppd /usr/lib/cups/filter/rastertoqpdl 431 jb foo 1 bar=foo reference.raster

ovsem to normalne funguje, dokonce i soubory, co jsou ve spoolu jako zrusene jsem po rozbaleni gzipem normalne mohl tisknout (lp jmeno_souboru) - a v tom je ten problem. Soubory v F20 chodi zrejem uz z hosta zkonvertovane (profiltrovane) rastertoqpdl, na serveru se pak snazi rastertoqpdl konvertovat soubor znovu, coz skonci chybou a tisk neprobehne.

Na hostech jsou tiskarny “nainstalovany” pres DNSSD (tedy autodiscovery).

Tusi nekdo jak to ma fungovat, resp. jak presvedcit hosta, aby soubory posilal nekonvertovane? V F19 to zrejme (uz to nemuzu vyzkouset) chodilo nekonvertovane.

2

Podle popisu problému, by to mělo nefungovat vždy, když uživatel na stroji s FC 20 tiskne přes CUPS na tiskárnu připojenou k serveru s FC20…?
Je ta chyba reprodukovatelná na jiné tiskárně?
Nebo je to problém specifický pro Samsung?

Mám sice jinou tiskárnu, ale přesně v této konfiguraci jsem to měl a vesele jsem tisknul. Tedy na desktopu FC20 64b KDE, na serveru FC 20 64b XFCE. Nyní jsem oba počítače FEDUPnul na FC 21 a tisknu vesele dál.

Takže otázka je, proč se u vás oba stroje nedomluví na formátu tiskového souboru a u mě jo. (Tzn. nebude to systematická chyba)

Můžeme to vystopovat u mě, kde se co filtruje a gzipuje na cestě od uživatele do tiskárny.

3

Ano popsal si to spravne. Tak to NEfunguje. Jinou tiskarnu na vyzkouseni nemam, ale uz me taky napadlo, jestli to neni tim “driverem”. Jenze ten se vubec nemeni, je uz nekolik generaci Fedory stale stejny.

V logu je ze prijdou data
File of type application/vnd.cups-raster queued by “remroot”.
rastertoqpdl (application/vnd.cups-raster to printer/Samsung-SCX-4500-Series, cost 0)
jenze data zrejme neprijdou jako raster, ale uz jako qpdl. Tedy pokud to, co zustane v /var/spool/cups je skutecne to co prislo k tisku z klienta.

Kazdopadne diky, prave jsem potreboval aspon mit moznost porovnat s nekym komu to treba funguje. Co mas ve webove administraci k tiskarne na klientech?

Description: Samsung SCX-4500
Location: server
Driver: Samsung SCX-4500, 2.0.0 (grayscale, 2-sided printing)
Connection: dnssd://Samsung%20SCX-4500%20Series%20%40%20server._ipp._tcp.local/cups
Defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided

Jde mi hlavne o ten zpusob pripojeni a jestli driver ma byt skutecne driver te tiskarny, nebo jen nejaky “dummy”. Uz totiz neverim nicemu.

4

Tak jsem nasel podobny stary bug v debianu a konecne trochu stopu
https://lists.debian.org/debian-printing/2013/08/msg00088.html

jedna se tedy zrejme o problem s nastavenim mime typu odesilaneho klientem. Proc k tomu dochazi je ale obtizne ladit, protoze na klientu nejsou zadne zaznamy, co s tiskem dela.

5

covex napsal(a):

Co mas ve webove administraci k tiskarne na
klientech?

Dnes večer se k to mu dostanu fyzicky, jsem asi 30 km jinde. Ono by to šlo pozapínat na dálku (kromě tiskárny), ale radši budu u toho na místě. Tak se pak ozvu.

6

Popis: HP_LaserJet_Professional_M1217nfw_MFP
Umístění:
Výrobce a model: HP LaserJet Professional m1217nfw MFP, hpcups 3.14.10, requires proprietary plugin (barevná, oboustranný tisk)
Připojení: hp:/net/HP_LaserJet_Professional_M1217nfw_MFP?ip=192.168.70.194
Nastavení: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided

7

No tak to pripojeni je teda zase neco uplne jineho… s tim mime jsem zatim nic nevymyslel, jde s tim nejak manipulovat pres lpoptions, ale ja to nechci nastavit navrdo…

8

Jo, ta moje tiskárna má rozhraní Ethernet, je na stejné síti jako ostatní počítače. I když ji desktop vidí, tak tisknu přes CUPS na serveru.
Moje teta má podobnou tiskárnu, která ale nemá Ethernet, nýbrž USB. Můžu zkusit si nainstalovat “vzdálenou tiskárnu”, mám k ní VPN. Měl by to pak být obdobný případ jako u Vás. Ale je to HP, nikoliv Samsung.

9

Z F19 to se stejnym nastaveni jde z F20 ne, takze to bude bug… nic jineho uz ne nenapada.

10

https://bugzilla.redhat.com/show_bug.cgi?id=1180859

11

Jako workaround mi mezi Debianem (server - CUPS 1.5.x) a Gentoo (klient - CUPS 1.7.x) funguje toto:

  1. Vytvorit filtr (napr. rastertosame) s obsahem:

ondrada filter # cat /usr/libexec/cups/filter/rastertosame


#!/bin/bash
set -x
[ -n "$6" ] && exec <"$6"
cat

a nastavit mu execute prava


ondrada filter # chmod 755 /usr/libexec/cups/filter/rastertosame

Tento filtr co dostane, to posle dal

  1. Na klientovi upravit .ppd tiskarny, radek (napr. z moji Xerox Phaser 3140)

*cupsFilter: "application/vnd.cups-raster 0 rastertoqpdl"

upravit na


*cupsFilter: "application/vnd.cups-raster 0 rastertosame"

a toto PPD pouzit (nebo ho upravit rovnou v /etc/cups/ppd)

  1. Server nechat byt s puvodnim PPD

Vysledkem by mel byt funkcni tisk pres IPP. Nicmene je to jen hnusnej hack… Zacalo se to projevovat po aktualizaci Gentoo na klientovi na CUPS 1.7.x s proprietarnim ovladacem (rastertosamsungspl, tehdy na serveru bylo Hardened Gentoo CUPS 1.5.x nebo 1.6.x, uz nevim, ale aktualizace na 1.7 nepomohla) a dela to i se SpliXem, takze je to pravdepodobne zmena chovani CUPS 1.7 a jeho bug, nebo nejaky nastaveni, ktery mi uniklo…

12

Je to bug, ktery jsem odkazoval. Filtr jsem si zkousel taky delat, ale nejak mi to nefungovalo a hlavne se mi to nechce upravovat na vsech klientech. I tak diky.