Bug 88303

cc'd redhat-config-network maintainer

Harald: is this the right fix?

I'm a bit puzzled, since I have network-shared printers working absolutely fine
on a fresh kickstart Red Hat Linux 9 install.

So when is the first path used for ifcfg-* files, and when is the other one
used?  And which one should printconf look at?

Okay, reproduced.  There is also a further problem with DHCP-configured
interfaces; investigating.

Created attachment 91040 [details]
Proposed patch

Here's the patch I plan on using.

do not use /etc/sysconfig/networking ...

The current rawhide package (0.6.53-1) has this fixed.  Needs an RHBA.

backend.py is generating unecessary Listen statements which are killing cupsd.

I'm using Red Hat 9 with redhat-config-printer-0.6.47-1.

Senario: I have a central server which will share queues to many clients.
I restrict access to one (of many) of my queues to a specific IP address,
say, 137.92.140.81. The other queues are shared to a network range
137.92.140.0/255.255.255.0. This then triggers the following code at
the very bottom of backend.py.

# Interfaces to listen on
if len (ipaddr) != 1 or ipaddr[0] != "*":
    cupsd_conf_lines.append ("Listen 127.0.0.1:631\n")

for each in ipaddr:
    cupsd_conf_lines.append ("Listen %s:631\n" % each)


Which produces in my cupsd.conf:

Listen 127.0.0.1:631
Listen 137.92.140.81:631

Subsequently, I get a cupsd error 'cannot bind to address' on the
second Listen line. If I delete the second line, cupsd runs but
remote clients don't send jobs to it because it's only listening
to localhost. If replace all Listen lines with just

Port 631

cupsd accepts jobs from remote clients and will honour the restrictions
on the restricted queue via the correctly generated Allow/Deny attributes.

I don't believe you can have two sockets listening on the same port.
I suspect the Listen statement is intended to allow cupsd to
Listen on different ports and the IP address spec simply sets up
filters within cupsd for a bit of extra security.

I suspect that the code above should only emit

Listen 631

or a single computed all-encompassing range of the individually
Allowed From IP addresses. In my case that might be

Listen 137.92.140.0/255.255.255.0:631

But I don't know that that's even necessary. Leave that to iptables.

No, the code is as intended: you can listen on several different addresses to
the same port.

This works for me, and netstat -tlp shows:

tcp        0      0 192.168.1.7:631    0.0.0.0:*               LISTEN 4716/cupsd
tcp        0      0 127.0.0.1:631      0.0.0.0:*               LISTEN 4716/cupsd

Also, with LogLevel debug, error_log shows:

D [05/Jun/2003:10:45:19 +0100] StartListening: address=7f000001 port=631
D [05/Jun/2003:10:45:19 +0100] StartListening: address=c0a80107 port=631

So I don't think your problem is due to there being several different Listen
lines.  If there are any duplicated identical Listen lines that would cause
problems though.

I've put an unofficial package which fixes several problems at:
ftp://people.redhat.com/twaugh/tmp/redhat-config-printer-0.6.47.6-1.src.rpm

Use 'rpmbuild --rebuild redhat-config-printer-0.6.47.6-1.src.rpm' to generate
the binary RPMs.

Created attachment 92166 [details]
Uniques the Listen and BrowseAddress lists

Thanks! I see what you've done and that works.

I also get duplicate browserequest broadcast addresses, which suggests that
both
the ipaddr and broadcast lists should be uniqued. I've included a patch against

your unofficial source RPM that I think does this. Changes are all in
grok_sysconfig_files.

Thanks, I've added this fix too.

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-2003-125.html