Bug 975822
| Summary: | Printing not possible or held in local queue | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Woerner <twoerner> | ||||||||||||
| Component: | cups-filters | Assignee: | Tim Waugh <twaugh> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 19 | CC: | jpopelka, twaugh, twoerner | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | |||||||||||||||
| 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-10 01:34:28 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 762915 [details]
cupsd.conf
Created attachment 762916 [details]
printers.conf
Created attachment 762917 [details]
lpstat -s output
Created attachment 762918 [details]
cups-browsed --debug output
"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
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')
What does 'lpstat -h server.fritz.box -t' say? 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 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. 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. (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 ? (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 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). The testing package cups-filters-1.0.34-9.fc19 is working. Thanks, Thomas. 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 reported upstream https://bugs.linuxfoundation.org/show_bug.cgi?id=1141 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). 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. |
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 :-)