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): cups-1.1.22-0.rc1.8.4 howl-0.9.6-6 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 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: Hostname: localhost.localdomain Primary DNS: 206.13.28.12 (A server at my ISP) Secondary DNS: 206.13.29.12 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.
Filed upstream: http://www.cups.org/str.php?L1076
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 same name.
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!
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.