[Thinlinc-technical] TL v4.5 : failure printing from Ubuntu-agent (was: Windows-client)
Rob De Langhe
rob.de.langhe at twistfare.be
Mon Nov 23 21:41:32 CET 2015
and the saga continues ...
On Ubuntu 14.04LTS, the package "cups" contains CUPS software 1.7.2
This CUPS software version is documented to contain a 'patch' which
effectively breaks the job-content filtering.
Nowhere it is explicitly documented if a more recent version of CUPS would
no longer contain that 'patch', so I tried the following :
1) Contacted CUPS authors for more information : radio-silence ... :-(
2) found latest CUPS software version to be v2.1.0
3) found that only in "cups" package of Ubuntu 15.10, this v2.1.0 is
bundled
4) upgraded master and agent servers to Ubuntu 15.10, now they run "cups"
package with this latest CUPS software version:
# dpkg -l cups
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii cups 2.1.0-4ubunt amd64 Common UNIX
Printing System(tm) -
5) had TL setup with the local print queue (thinlocal) only
6) checked that printing works fine from my Ubuntu 14.04LTS client to a
local printer : OK
7) tried printing a single one-page from a session on the agent; as far as
the agent is concerned all goes smoothly : nothing in
/var/log/cups/error_log, and a succesfull print log in
/var/log/cups/access_log :
localhost - - [23/Nov/2015:21:18:27 +0100] "POST /printers/thinlocal
HTTP/1.1" 200 21526 Print-Job successful-ok
8) on the client the job is accepted from the agent
# tail /var/log/cups/access_log
...
localhost - - [23/Nov/2015:21:18:27 +0100] "POST /printers/MFCJ6510DW
HTTP/1.1" 200 317 Create-Job successful-ok
localhost - - [23/Nov/2015:21:18:27 +0100] "POST /printers/MFCJ6510DW
HTTP/1.1" 200 21541 Send-Document successful-ok
but nothing gets printed and the job remains queued in /var/spool/cups :
# ls -ltr
-rw-r----- 1 root lp 21278 nov 23 21:18 d00013-001
-rw------- 1 root lp 794 nov 23 21:18 c00013
# file d00013-001
d00013-001: PDF document, version 1.5
In the beginning of the file, I see
# head -7 d00013-001
%PDF-1.5
%...
3 0 obj
<< /Length 4 0 R
/Filter /FlateDecode
>>
stream
(and then a bunch of binary data)
9) I remembered the 'workaround' suggested in the Redhat forum for this
incorrect print-job filtering issue, namely setting the printer queue as
'raw' :
(agent)# lpadmin -p thinlocal -m raw
After a restart of the "cups" service, this changed
"/etc/cups/printers.conf" from
<Printer thinlocal>
...
MakeModel Generic postscript printer
...
Type 4180
into
<Printer thinlocal>
...
Type 4
10) then tried the printing again, but still not joy and exactly the same
behaviour (job queued on client), printer status on client is happily idle
as if nothing decent is queued for printing:
# lpstat -t
scheduler is running
system default destination: MFCJ6510DW
device for MFCJ6510DW: ipp://10.50.0.4/
MFCJ6510DW accepting requests since ma 23 nov 2015 21:18:38 CET
printer MFCJ6510DW is idle. enabled since ma 23 nov 2015 21:18:38 CET
Ready
The queued file from this print-attempt seems to contain now some
indication of a 'application/vnd.cups-raw' job :
# od -c /var/spool/cups/c00014
...
0001260 d o c u m e n t - f
o r m a t \0
0001300 030 a p p l i c a t i o
n / v n d
0001320 . c u p s - r a w A \0
031 j o b -
0001340 p r i n t e r - s t
a t e - m e
0001360 s s a g e \0 \0 D \0 031 j
o b - p r
0001400 i n t e r - s t a t
e - r e a s
0001420 o n s \0 004 n o n e 003
=> anyone with a clue about how printing is $!**# possible with TL ?
with kind regards,
Rob
Citeren Pierre Ossman <ossman at cendio.se>:
> On Sat, 07 Nov 2015 16:20:56 +0100
> Rob De Langhe <rob.de.langhe at twistfare.be> wrote:
>
>> The bug description refers to another bug filed at Redhat, bug
>> "https://bugzilla.redhat.com/show_bug.cgi?id=1010580"
>>
>> In this bug, it is not so clear to me whether there is finally some
>> patch, the only 'workaround' I see more or less described as
>> succesfull, is setting the printer driver on the client side (I
>> assume that, in the context of ThinLinc, that is the agent because
>> there the print job is initiated) to "raw" so that the client side is
>> not doing any job-content filtering.
>
> There's a lot of technical details on that bug so it's not terribly
> easy to follow. The story is basically this:
>
> - A user could print to his printer locally but not remotely.
>
> - The bug turned out to be that CUPS is sending the right data, but
> putting an incorrect type label on it. This is only noticeable when
> using an advanced protocol like IPP in combination with having the
> printer driver early in the chain. This is a fairly uncommon setup.
>
> - Red Hat "fixed" the bug by forcing everything leaving CUPS to be
> tagged as raw data. This is the correct type in most cases when
> sending to a printer. It is not the correct type for advanced queues
> like thinlocal.
>
> - The "fix" got removed once we pointed out that this was an incorrect
> way of handling things.
>
> - Users are now experiencing the original bug again, which can be
> worked around by configuring one of the queues as raw.
>
> That's why the workaround does nothing for you. It solves a different
> bug.
>
> The reason thinlocal doesn't work is because the "fix" is broken. To
> get thinlocal working you have to remove that "fix". Red Hat has
> already done so, but Ubuntu are still using it.
>
>> -> puzzled as to whom to contact to get this resolved ... As least I
>> wanted to share my findings (or lack of...) with anyone here who's
>> investigating the same issues on Ubuntu.
>
> It's only Canonical that can fix this properly. They are the ones
> compiling the CUPS package for you.
>
> Rgds
> --
> Pierre Ossman Software Development
> Cendio AB https://cendio.com
> Teknikringen 8 https://twitter.com/ThinLinc
> 583 30 Linköping https://facebook.com/ThinLinc
> Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc
>
> A: Because it messes up the order in which people normally read text.Q:
> Why is top-posting such a bad thing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cendio.se/pipermail/thinlinc-technical/attachments/20151123/f5b35d05/attachment-0003.html>
More information about the Thinlinc-technical
mailing list