Bug 147005 - default configuration for ServerName doesn't work (ipp server)
Summary: default configuration for ServerName doesn't work (ipp server)
Alias: None
Product: Fedora
Classification: Fedora
Component: cups   
(Show other bugs)
Version: 4
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-03 16:45 UTC by Jim Kingdon
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-11 12:01:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jim Kingdon 2005-02-03 16:45:34 UTC
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):


How reproducible:

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.

Additional info:

The problem can be solved by adding "ServerName" 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).

Comment 1 Tim Waugh 2005-02-03 16:58:16 UTC
"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.

Comment 2 Jim Kingdon 2005-02-04 04:33:55 UTC
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:

Hostname: localhost.localdomain
Primary DNS:  (A server at my ISP)
Secondary DNS:
Tertiary DNS: (blank)
DNS search path: localdomain

The Hosts tab shows no hosts entered.

Hope this is enough.

Comment 3 Tim Waugh 2005-02-08 15:29:27 UTC
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.

Comment 4 Tim Waugh 2005-02-08 15:34:04 UTC
Filed upstream:

Comment 5 Tim Waugh 2005-02-14 13:05:33 UTC
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".

Comment 6 Jim Kingdon 2005-02-14 16:04:09 UTC
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.

Comment 7 Tim Waugh 2005-02-14 16:22:44 UTC
What multicast DNS?  Do you mean howl?  Or DNS in general?

Comment 8 Jim Kingdon 2005-02-15 04:41:10 UTC
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
same name.

Comment 9 Matthew Miller 2006-07-10 20:10:03 UTC
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.

Thank you!

Comment 10 Jim Kingdon 2006-07-10 21:06:41 UTC
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.

Comment 11 Matthew Miller 2006-07-10 21:08:35 UTC
Tim, you interested in tracing this down further still? Moving to fc4 as per
comment #10, which gives us a few more weeks. :)

Comment 12 Tim Waugh 2006-07-11 12:01:13 UTC
There was a fix committed upstream for this, so I'm going to close this now.

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