Bug 147005
Summary: | default configuration for ServerName doesn't work (ipp server) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jim Kingdon <kingdon> |
Component: | cups | Assignee: | Tim Waugh <twaugh> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | mattdm |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-07-11 12:01:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jim Kingdon
2005-02-03 16:45:34 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. 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. |