Bug 975822 - Printing not possible or held in local queue
Printing not possible or held in local queue
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cups-filters (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-19 08:17 EDT by Thomas Woerner
Modified: 2013-07-09 21:34 EDT (History)
3 users (show)

See Also:
Fixed In Version: cups-filters-1.0.35-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-09 21:34:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cups-browsed.conf (940 bytes, text/plain)
2013-06-19 08:17 EDT, Thomas Woerner
no flags Details
cupsd.conf (4.40 KB, text/plain)
2013-06-19 08:18 EDT, Thomas Woerner
no flags Details
printers.conf (1.18 KB, text/plain)
2013-06-19 08:18 EDT, Thomas Woerner
no flags Details
lpstat -s output (224 bytes, text/plain)
2013-06-19 08:19 EDT, Thomas Woerner
no flags Details
cups-browsed --debug output (17.90 KB, text/plain)
2013-06-19 08:20 EDT, Thomas Woerner
no flags Details

  None (edit)
Description Thomas Woerner 2013-06-19 08:17:02 EDT
Created attachment 762914 [details]
cups-browsed.conf

Description of problem:
The cups server is running on a RHEL-6 machine and working with Fedora up to version 18. With Fedora 19, cups-browsed is needed to get the printers locally. But printing does not work:

With evince and gedit, the printers are in the list, but the Print button is insensitive for all printers. Only selecting printing into a file makes the button sensitive. For all printers the state is: "Getting printer information failed"

With okular I can submit the print job to the printer, according to the print dialog. But is queued locally and never makes it to the print server.

Stopping cups-browsed results in the removal of the printers and also the jobs locally.

Version-Release number of selected component (if applicable):
cups-filters-1.0.34-7.fc19.x86_64
cups-1.6.2-9.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Try to print with evince/gedit or okular

Actual results:
Print button in evince/gedit insensitive
Prints jobs submitted with okular held locally

Expected results:
Prints coming out of the printer :-)
Comment 1 Thomas Woerner 2013-06-19 08:18:00 EDT
Created attachment 762915 [details]
cupsd.conf
Comment 2 Thomas Woerner 2013-06-19 08:18:55 EDT
Created attachment 762916 [details]
printers.conf
Comment 3 Thomas Woerner 2013-06-19 08:19:26 EDT
Created attachment 762917 [details]
lpstat -s output
Comment 4 Thomas Woerner 2013-06-19 08:20:00 EDT
Created attachment 762918 [details]
cups-browsed --debug output
Comment 5 Tim Waugh 2013-06-19 10:46:06 EDT
"Getting printer information failed" means that the GTK+ print dialog couldn't get the PPD for the printer.

When you are able to submit a job to the local queue, it stays there.  It fails but in a way that means retries are fine.

My guess is that it's a DNS issue.  The server is advertising the queues as being on "server.fritz.box", but can the client resolve that name?

What output do you get from this?:

python <<"EOF"
import cups, os
c=cups.Connection("server.fritz.box")
s=c.getPPD("Brother")
print s
p=cups.PPD(s)
os.unlink(s)
EOF
Comment 6 Thomas Woerner 2013-06-25 05:14:37 EDT
This is the output:

$ python <<"EOF"
> import cups, os
> c=cups.Connection("server.fritz.box")
> s=c.getPPD("Brother")
> print s
> p=cups.PPD(s)
> os.unlink(s)
> EOF
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
cups.IPPError: (1280, 'No printer-uri found')
Comment 7 Tim Waugh 2013-06-25 06:29:18 EDT
What does 'lpstat -h server.fritz.box -t' say?
Comment 8 Thomas Woerner 2013-06-25 06:36:03 EDT
lpstat -h server.fritz.box -t
scheduler is running
no system default destination
lpstat: Bad Request
lpstat: Bad Request
lpstat: Bad Request
lpstat: Bad Request
lpstat: Bad Request
Comment 9 Tim Waugh 2013-06-25 07:20:41 EDT
Out-of-band we figured out that adding "ServerAlias server.fritz.box" to cupsd.conf on the server end solved these problems.

That leaves the question of why this was not needed for Fedora 18.
Comment 11 Tim Waugh 2013-06-25 08:07:47 EDT
The reason is that although the CUPS server is sending out URIs with IP addresses for the server component, cups-browsed is translating them into hostnames if it can.  It just shouldn't do this.
Comment 12 Jiri Popelka 2013-06-26 10:18:37 EDT
(In reply to Tim Waugh from comment #11)
> The reason is that although the CUPS server is sending out URIs with IP
> addresses for the server component, cups-browsed is translating them into
> hostnames if it can.  It just shouldn't do this.

Neither I can see any reason why we should reverse-lookup them.

(In reply to Tim Waugh from comment #9)
> Out-of-band we figured out that adding "ServerAlias server.fritz.box" to
> cupsd.conf on the server end solved these problems.

how does it work then ?
does it send the uri as
ipp://server.fritz.box:631/printers/Brother
instead of
ipp://192.168.178.254:631/printers/Brother  (or whatever the ip address of the cups server is)

but that shouldn't help as I understand it, see below ...

(In reply to Tim Waugh from comment #5)
> My guess is that it's a DNS issue.

+1 some DNS problem seems to be the trigger.
Thomas' machine is able to reverse-lookup 192.168.178.254 -> server.fritz.box
but not lookup server.fritz.box -> 192.168.178.254 ?
Comment 13 Jiri Popelka 2013-06-26 10:36:47 EDT
(In reply to Jiri Popelka from comment #12)
> Neither I can see any reason why we should reverse-lookup them.

I removed that code completely. Thomas, can you try
http://koji.fedoraproject.org/koji/taskinfo?taskID=5546427
Comment 14 Tim Waugh 2013-06-26 10:57:36 EDT
Jiri: when cupsd on server.fritz.box does a reverse lookup for its own IP addresses, it just gets 'server', not the FQDN.  That means it thinks that being addressed as server.fritz.box (a name it doesn't recognise) might be a DNS rebinding attack and denies the request. :-/

Adding 'ServerAlias server.fritz.box' made cupsd happy again.

So yes, the CUPS Browsing packet had an IP address in the URI, and cups-browsed did a reverse lookup to get a hostname instead (and shouldn't do this).
Comment 15 Thomas Woerner 2013-07-01 08:47:56 EDT
The testing package cups-filters-1.0.34-9.fc19 is working.

Thanks, Thomas.
Comment 16 Fedora Update System 2013-07-01 09:11:07 EDT
cups-filters-1.0.35-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cups-filters-1.0.35-2.fc19
Comment 17 Jiri Popelka 2013-07-01 09:47:35 EDT
reported upstream
https://bugs.linuxfoundation.org/show_bug.cgi?id=1141
Comment 18 Fedora Update System 2013-07-01 20:35:55 EDT
Package cups-filters-1.0.35-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.35-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-12139/cups-filters-1.0.35-2.fc19
then log in and leave karma (feedback).
Comment 19 Fedora Update System 2013-07-09 21:34:28 EDT
cups-filters-1.0.35-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.