Bug 335341 - upgrades leave stale cupsd.conf sharing bits
Summary: upgrades leave stale cupsd.conf sharing bits
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 8
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
 
Reported: 2007-10-16 20:55 UTC by Vladimir Kotal
Modified: 2008-06-02 10:47 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-06-02 10:47:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
traffic dump starting with autodetecting the printer (29.11 KB, text/plain)
2007-10-18 18:40 UTC, Vladimir Kotal
no flags Details

Description Vladimir Kotal 2007-10-16 20:55:57 UTC
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'.

Comment 1 Tim Waugh 2007-10-16 21:28:10 UTC
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.

Comment 2 Vladimir Kotal 2007-10-18 18:28:43 UTC
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.

Comment 3 Vladimir Kotal 2007-10-18 18:31:34 UTC
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



Comment 4 Vladimir Kotal 2007-10-18 18:40:21 UTC
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).

Comment 5 Vladimir Kotal 2007-10-18 19:11:55 UTC
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.

Comment 6 Tim Waugh 2007-10-18 21:53:54 UTC
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?

Comment 7 Vladimir Kotal 2007-10-18 22:11:20 UTC
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.


Comment 8 Tim Waugh 2007-10-18 22:20:54 UTC
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..?)

Comment 9 Vladimir Kotal 2007-10-19 21:27:45 UTC
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 :))

Comment 10 Tim Waugh 2008-01-10 17:42:08 UTC
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.)

Comment 11 Bug Zapper 2008-05-14 14:46:16 UTC
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

Comment 12 Tim Waugh 2008-06-02 10:47:28 UTC
I don't think I'm going to be able to get to this.


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