Red Hat Bugzilla – Bug 88303
cupsd.conf missing Listen networks for shared printing
Last modified: 2007-04-18 12:52:51 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 127.0.0.1:631". 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.
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
Created attachment 91040 [details]
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, 188.8.131.52. The other queues are shared to a network range
184.108.40.206/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 != "*":
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:
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
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
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.
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
I've put an unofficial package which fixes several problems at:
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
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
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.