Bug 109942

Please try this experimental fix:

ftp://people.redhat.com/twaugh/tmp/redhat-config-printer-0.6.79.1-1.i386.rpm
ftp://people.redhat.com/twaugh/tmp/redhat-config-printer-gui-0.6.79.1-1.i386.rpm

Does that fix the problem for you?

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.

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.

Aha, fixed another bug.  New testing package on the way..

Please try redhat-config-printer-0.6.79.2-1, available in the same place.

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?

For me, the correct Listen line is added.  Does the problem persist if
you do this (as root)?: printconf-backend --force-rebuild

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

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.

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.

Okay, that's what is catching it out.  It's checking for mask
equality, not mask inclusion.  Will fix.

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.

jeskritt: you *must* state what version you are using, or else I can't
act on what you say.

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.

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.

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

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

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.

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

Created attachment 99187 [details]
Computer-A_cupsd.conf with multiple defined ques

Created attachment 99188 [details]
Computer-A_printconf.log   printconf-tui -Xexports spewage

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