Bug 182487 - system-config-printer sharing with specified subnet not working
Summary: system-config-printer sharing with specified subnet not working
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-printer
Version: 4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-22 20:43 UTC by D. Hugh Redelmeier
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-01-13 18:02:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of printconf-tue --Xexport (3.36 KB, text/plain)
2006-02-22 20:43 UTC, D. Hugh Redelmeier
no flags Details
cupsd.conf generated (21.67 KB, text/plain)
2006-02-22 20:46 UTC, D. Hugh Redelmeier
no flags Details

Description D. Hugh Redelmeier 2006-02-22 20:43:22 UTC
Description of problem:
I have a local printer which I wish to share on my LAN via IPP.
I configure it with system-config-printer.  Including sharing.
Other machines do not see the queue.

Note: this worked in FC3.

When I look in /etc/cups/cupsd.conf, the subnet CIDR block is mentioned nowhere
(unlike in FC3).  Based on the FC3 version, the following things seem to be missing:
[for each queue]
  Allow from 192.139.70.64/255.255.255.192
[Global, at end]
  BrowseAddress 192.139.70.127
  Listen 192.139.70.122:631

The output of "printconf-tui --Xexport" on the FC4 system does mention the LAN
subnet.  I have attached a copy.


Version-Release number of selected component (if applicable):
system-config-printer-0.6.131.3-1


How reproducible:
Every time that I've tried.

Steps to Reproduce:
1.system-config-printer
2.select queue
3.Action:Sharing...
4.Add...
5.Network address
6.fill in network address and mask
7.OK
8.OK
9.Apply
  
Actual results:
other machines cannot see the queue
/etc/cups/cupsd.conf does not reflect the network specified

Expected results:
otehr machines can see the queue
/etc/cups/cupsd.conf reflects the network specified

Additional info:
Since system-config-printer overwrites /etc/cups/cupsd.conf every time, it seems
pointless to hand-edit the config file.

Comment 1 D. Hugh Redelmeier 2006-02-22 20:43:22 UTC
Created attachment 125054 [details]
output of printconf-tue --Xexport

Comment 2 D. Hugh Redelmeier 2006-02-22 20:46:25 UTC
Created attachment 125055 [details]
cupsd.conf generated

Comment 3 D. Hugh Redelmeier 2006-02-22 21:36:51 UTC
As a work-around, I tried adding sharing for anything on Network devices eth0.
This too made NO change to cupsd.conf.

Then I gave up and said "All hosts".  That seems to have caused changes to
cupsd.conf.  Remote printing seems to work.  Queue changes percolated very
slowly between the machines (something to do with "browsing", I think).

Comment 4 Tim Waugh 2006-02-23 14:12:20 UTC
Sounds like rhpl.ethtool isn't working right.

Please change the settings back to 'Network devices eth0', and try this as root:

echo '#!/usr/bin/python' > /tmp/printconf-backend
cat /usr/sbin/printconf-backend >> /tmp/printconf-backend
chmod a+x /tmp/printconf-backend
/tmp/printconf-backend --force-rebuild

What does it say?

Comment 5 D. Hugh Redelmeier 2006-02-23 16:22:44 UTC
==== Output: ====
Rebuild forced on command line
Add 'clawlex' configuration to /etc/cups/printers.conf
Add 'clawlex' configuration to /etc/cups/cupsd.conf
Create /etc/cups/ppd/clawlex.ppd
PPD generated.  Adjusting options.
Set page margins: *ImageableArea Letter/US Letter: "36 36 576 756"
For interfaces: ['@IF(eth0)']
ipaddr: ['192.139.70.88']
broadcast: ['192.139.70.127']
==== end of output ====

Interesting: looks reasonable.  The /etc/cups/cupsd.conf reflects this too. 
Stupidly, I didn't take a snapshot after I went back to eth0 but before issuing
the commands you requested, so I don't know what fixed the /etc/cupsd.conf.

The first line of /usr/sbin/printconf-backend is "#!/usr/bin/python -O"
so your command sequence effectively just suppressed this -O.  Do you suspect
that python optimization is a problem?  For what it is worth, I'm using Fedora
Core's python-2.4.1-2 for x86_64.

Comment 6 Tim Waugh 2006-02-23 16:59:59 UTC
The '-O' just suppresses these debugging messages.  In theory, you just did what
pressing 'Apply' would have done, except for restarting the CUPS daemon.

Strange that it didn't work before.

Comment 7 John Thacker 2007-01-13 18:02:33 UTC
Given the last couple messages, this sounds irreproducible.  I suppose I'll have
to close it, then.  Also note that FC4 is no longer supported except for Fedora
Legacy, and s-c-p has been completely rewritten for FC6.


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