Bug 109942 - Have to share all printers to share any of them
Summary: Have to share all printers to share any of them
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-config-printer   
(Show other bugs)
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-13 08:38 UTC by Sitsofe Wheeler
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-12 04:42:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Computer-A_cupsd.conf with multiple defined ques (21.60 KB, text/plain)
2004-04-07 14:12 UTC, Jef Spaleta
no flags Details
Computer-A_printconf.log printconf-tui -Xexports spewage (14.35 KB, text/plain)
2004-04-07 14:13 UTC, Jef Spaleta
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:071 normal SHIPPED_LIVE Updated printer configuration tool fixes sharing problems 2004-05-12 04:00:00 UTC

Description Sitsofe Wheeler 2003-11-13 08:38:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
If you have more than one printer and do not share all of them (but
share at least one), the shared printers will not be automatically
detected by remote machines.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up two printers, turning sharing on one but not the other.
2. Browse a remote machines printer queue to check whether the shared
queue turns up.

Actual Results:  Shared queue will not show up on remote machines,
errors appear in /var/log/cups/error_log if you turn cups polling on
saying "cups-polld: Unable to connect to x.x.x.x on port 631:
Connection refused"

Expected Results:  Remote machines to be able to connect but only see
the shared queue and not the unshared queue.

Additional info:

Comment 2 Tim Waugh 2003-11-14 13:20:34 UTC
Moved to:


Please verify that these packages fix the problem for you.

Comment 3 Sitsofe Wheeler 2003-11-18 17:59:55 UTC
Apologies for the very slow reply to this but this is hard for me to
test since I'm stuck on a machine that has no X-server and the text
interface is not as capable as the gui interface...

The updated packages ( Build Date: Thu 13 Nov 2003 11:30:03 ) didn't
fix the problem but perhaps I need to specify what I was doing in more
detail. Further, I've found I can reproduce the problem with just one
printer. I was previously attempting to limit who could send jobs to
the printer by only sharing to a particular netmask of x.x.x.1 / . 

