Red Hat Bugzilla – Bug 335341
upgrades leave stale cupsd.conf sharing bits
Last modified: 2008-06-02 06:47:28 EDT
Description of problem: After installing USB printer and sharing it, it is not possible to print from OS X machine. Version-Release number of selected component (if applicable): cups-1.2.12-4.fc7 How reproducible: print from OS X to a printer attached to FC7 Steps to Reproduce: 1.add new printer in OS X and select the one attached to FC7 box and make it default 2.print from OS X Actual results: OS X says 'printing error' Expected results: page should be printed Additional info: The printer is discovered by the OS X box just fine (thanks to MDNS support) and after it is added no page cannot be printed from any application. I have verified by tcpdump that the FC7 box receives traffic from the OS X box. Firewall and SELinux are disabled on the FC7 box. The log file says it all: [root@erazim cups]# tail access_log 10.0.1.50 - - [16/Oct/2007:22:33:57 +0200] "GET /printers/printer2.ppd HTTP/1.1" 403 0 - - 10.0.1.50 - - [16/Oct/2007:22:35:30 +0200] "GET /printers/printer2.ppd HTTP/1.1" 403 0 - - 10.0.1.50 - - [16/Oct/2007:22:35:30 +0200] "GET /printers/printer2.ppd HTTP/1.1" 403 0 - - localhost - - [16/Oct/2007:22:36:21 +0200] "POST / HTTP/1.1" 200 327 CUPS-Get-Printers successful-ok localhost - - [16/Oct/2007:22:36:21 +0200] "POST / HTTP/1.1" 200 129 CUPS-Get-Classes successful-ok localhost - - [16/Oct/2007:22:36:21 +0200] "POST / HTTP/1.1" 200 122 Get-Printer-Attributes successful-ok localhost - - [16/Oct/2007:22:36:21 +0200] "POST / HTTP/1.1" 200 124 Get-Printer-Attributes successful-ok localhost - - [16/Oct/2007:22:36:22 +0200] "POST / HTTP/1.1" 200 203 Get-Printer-Attributes successful-ok localhost - - [16/Oct/2007:22:36:22 +0200] "GET /ppd/printer2.ppd HTTP/1.1" 200 11232 - - localhost - - [16/Oct/2007:22:36:22 +0200] "POST / HTTP/1.1" 200 149 Get-Jobs successful-ok While the OS X box (10.0.1.50) uses '/printers' the localhost (FC7 box) uses '/ppd'.
That isn't the problem, I'm afraid -- note the '200' status code, which means it was successful. Can you attach the PPD file you're using please, so I can test it with OS X here? Thanks.
No, the status code 200 is only reported for localhost and printing from the workstation to directly attached printer works fine. See the lines for 10.0.1.50 and the 403 codes - this means 'permission denied'. As for the PPD file: I am using Canon Pixma iP4200 driver which can be downloaded from http://software.canon-europe.com/files/soft24302/software/iP4200_Linux_260.tar.gz The PPD file itself is located in /usr/share/cups/model/canonip4200.ppd. 'printer2' is the name of the printer I have configured on 'localhost' which is FC7.
I think the problem is in the path. Compare the following: machine OS request (reported in log file) return code +------------+---------+-------------------------------------+--------------+ localhost FC7 GET /ppd/printer2.ppd HTTP/1.1 200 10.0.1.50 OS X GET /printers/printer2.ppd HTTP/1.1 403
Created attachment 231381 [details] traffic dump starting with autodetecting the printer Attached is a dump of a traffic starting with MDNS based autoconfiguration of the printer on the OS X machine and later followed by an attempt to print a page. It is obvious that the server reports 403 (Permission denied) error to the client (the OS X box).
I can now confirm it was indeed caused by wrong setting of access control in /etc/cups/cupsd.conf. Now the relevant section looks like this: <Location /printers/printer2> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 10.0.1.50 AuthType None </Location> and printing from 10.0.1.50 (OS X box) works fine. This is definitely a bug in system-config-printer because when I setup the printer first I entered name 'printer' and then tried another setting so I created 'printer2' and removed 'printer'. However, cupsd.conf still contained '/printers/printer' and not '/printers/printer2'. Also, setting of the hosts which are allowed to print is not possible via system-config-printer. And last but not least: even if the 'share all printers' is ticked in system-config-printer entries in cupsd.conf are still created with default deny setting.
system-config-printer does not modify /etc/cups/cupsd.conf except for the 'Server Settings' Boolean values, and has not done so since Fedora Core 6. Whatever put that Location section in /etc/cups/cupsd.conf, it was not system-config-printer in Fedora 7. Is this an upgrade from Fedora Core 5 (or earlier) by any chance?
Weird. I am not 100% sure that the '/printers/printer' entry was not in cupsd.conf before I started configuring the printer but rational thinking makes me believe it could not be there. (I doubt that '/printers/printer' is some special entry installed by default) The upgrade path of the machine went like this: FC4 fresh install -> FC5 upgrade -> FC6 upgrade -> FC7 upgrade Anyway, configuring shared printer in FC7 is not user friendly, to put it lightly. This report should be at least switched to RFE and moved to appropriate component to make that problem addressed. Also, the printer is discovered automa(g)tically via mDNS/avahi but then it is not possible to print on it remotely. There should definitely be smarter. Not advertising the printer if it is in default deny state makes more sense.
I think you've been unlucky in that upgrades leave cupsd.conf in exactly the state it was in. The whole idea in Fedora Core 6 and onwards is that we don't fiddle with configuration files but instead use the CUPS API for configuring it. I think you'll find that if you replace /etc/cups/cupsd.conf with the as-shipped version (there should be a /etc/cups/cupsd.conf.rpmnew file there), your experience will be a lot more user-friendly. Regarding the publishing of unprintable printers -- in Fedora Core 6 and onwards, unshared printers are *not* published. However, this particular printer was shared but not printable-to due to special policy written before the FC-6 upgrade. I really am going to stand by that the system-config-printer in F-7 did not put that Location section in /etc/cups/cupsd.conf. If it got there after your upgrade, some other application put it there. (You aren't using KDE by any chance..?)
Hm, that's kind of sad backwards compatibility story. I'd expected that the application (seems there no such thing) responsible for configuring printing permissions would read cupsd.conf in and presented it to user which could make the changes via GUI and it will be then translated back to the ASCII representation and saved to cupsd.conf again. (and no, no KDE in sight :))
So perhaps system-config-printer needs to detect this situation when it fetches cupsd.conf, and offer to update it. (Trouble is, this might be hard to get right.)
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I don't think I'm going to be able to get to this.