Bug 182487 - system-config-printer sharing with specified subnet not working
system-config-printer sharing with specified subnet not working
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: system-config-printer (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-22 15:43 EST by D. Hugh Redelmeier
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-13 13:02:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description D. Hugh Redelmeier 2006-02-22 15:43:22 EST
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 15:43:22 EST
Created attachment 125054 [details]
output of printconf-tue --Xexport
Comment 2 D. Hugh Redelmeier 2006-02-22 15:46:25 EST
Created attachment 125055 [details]
cupsd.conf generated
Comment 3 D. Hugh Redelmeier 2006-02-22 16:36:51 EST
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 09:12:20 EST
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 11:22:44 EST
==== 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 11:59:59 EST
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 13:02:33 EST
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.