Bug 109942 - Have to share all printers to share any of them
Have to share all printers to share any of them
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: redhat-config-printer (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-13 03:38 EST by Sitsofe Wheeler
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-12 00:42:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 10:12 EDT, Jef Spaleta
no flags Details
Computer-A_printconf.log printconf-tui -Xexports spewage (14.35 KB, text/plain)
2004-04-07 10:13 EDT, Jef Spaleta
no flags Details

  None (edit)
Description Sitsofe Wheeler 2003-11-13 03:38:23 EST
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):
redhat-config-printer-0.6.79-1

How reproducible:
Always

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 08:20:34 EST
Moved to:

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/i386/

Please verify that these packages fix the problem for you.
Comment 3 Sitsofe Wheeler 2003-11-18 12:59:55 EST
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 /
255.255.255.0 . 

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 1.2.3.1 /
255.255.255.0 (which should represent the local subnet for 1.2.3.1)
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 127.0.0.1 ...

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 08:59:32 EST
Aha, fixed another bug.  New testing package on the way..
Comment 5 Tim Waugh 2003-11-19 12:18:32 EST
Please try redhat-config-printer-0.6.79.2-1, available in the same place.
Comment 6 Sitsofe Wheeler 2003-11-19 15:49:18 EST
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 127.0.0.1)
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 16:23:48 EST
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 03:11:45 EST
Yes the problem persists even after running printconf-backend
--force-rebuild. If the printer is restricted by network address (i.e.
1.2.3.1 / 255.255.255.0) then no Listen line other than 127.0.0.1 is
added.

I've doubled checked and the version of the rpm installed is 0.6.79.2
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 05:20:26 EST
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

Thanks.
Comment 10 Sitsofe Wheeler 2003-11-21 04:43:36 EST
1. (from ifconfig) inet addr:137.44.10.1  Bcast:137.44.10.63 
Mask:255.255.255.192

2. ip: 137.44.10.1 mask: 255.255.255.0 .

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 05:47:22 EST
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 16:03:12 EST
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 17:55:05 EST
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 13:46:29 EST
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 16:15:55 EST
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 06:26:08 EST
Hi,

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

xxx.xxx.240.0/255.255.255.128

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 127.0.0.1
AuthType None
Allow from xxx.xxx.240.0/255.255.255.128
</Location>
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Location>
Browsing On
BrowseProtocols cups
BrowseOrder Deny,Allow
BrowseAllow from @LOCAL
BrowseAddress xxx.xxx.240.127
Listen xxx.xxx.240.45:631
Listen 127.0.0.1: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 127.0.0.1
AuthType None
Allow from xxx.xxx.240.0/255.255.255.128
</Location>
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Location>
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 0.6.79.2.

Bye,

   Jürgen
Comment 17 JM 2004-02-02 06:45:25 EST
Hi,

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 :).

Bye,

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

http://www.redhat.com/archives/fedora-test-list/2004-February/msg00231.html

Please test them out and verify that the problem is indeed fixed.  Thanks.
Comment 19 Jef Spaleta 2004-04-07 10:09:49 EDT
Pretty sure I'm still seeing this with
redhat-config-printer-0.6.79.5-1

Basic setup:
2 boxes both running fedora core 1 on 192.168.1.X/255.255.255.0
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 10:12:17 EDT
Created attachment 99187 [details]
Computer-A_cupsd.conf with multiple defined ques
Comment 21 Jef Spaleta 2004-04-07 10:13:53 EDT
Created attachment 99188 [details]
Computer-A_printconf.log   printconf-tui -Xexports spewage
Comment 22 John Flanagan 2004-05-12 00:42:14 EDT
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.

http://rhn.redhat.com/errata/RHBA-2004-071.html

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