Steps to reproduce:
1. Remove all printers and create one new printer
2. Go to Action -> Sharing...
3. Click add.
4. Choose Network address and enter in an address like / (which should represent the local subnet for
5. Click OK.
6. Click OK.
7. Click Apply.

Unfortunately this still produced the previously mentioned error so I
have given up on restricting by netmask. I suspect this problem may be
because in /etc/cups/cupsd.conf there is no line to tell it to listen
to any interface other than ...

When I restricted by network device the appropriate Listen line was
added but the remote machine had the following in
/var/logs/cups/error_log :

cups-polld: get-printers failed: server-error-service-unavailable

I ended up solving this by manually adding under <Location />
 in /etc/cups/cupsd.conf:
AuthType None
Allow from @IF(eth0)

I do not know if limiting by interface is the same as limiting to the
local subnet though - this is not clear in the help file.

Comment 4 Tim Waugh 2003-11-19 13:59:32 UTC
Aha, fixed another bug.  New testing package on the way..

Comment 5 Tim Waugh 2003-11-19 17:18:32 UTC
Please try redhat-config-printer-, available in the same place.

Comment 6 Sitsofe Wheeler 2003-11-19 20:49:18 UTC
Ok now with a single queue, the remote machine (which has explicit
polling turned on) sees the shared queue (restricted by network
device) and adds it but continues to moan in the error_log about
get-printers every 30 seconds:
Added remote printer "lp"...
cups-polld: get-printers failed: server-error-service-unavailable
cups-polld: get-printers failed: server-error-service-unavailable

Restricting by network address still does not add the appropriate
Listen line to cupsd.conf (there is only a Listen line for
and the remote machine cannot connect to port 631.

Another little hiccup was uncovered while adding / deleting / changing
sharing via the GUI interface. I deleted a printer previously added
via the GUI but it wasn't removed from cupds.conf. Is this a known bug
and if not do you want it spun off into a seperate new bug?

Comment 7 Tim Waugh 2003-11-19 21:23:48 UTC
For me, the correct Listen line is added.  Does the problem persist if
you do this (as root)?: printconf-backend --force-rebuild

Comment 8 Sitsofe Wheeler 2003-11-20 08:11:45 UTC
Yes the problem persists even after running printconf-backend
--force-rebuild. If the printer is restricted by network address (i.e. / then no Listen line other than is

I've doubled checked and the version of the rpm installed is
release 1. The RPMs verified without error other than this:
SM5....T c /etc/alchemist/namespace/printconf/local.adl

Comment 9 Tim Waugh 2003-11-20 10:20:26 UTC
The 'restrict by network address' option needs to figure out which
interface to listen on, and do some maths with the addresses.

Can you let me know:

1. the IP address and netmask of the actual network interface(s) on
that machine

2. the network address and mask that you are telling the tool to
restrict access to


Comment 10 Sitsofe Wheeler 2003-11-21 09:43:36 UTC
1. (from ifconfig) inet addr:  Bcast: 

2. ip: mask: .

I know that the mask set in the tool a different range to that of the
interface but it is intentional.

Comment 11 Tim Waugh 2003-11-21 10:47:22 UTC
Okay, that's what is catching it out.  It's checking for mask
equality, not mask inclusion.  Will fix.

Comment 12 Jonathan Eskritt 2003-12-08 21:03:12 UTC
I've had issues with the Listen lines. If you restrict sharing access
by individual IP, you get a Listen line to trying to listen on each IP
you add to the restriction list. 

If you don't comment out these extra lines cupsd would not start
(child error 99). The error log reports "can't bind to address" or
something similar. I had to comment out all the Listen lines except
the machine's IP and the localhost IP.

Comment 13 Tim Waugh 2003-12-08 22:55:05 UTC
jeskritt: you *must* state what version you are using, or else I can't
act on what you say.

Comment 14 Tim Waugh 2003-12-12 18:46:29 UTC
I'm going to release the testing update as-is for the moment and look
at the netmask problem later on -- it's lower priority I think.

Comment 15 Jonathan Eskritt 2003-12-15 21:15:55 UTC
I'm using fedora core 1. Unfortunately the redhat-config-printer
package has been upgraded since I added comment #12. So I'm not 100%
sure the version #. It would be whatever fedora core used before this
latest update.

Sorry, I couldn't be more specific.

Comment 16 JM 2004-02-02 11:26:08 UTC

I have a similar problem, when I try to share a printer with the
redhat-config-printer tool it creates a completely wrong cupsd.conf
file (without sharing the cupsd.conf is okay).

For example I share the printer and set the Allow Hosts to


then redhat-config-printer creates a cupsd.conf file with this content

# End of "$Id: cupsd.conf.in,v 1.13 2003/04/10 20:14:04 mike Exp $".
# Lines below are automatically generated - DO NOT EDIT
<Location /printers/lokal>
Order Deny,Allow
Deny From All
Allow From
AuthType None
Allow from xxx.xxx.240.0/
<Location />
Order Deny,Allow
Deny From All
Allow From
Browsing On
BrowseProtocols cups
BrowseOrder Deny,Allow
BrowseAllow from @LOCAL
BrowseAddress xxx.xxx.240.127
Listen xxx.xxx.240.45:631

which is completely bogus, because it contains 2 Listen entries which
cups doesn't like at all (it doesn't start). The correct entry would
look like this:

# End of "$Id: cupsd.conf.in,v 1.13 2003/04/10 20:14:04 mike Exp $".
# Lines below are automatically generated - DO NOT EDIT
<Location /printers/lokal>
Order Deny,Allow
Deny From All
Allow From
AuthType None
Allow from xxx.xxx.240.0/
<Location />
Order Deny,Allow
Deny From All
Allow From
Browsing On
BrowseProtocols cups
BrowseOrder Deny,Allow
BrowseAllow from @LOCAL
BrowseAddress xxx.xxx.240.127
Listen *:631

It's just one Listen entry. 

Could you fix this bug? Btw. this bug has RH9 too (I saw it first
there). It's very annoying, because every time I use the tool it
creates the same wrong entry and I must fix it manually. The version
of redhat-config-printer is



Comment 17 JM 2004-02-02 11:45:25 UTC

forget my last comment :). I tested the whole stuff again (created a
complete new set of shared printers) and now cups doesn't complain
because of the two Listen entries. With RH9 I couldn't get it to work
but with FC1 it works. So redhat-config-printer works now perfect for
me :).



Comment 18 Tim Waugh 2004-02-09 16:34:25 UTC
The netmask problem from the first 11 comments in this report should
be rectified in these test update packages for Fedora Core 1:


Please test them out and verify that the problem is indeed fixed.  Thanks.

Comment 19 Jef Spaleta 2004-04-07 14:09:49 UTC
Pretty sure I'm still seeing this with

Basic setup:
2 boxes both running fedora core 1 on 192.168.1.X/
Computer A has 4 or 5 defined ques
Computer B has exactly 1 defined que
Everything is set to share to all hosts (at the moment, but specific
interface sharing has equal results for me, specific host sharing was
not attempted).
Computer A sees the 1 que from Computer B
Computer B sees nothing as shared from Computer A

attachments to follow soonish

Comment 20 Jef Spaleta 2004-04-07 14:12:17 UTC
Created attachment 99187 [details]
Computer-A_cupsd.conf with multiple defined ques

Comment 21 Jef Spaleta 2004-04-07 14:13:53 UTC
Created attachment 99188 [details]
Computer-A_printconf.log   printconf-tui -Xexports spewage

Comment 22 John Flanagan 2004-05-12 04:42:14 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


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