Red Hat Bugzilla – Bug 147005
default configuration for ServerName doesn't work (ipp server)
Last modified: 2008-08-02 19:40:32 EDT
Description of problem:
One has to edit a config file (which is hard to find) in order to make
a Fedora Core 3 box turn into a print server which is automatically
detected and works with Mac OS X clients.
Version-Release number of selected component (if applicable):
Perform a default Fedora Core 3 install (use the default domain/host
names of localhost/localdomain. Don't set up DNS in any way other
than what is provided by default). Check the box in the graphical
print setup to share your printer across the network. Go over to your
Mac OS X client. You will see the printer listed (identified as red
hat printer or some such). Select it. The Mac will hang trying to
connect to localhost.localdomain.
The problem can be solved by adding "ServerName 192.168.0.5" to
/etc/cups/cupsd.conf but of course this solution depends on having a
static IP address. Actually, I don't know whether this is a problem
in cups or in howl or what, but I don't understand this multicast DNS
stuff well enough to really know how any of this should work, or
whether in fact this is CUPS problem (P.S. relevant documentation
seemed to be hard to come by, although I'd rather have it Just Work
than have documentation).
"Don't set up DNS in any way other than what is provided by default" means
different things to different people -- the same goes for "the network".
Do you mean that you tell it to use DHCP?
Perhaps it would be more clear if you tell me what options you set to what on
the network screen while installing.
Yes, I told it to use DHCP. The DHCP server is a NetGear RP614v2
router (which is in turn connected to SBC DSL). The only network
interface (besides lo) is eth0 (SiS900 PCI Fast Ethernet); no wireless.
Not easy for me to go back to the installer network screen (I don't
remember making choices other than "use DHCP"), but in
system-config-network-gui the General tab for eth0 shows:
* Active device when computer starts up (checked)
* Allow all users to enable and disable this device (checked)
o Enable IPv6 configuration for this interface (unchecked)
* Automatically obtain IP address settings with: dhcp
Hostname (optional): _____ (blank)
* Automatically obtain DNS information from provider (checked)
o Statically set IP addresses: (unchecked)
The DNS tab (not interface specific) shows:
Primary DNS: 188.8.131.52 (A server at my ISP)
Secondary DNS: 184.108.40.206
Tertiary DNS: (blank)
DNS search path: localdomain
The Hosts tab shows no hosts entered.
Hope this is enough.
Okay, ServerName is trusting the hostname to be useful, and it isn't
in this instance.
I think the issue is that the DHCP server is not handing out hostnames
as well as IP addresses: however, CUPS should handle that when
ServerName is not specified in the cupsd.conf file.
Would having "BrowseAddress @LOCAL" in the cupsd.conf file by default
(or at least, when at least one queue is shared) fix this problem?
Could you try adjusting /etc/cups/cupsd.conf so that the BrowseAddress
line at the end says "BrowseAddress @LOCAL"? Then restart cups with
"service cups restart".
That doesn't seem to suffice. The MacOS X client gets "unable to look
up host: localhost.localdomain".
As for what my DHCP server is doing, is there a way for me to send you
some output from my DHCP client or something (I'm not sure where to look)?
I'm kind of guessing the solution involves "localhost.local." or
something, but I don't really understand this multicast DNS stuff.
What multicast DNS? Do you mean howl? Or DNS in general?
I did mean howl, but I think it was probably a rash comment - I don't see how
"localhost.local." could work if other machines might be trying to claim that
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
The last time I was running a print server was FC4, and if memory serves this
problem still existed. But go ahead and close the problem - I don't any longer
have the ability/interest in reproducing it.
Tim, you interested in tracing this down further still? Moving to fc4 as per
comment #10, which gives us a few more weeks. :)
There was a fix committed upstream for this, so I'm going to close this now.