Bug 88303 - cupsd.conf missing Listen networks for shared printing
cupsd.conf missing Listen networks for shared printing
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-printer (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2003-04-08 14:38 EDT by Christopher Wong
Modified: 2007-04-18 12:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-07 12:36:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (2.41 KB, patch)
2003-04-09 07:54 EDT, Tim Waugh
no flags Details | Diff
Uniques the Listen and BrowseAddress lists (2.90 KB, patch)
2003-06-05 11:29 EDT, Ross Johnson
no flags Details | Diff

  None (edit)
Description Christopher Wong 2003-04-08 14:38:39 EDT
The redhat-config-printer utility misgenerates /etc/cups/cupsd.conf for the case of a 
printer shared over the network. CUPS needs to be told to listen to the network where 
service requests will come from. But after specifying a network and sharing, the 
resulting cupsd.conf only has "Listen". Needless to say, listening only on 
the local loopback will not make network printing work very well. 
The problem is that backend.py is looking in /etc/sysconfig/networking/devices for ifcfg-* 
files. That directory is empty. Anaconda installs the ifcfg-* files in 
/etc/sysconfig/network-scripts. Changing the relevant glob.glob() call to look in the latter 
directory will cause "printconf-backend --force-rebuild" to insert the appropriate "Listen" 
Note: I could not get this far until I used the fix in #88291.
Comment 1 Tim Waugh 2003-04-08 16:20:26 EDT
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?
Comment 2 Tim Waugh 2003-04-09 07:41:39 EDT
Okay, reproduced.  There is also a further problem with DHCP-configured
interfaces; investigating.
Comment 3 Tim Waugh 2003-04-09 07:54:52 EDT
Created attachment 91040 [details]
Proposed patch

Here's the patch I plan on using.
Comment 4 Harald Hoyer 2003-04-09 08:17:35 EDT
do not use /etc/sysconfig/networking ...
Comment 5 Tim Waugh 2003-05-06 05:08:51 EDT
The current rawhide package (0.6.53-1) has this fixed.  Needs an RHBA.
Comment 6 Ross Johnson 2003-06-05 05:30:21 EDT
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, The other queues are shared to a network range 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\n")

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

Which produces in my cupsd.conf:


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


But I don't know that that's even necessary. Leave that to iptables.
Comment 7 Tim Waugh 2003-06-05 05:50:01 EDT
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*               LISTEN 4716/cupsd
tcp        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:

Use 'rpmbuild --rebuild redhat-config-printer-' to generate
the binary RPMs.
Comment 8 Ross Johnson 2003-06-05 11:29:20 EDT
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
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
Comment 9 Tim Waugh 2003-06-09 06:10:36 EDT
Thanks, I've added this fix too.
Comment 10 Tim Waugh 2003-07-07 12:36:36 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.


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