Description of problem: This is a fresh install from Rawhide with "Set the hostname automatically via DHCP" option at the installation time and has a wired network though, it always shows me "Setting hostname localhost" message on VC. even if ethernet device is up when I can log into the box. Version-Release number of selected component (if applicable): initscripts-8.68-1
The 'setting hostname' is done well before any networking. What's the hostname after you get a DHCP address?
DHCP server gives me a hostname like dhcp-xxx-xxx.example.com and it is reflected to "hostname" certainly on F-8 or before, without any extra work. however not on rawhide. is it a bug in dhcp client or NetworkManager say?
well, to clarify again, hostname is localhost on rawhide box, after getting IP address via DHCP.
NM never changes the hostname of your machine in response to DHCP, because that has historically screwed up xauth, causing applications not to launch in X. That's been mostly fixed, however there are some issues with X's libSM session management that still depend on the hostname being resolvable with gethostbyname(), and may cause delays of up to 30 seconds when launching apps (though they will launch eventually). Can you post the contents of your ifcfg-eth0 file from /etc/sysconfig/network-scripts/ifcfg-eth0 ?
Hmm, okay. I'm not sure why it worked fine in the past. FWIW another rawhide box that is running through upgrading a lot works fine. I don't know what's wrong in one. Anyway, my ifcfg-eth0 on the problematic rawhide box is: % cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Intel Corporation 82566MM Gigabit Network Connection DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:1d:72:84:ec:62 IPV6INIT=yes IPV6_AUTOCONF=yes ONBOOT=yes and similar conf file on another rawhide box that is working fine. guess the problem may be in another place.
It might not have been NetworkManager but all pervious versions of Fedora and RHEL properly set the hostname via dhcp. That is why you are given the "set hostname via dhcp" option during install. It is normally set up by /etc/sysconfig/network-scripts/ifup-post with this bit of code. I have not checked to see if this is not getting run or if it is just failing: eval $(/bin/ipcalc --silent --hostname ${IPADDR} ; echo "status=$?") if [ "$status" = "0" ]; then set_hostname $HOSTNAME fi
While working on another problem: https://bugzilla.redhat.com/show_bug.cgi?id=444502 I tested NetworkManager-0.7.0-0.9.2.svn3614.fc9.x86_64 This "appears" to fix having NetworkManager actaull send the system name so that dhcpd can dynamically update DNS. I do not know if this will fix the problem described here but it may be work a try.
The comment #7 is backwards, that is when the system knows its hostname and tells the DHCP server what it should be. the problem here is when the system does not know what the hostname is and should get it from the DHCP server. This is a big issue in enterprise environments where you have many identical systems (blades for example). I am raising the severity to high. This is not a NetworkManager issue I don't think. In the past this was done by dhclient (my comment in #6 is incorrect I found after digging into it). So, either dhclient is broken OR whatever flag gets set so that dhclient knows it is supposed to set the hostname isn't working (i.e. whatever happens when the users checks the "get hostname from DHCP box at install time).
Heh, ok I take that back.... I guess this IS a network manager problerm. In F7 and before networking was started with by the "network" service. It appears that in F8 NetworkManager is what starts networking. If I do this as a workaround: chkconfig NetworkManager off chkconfig NetworkManagerDispatcher off chkconfig netowrk on everything works just fine. So, it appears NetworkManager does something wrong that the old "network" service started properly.
(In reply to comment #9) > Heh, ok I take that back.... I guess this IS a network manager problerm. In F7 > and before networking was started with by the "network" service. It appears > that in F8 NetworkManager is what starts networking. > Of course what I meant here is in F8 and before it was the "network" service and in F9 NetworkManager appears to be the default way to start networking. I looked in the changelog for "initscripts" and it does appear that the change of not starting "network" by default was intentional: * Mon Mar 10 2008 Bill Nottingham <notting> - 8.65-1 - disable network by default, in favor of NetworkManager
What's the expected behavior here? The ifup-post stuff will get done after every ifup, so if you have eth0 and eth1 whichever you ifup second will set the hostname of the machine. I'm assuming a hostname set in /etc/sysconfig/network overrides anything that ifup-post sets? Or does the ifup-post override /etc/sysconfig/network? For NM, I'd implement per-connection hostnames (where your hostname follows the current "active" device) unless you override the hostname for that connection. Also, that ifup-post bit depends on reverse DNS resolution for the hostname, which is pretty fragile in many situations and will take quite a long time on mobile broadband and modem connections. There's also DHCP-returned hostnames. I'd expect these to take precedence over the ifup-post reverse-DNS hostname attempt unless you've set PEERDNS=no in your ifcfg file, right?
Here is how it worked before F9. 1. if there was a hostname set in /etc/sysconfig/network the hostname would get set to this fairly early in boot and would not get overwritten (this bit still works). 2. if using dhcp, the "network" service would use /sbin/dhclient to bring up the device. then, dhclient would run /sbin/dhclient-script. In this script there is this bit of code: if [ -n "$new_host_name" ] && need_hostname; then hostname $new_host_name fi the "need_hostname" shell function just asks is the current hostname either "(none)", "localhost", or "localhost.localdomain", if it is one of those then it sets the hostname to the info it got back from the dhcp server (the check prevents overwritting the hostname if it was set in /etc/sysconfig/network). This is the bit that does not work in F9. It appears NetworkManager still uses /sbin/dhclient, perhaps it passes a different arg to it which prevents the hostname from being set? I will try to check that today. 3. as a last ditch effort, /etc/sysconfig/network-scripts/ifup-post tries to do a reverse lookup as I describe in comment #6. I agree with your mention about this being fragile as you say in comment #11. I imagine this actually might still work in F9 if the hostname was registered in DNS (in my case it is not).
Ahh, I think this is it. Under NetworkManager it passes this to dhclient: -sf /usr/libexec/nm-dhcp-client.action this overrides the default of /sbin/dhclient-script (which is where the hostname got set in the past). So the fix is to add the same functionality I describe in step 2 of comment #12 to nm-dhcp-client.action.
Yeah, we do need to make NM do what you've listed in comment 13.
I'm not sure this is the same bug, or a bug at all, but when I installed the Fedora 9 test release, one of the menus in the installer (Ananconda) asked what the hostname was. There was an input field that had "localhost.localdomain" in it. (I'm not going to try this again to check, but I think that was it.) I tried clicking in the window to change it, but nothing happened. Thus, I was initially unable to set the hostname during the installation. I was not yet connected to any network, so far as I know. When I finished the installation, I then edited /etc/hosts and /etc/sysconfig/network by hand, but I think Anaconda should have made that unnecessary. (I like to give my computers distinctive names.)
(In reply to comment #15) > When I finished the installation, I > then edited /etc/hosts and /etc/sysconfig/network by hand, But this did not stick. When I rebooted, /etc/sysconfig/network was back to localhost.localdomain, so perhaps this is the same bug, or there are two different bugs, one in Anaconda (that prevents setting hostname) and one somewhere else, perhaps in NetworkManager. (This is the current rawhide version as of 5/2/08.)
NM doesn't ever write out to /etc/sysconfig/network at all, so if you edited the file, and then on reboot it didn't have what you put in there before, that's not going to be an NM issue. Need to find out what writes that file back out.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug still exist in the final version of Fedora 9. So far I use chkconfig NetworkManager off chkconfig network on as workaround. Is there a chance that this bug will be fixed in the near future?
About comment #11 > What's the expected behavior here? The ifup-post stuff will get done after > every ifup, so if you have eth0 and eth1 whichever you ifup second will set > the hostname of the machine. In reality scripts from /etc/sysconfig/network-scripts are somewhat "smarter" than that. /etc/init.d/network is calling those with an extra parameter 'boot' and a name is set only of 'boot' is present _and_ a host name was empty, or was 'localhost', or 'localhost.localdomain' plus some other checks so this name setting will happen only ONCE and it will stick. In particular whatever is set as HOSTNAME in /etc/sysconfig/network has a priority over what '/bin/ipcalc --silent --hostname $ADDR' would provide. I am not really sure why this 'boot' marker was needed. It looks like a "micro-optimization" to prevent later attempts to reset hostname (which should not happen anyway). Or maybe to prevent a case when an ONBOOT interface was left with 'localhost' name but some other one, brought up explicitely, would cause a change? One could as well set a flag in /var/run/ and clear it in /etc/rc.d/rc.sysconfig. > I'm assuming a hostname set in /etc/sysconfig/network overrides anything that > ifup-post sets? Or does the ifup-post override /etc/sysconfig/network? Correct - unless this happens to be 'localhost.localdomain. Why to assume when it is easy to look and see how it works? The current behaviour of NetworkManager, with network handling defaults switched around in F9, is a _major_ PITA and a regression in an environment where addresses and names are assigned dynamically.
Yes, NM will support both sending a hostname to the DHCP server and honoring either a DHCP-returned or a manually set hostname in the near future. This will appear as an update for both F8 and F9.
> NM will support both sending a hostname to the DHCP server and honoring > either a DHCP-returned or a manually set hostname in the near future. I hope that will cover also a situation when you have a DHCP server but you do not control a name server and "local" names are given by /etc/hosts table. Think about a "home router/firewall" with a DHCP server, and where you can configure only a range of IPs to use, which is a quite common setup. 'network' service handles that without any issues while DHCP does not supply any names. A hook in NM which would allow to run something external on an interface status changes would go a long way.
So for now, NM won't touch hostnames directly, though we will probably provide a dispatcher script to do that based on the value of HOSTNAME from /etc/sysconfig/network or from the DHCP server options. Stuff still breaks when changing the hostname underneath X and other apps, unfortunately. Though if you're assigning essentially static IP address -> name mappings out of /etc/hosts for a small, nameserverless network, why not just set /etc/sysconfig/network HOSTNAME=xxxx to whatever you want it to be? Are you actually using dynamic addressing in this case?
> Though if you're assigning essentially static > IP address -> name mappings out of /etc/hosts > for a small, nameserverless network, why not > just set /etc/sysconfig/network HOSTNAME=xxxx > to whatever you want it to be? I am afraid that you miss the point. What I mentioned in comment #22 is just one possible scenario. What if you have a bigger network and no /etc/hosts mappings? How names are assigned is really irrelevant if you are not using NM. > Are you actually using dynamic addressing in this case? Yes, precisely. If you have only static addresses then there is no point to bother with NM at all. If X and other apps "unfortunately" break then this only shows again that NM gets into action too late (as it was pointed out on other occasions).
*** Bug 445741 has been marked as a duplicate of this bug. ***
Update: upstream NM SVN as of ~ r4082 honors automatically determined hostnames (via DHCP or whatever) if you do not have a hostname set in /etc/sysconfig/network.
Hopefuly r4082 will help here. So far after updating my "test" F9 installation, which has only wired connection on DHCP, to NetworkManager-0.7.0-0.11.svn4022.fc9 there are _no_ connections recognized by NM so the problem is in a sense moot. I have no idea how to "wake up" NM. I tried restarting, replugging a network cable, enabling networks in NM explicitely to no avail when service network is off. There are no issues with bringing net interfaces up with 'service network start'.
Michael: let's keep that discussion in bug 464417, thanks. Still trying to figure out why that's happening.
Comment #27 was added before I was aware of an existence of bug 464417. With recent bugzilla changes it is exceedingly hard, and takes very long, to find there anything at all.
*** Bug 462131 has been marked as a duplicate of this bug. ***
NetworkManager-0.7.0-0.12.svn4326.fc9,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9,NetworkManager-openvpn-0.7.0-16.svn4326.fc9,NetworkManager-pptp-0.7.0-0.12.svn4326.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.12.svn4326.fc9,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9,NetworkManager-openvpn-0.7.0-16.svn4326.fc9,NetworkManager-pptp-0.7.0-0.12.svn4326.fc9
NetworkManager-0.7.0-0.12.svn4326.fc8,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8,NetworkManager-openvpn-0.7.0-16.svn4326.fc8,NetworkManager-pptp-0.7.0-0.12.svn4326.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/NetworkManager-0.7.0-0.12.svn4326.fc8,NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8,NetworkManager-openvpn-0.7.0-16.svn4326.fc8,NetworkManager-pptp-0.7.0-0.12.svn4326.fc8
NetworkManager-0.7.0-0.12.svn4326.fc8, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8, NetworkManager-openvpn-0.7.0-16.svn4326.fc8, NetworkManager-pptp-0.7.0-0.12.svn4326.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update NetworkManager NetworkManager-vpnc NetworkManager-openvpn NetworkManager-pptp'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-10263
NetworkManager-0.7.0-0.12.svn4326.fc9, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9, NetworkManager-openvpn-0.7.0-16.svn4326.fc9, NetworkManager-pptp-0.7.0-0.12.svn4326.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update NetworkManager NetworkManager-vpnc NetworkManager-openvpn NetworkManager-pptp'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10321
This is a bug of /bin/ipcalc. "ipcalc --silent --hostname IPADDR/PREFIX" do not work on F10.
(In reply to comment #35) > This is a bug of /bin/ipcalc. "ipcalc --silent --hostname IPADDR/PREFIX" do not > work on F10. Sorry, I misunderstood. The ipcalc is working fine. My nsswitch configuration was wrong.
NetworkManager-0.7.0-0.12.svn4326.fc9, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc9, NetworkManager-openvpn-0.7.0-16.svn4326.fc9, NetworkManager-pptp-0.7.0-0.12.svn4326.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.7.0-0.12.svn4326.fc8, NetworkManager-vpnc-0.7.0-0.11.svn4326.fc8, NetworkManager-openvpn-0.7.0-16.svn4326.fc8, NetworkManager-pptp-0.7.0-0.12.svn4326.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Re: comment #37 "if problems still persist": I am running now with NetworkManager-0.7.0-0.12.svn4326.fc9 and, if I am using NetworkManager service instead of network then my hostname comes as "localhost.localdomain". That despite that "ipcalc --silent --hostname IPADDR/PREFIX", with an address of an interface as it was brought up by NetworkManager, prints an expected "real" name. Could be that the issue is that this interface happens to be eth1 and not eth0? eth0 is just not UP by a default (and "real" reasons). At least on an F9 installation that interface is activated _without_ anybody logged in; just with a gdm screen showing up. On two F10 installations, one x86_64 and another i386 on two diferent machines, with both using NetworkManager-0.7.0-0.12.svn4326.fc10, even that does not work. I have to have an active login before a network is up (and setting machine names does not work too). The difference is that an F9 installation was made "from scratch" and later all relevant updates applied. Both F10 installations are upgrades from F8. What I am missing?
The problem still exists with "NetworkManager-0.7.0-0.12.svn4326.fc9", the hostname is still "localhost.localdomain", when I use "/etc/init.d/network" the hostname is the hostname which the DHCP-Server sends but with NetworkManager it's "localhost.localdomain".
(In reply to comment #40) > The problem still exists with "NetworkManager-0.7.0-0.12.svn4326.fc9", the > hostname is still "localhost.localdomain", when I use "/etc/init.d/network" the > hostname is the hostname which the DHCP-Server sends but with NetworkManager > it's "localhost.localdomain". Have you set a hostname in /etc/syconfig/network? Can you attach the parts of /var/log/messages that show a connection attempt where the hostname is incorrectly set?
> Have you set a hostname in /etc/syconfig/network? You _totally_ miss the point. If you will set a hostname in /etc/syconfig/network then this name is *statically* attached to a given machine. I do that on a laptop but then, regardless where an how it is connected, it always "internally" shows the same name while it "external" names differ. OTOH if you are using 'network' service AND if you leave hostname in /etc/syconfig/network as 'localhost' or 'localhost.localdomain' AND this is the first time when that interface goes up then a hostname of machine will be derived from an assigned IP number with a help of /bin/ipcalc --silent --hostname ${IPADDR} That requires a working DNS, or /etc/hosts table which covers all possible addresses which can be asigned, and is important if you have a bunch of interfaces for which "preassigned" names are not given. This functionality is missing when using NM. To add an insult to injury currently anaconda writes during an installation such "dynamically derived name" into /etc/syconfig/network and creates a real mess if not explicitely prevented.
(In reply to comment #41) > Have you set a hostname in /etc/syconfig/network? > > Can you attach the parts of /var/log/messages that show a connection attempt > where the hostname is incorrectly set? No $HOSTNAME in /etc/sysconfig/network. I'm afraid I don't have F-9 box here anymore but F-10 yum-upgraded from F-9. and looks good on it at least. I'll try to build F-9 box up to get more information if necessary.
(In reply to comment #42) > > Have you set a hostname in /etc/syconfig/network? > > You _totally_ miss the point. If you will set a hostname in > /etc/syconfig/network then this name is *statically* attached to a given > machine. I do that on a laptop but then, regardless where an how it is > connected, it always "internally" shows the same name while it "external" names > differ. > > OTOH if you are using 'network' service AND if you leave hostname in > /etc/syconfig/network as 'localhost' or 'localhost.localdomain' AND this is the > first time when that interface goes up then a hostname of machine will be > derived from an assigned IP number with a help of > > /bin/ipcalc --silent --hostname ${IPADDR} Right, there's support for this inside NetworkManager if no other source of information (ie, /etc/sysconfig/network or DHCP) provides a hostname. Need to figure out why that's not working. > That requires a working DNS, or /etc/hosts table which covers all possible > addresses which can be asigned, and is important if you have a bunch of > interfaces for which "preassigned" names are not given. > > This functionality is missing when using NM. It's there, but apparently it's not being triggered. Can somebody post logs from /var/log/messages that show a connection attempt with NetworkManager where the hostname is not being autodetected based on reverse-DNS? You should see something like: NetworkManager: Setting system hostname to 'blahblah' (from address lookup)
> with NetworkManager where the hostname is not being autodetected based on > reverse-DNS? Does this has to be DNS? What I have now here has possible names in /etc/hosts and 'ipcalc --hostname ...' does not mind that at all. Setting up a local DNS would be a significant bother. What you see below is a "home router" with a caching DNS. > You should see something like: > NetworkManager: Setting system hostname to .... Nothing of that sort, I am afraid. I get: localhost NetworkManager: <info> Activation (eth0) Stage 4 of 5 Get) started... localhost NetworkManager: <info> address 192.168.xx.yyy localhost NetworkManager: <info> prefix 24 (255.255.255.0) localhost NetworkManager: <info> gateway 192.168.xx.zzz localhost NetworkManager: <info> nameserver '192.168.xx.zzz' localhost NetworkManager: <info> domain name 'some.domain' and off we go to Stage 5. I can post all NetworkManager messages bug maybe somebody else has already something like that with a true local DNS?
(In reply to comment #45) > > with NetworkManager where the hostname is not being autodetected based on > > reverse-DNS? > > Does this has to be DNS? What I have now here has possible names in /etc/hosts > and 'ipcalc --hostname ...' does not mind that at all. Setting up a local DNS > would be a significant bother. What you see below is a "home router" with a > caching DNS. No, it shouldn't have to be DNS, but NM does the *same* thing ipcalc does; in fact I looked at ipcalc to see exactly what it did and used that as the basis for the implementation in NM. NM calls getnameinfo() using your IP4 address; which should be exactly what ipcalc does using the address supplied on the command-line. getnameinfo() should be using the standard glibc resolution path; so if you have something in /etc/hosts and you have configured the lookups correctly to look in your files first (which is default) then this won't need to hit up your DNS server. > > You should see something like: > > > NetworkManager: Setting system hostname to .... > > Nothing of that sort, I am afraid. I get: > > localhost NetworkManager: <info> Activation (eth0) Stage 4 of 5 Get) > started... > localhost NetworkManager: <info> address 192.168.xx.yyy > localhost NetworkManager: <info> prefix 24 (255.255.255.0) > localhost NetworkManager: <info> gateway 192.168.xx.zzz > localhost NetworkManager: <info> nameserver '192.168.xx.zzz' > localhost NetworkManager: <info> domain name 'some.domain' > > and off we go to Stage 5. > > I can post all NetworkManager messages bug maybe somebody else has already > something like that with a true local DNS? Please post more; the lookups happen *after* Stage 5 and may take a few seconds to complete the query. The system hostname follows the hostname assigned by the default device, or the hostname found from reverse-lookup of the default device's IP address.
Created attachment 331785 [details] messages from NetworkManager > Please post more; Attached is a complete record of NetworkManager messages from a boot time to the moment gdm went up. The other interface which can be noticed in that at this moment has in its configuration: ONBOOT=no NM_CONTROLLED=no so it can be disregarded. When booting with a 'network' service active instead of NetworkManager, and NM_CONTROLLED in a corresponding configuration switched from "yes" to "no", then a hostname is derived from an assigned IP as expected.
(In reply to comment #47) > Created an attachment (id=331785) [details] > messages from NetworkManager > > > Please post more; > > Attached is a complete record of NetworkManager messages from a boot time to > the moment gdm went up. The other interface which can be noticed in that at > this moment has in its configuration: > > ONBOOT=no > NM_CONTROLLED=no > > so it can be disregarded. > > When booting with a 'network' service active instead of NetworkManager, and > NM_CONTROLLED in a corresponding configuration switched from "yes" to "no", > then a hostname is derived from an assigned IP as expected. Ok, that doesn't show the hostname lookup succeeding. So either NM isn't starting it, or there's an error during the lookup. To check the first one, what's the output of the following command *after* letting the connection succeed like at the end of the log you've posted? dbus-send --system --print-reply --dest=org.freedesktop.NetworkManagerSystemSettings /org/freedesktop/NetworkManagerSettings org.freedesktop.DBus.Properties.Get string:org.freedesktop.NetworkManagerSettings.System string:Hostname This will tell us what the system settings service reports any configured static hostname to be, which may cause NetworkManager not to attempt the reverse lookup.
> dbus-send --system ... That command prints for me: method return sender=:1.2 -> dest=:1.23 reply_serial=2 variant string "localhost.localdomain" Just to be sure; on that system I am running these experiments this is currently with NetworkManager-0.7.0-1.git20090102.fc10.x86_64 and dbus-1.2.4-2.fc10.x86_64.
Ok, great. That means the system settings service is picking up the hostname from *somewhere*. We need to figure out where. Can you paste in the contents of /etc/NetworkManager/nm-system-settings.conf ? Next, can you stop NetworkManager, and run: /usr/sbin/nm-system-settings --debug --plugins=ifcfg-rh wait about 20 seconds, run the same "dbus-send" command from a couple comments ago, kill nm-system-settings with Ctrl+C, and paste it's output and the new dbus-send output into this bug?
Contents of /etc/NetworkManager/nm-system-settings.conf: [main] plugins=ifcfg-fedora > Next, can you stop NetworkManager, and run: > /usr/sbin/nm-system-settings --debug --plugins=ifcfg-rh Does not work this way because even with NetworkManager stopped nm-system-settings is still running and that results in: "Could not acquire the NetworkManagerSystemSettings service as it is already taken. Return: 3". After killing nm-system-settings process '/usr/sbin/nm-system-settings --debug --plugins=ifcfg-rh' prints: ** Message: Loaded plugin ifcfg-rh: (c) 2007 - 2008 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. ** Message: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth1 ... ** Message: ifcfg-rh: read connection 'System eth1' ** Message: ifcfg-rh: Ignoring connection 'System eth1' and its device because NM_CONTROLLED was false. ** Message: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... ** Message: ifcfg-rh: read connection 'System eth0' ** Message: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... ** Message: ifcfg-rh: error: Ignoring loopback device config. > wait about 20 seconds, run the same "dbus-send" command That is persistent with printing messages like that: method return sender=:1.48 -> dest=:1.49 reply_serial=2 variant string "localhost.localdomain" does not matter how long I am waiting or running. /etc/sysconfig/network-scripts/ifcfg-eth0 says: # Intel Corporation 82557/8/9 [Ethernet Pro 100] DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:02:B3:A3:60:E4 ONBOOT=yes TYPE=Ethernet NM_CONTROLLED=yes
Michal: just to confirm, you *do* have a hostname defined in /etc/sysconfig/network, but you'd like the machine's hostname to be dynamically assigned via reverse lookup when the hostname is either "localhost" or "localhost.localdomain"? The only way I can see (and I tested with F-10's 0.7.0-1.git20090102.fc10) that the system settings service would report "localhost.localdomain" was if it was configured that way in /etc/sysconfig/network.
> just to confirm, you *do* have a hostname defined in /etc/sysconfig/network, Some hostname _has_ to be given there but in this case this is 'HOSTNAME=localhost.localdomain'. If I would put there something else then this will be always asigned regardless of what particular IP showed up with a dynamic configuration. That how it works on a laptop of my wife, for example. > but you'd like the machine's hostname to be dynamically assigned via reverse > lookup when the hostname is either "localhost" or "localhost.localdomain"? That is how it works with a service 'network'.
How come the hostname _has_ to be there? My read of the network scripts indicate that if you don't include HOSTNAME stuff will still work OK. The need_hostname() function will check for "localhost", "localhost.localdomain", and "" as hostnames that will trigger reverse-lookup.
> How come the hostname _has_ to be there? - Because in /etc/rc.d/rc.sysinit you have the following code: if [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" ]; then HOSTNAME=localhost fi .... action $"Setting hostname ${HOSTNAME}: " hostname ${HOSTNAME} so even if you will attempt to avoid it you will end up with 'localhost'. - Because in various places of a system, like X but far from only, it is expected that hostname will found even if it is 'localhost' and resolves to a loopback adress. A warning comment which opens /etc/hosts was put there not without reasons. - Because anaconda assigned it during an installation. > The need_hostname() function will check for "localhost", > "localhost.localdomain", and "" as hostnames that will trigger reverse-lookup Yes. That precisely happens if you are using 'network' service but not with NM.
(In reply to comment #55) > > How come the hostname _has_ to be there? > > - Because in /etc/rc.d/rc.sysinit you have the following code: > > if [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" ]; then > HOSTNAME=localhost > fi > .... > action $"Setting hostname ${HOSTNAME}: " hostname ${HOSTNAME} > > so even if you will attempt to avoid it you will end up with 'localhost'. rc.sysinit gets run once on bootup. It's not sourced by any other scripts. HOSTNAME in /etc/sysconfig/network has no impact on rc.sysinit. I don't believe you need HOSTNAME in /etc/sysconfig/network at all for your case. You don't want to force the hostname to be something specific, so you don't need HOSTNAME at all. Both NM and 'network' should handle it in exactly the same way if you remove HOSTNAME from /etc/sysconfig/network AFAICT. > - Because in various places of a system, like X but far from only, it is > expected that hostname will found even if it is 'localhost' and resolves to a > loopback adress. A warning comment which opens /etc/hosts was put there not > without reasons. That should still be the case no matter what, 'localhost' will always be in /etc/hosts. That's not affected by this issue AFAICT. > - Because anaconda assigned it during an installation. Arguably anaconda should probably not write out HOSTNAME if it's localhost. > > The need_hostname() function will check for "localhost", > > "localhost.localdomain", and "" as hostnames that will trigger reverse-lookup > > Yes. That precisely happens if you are using 'network' service but not with > NM. Wrong; if the user has not locked a hostname using /etc/sysconfig/network, then NM *will* do the same thing as the 'network' service. Some people may well *want* their hostname to always be localhost. The network service doesn't allow this. Please let me know if removing HOSTNAME from /etc/sysconfig/network has any adverse effects on your installations.
> Wrong; if the user has not locked a hostname ... Ah, so you are saying that this bug should be now rewritten as "if in /etc/sysconfig/network HOSTNAME is set to 'localhost.localdomain' then NetworkManager is unable to assign a hostname from an address lookup"? Indeed, if I wll remove HOSTNAME entirely from /etc/sysconfig/network then NM does perform than operation. There are only some side-effects. Namely I see then in my logs many, many times: WARNING: Unable to connect to display after 10 tries - bailing out followed by mulitple blocks like these: gdm-binary[2764]: WARNING: GdmDisplay: display lasted 0.017707 seconds gdm-binary[2764]: WARNING: GdmDisplay: display lasted 0.017547 seconds gdm-binary[2764]: WARNING: GdmDisplay: display lasted 0.017545 seconds gdm-binary[2764]: WARNING: GdmDisplay: display lasted 0.017549 seconds gdm-binary[2764]: WARNING: GdmDisplay: display lasted 0.017569 seconds gdm-binary[2764]: WARNING: GdmDisplay: display lasted 0.017772 seconds gdm-binary[2764]: WARNING: GdmLocalDisplayFactory: maximum number of X display f ailures reached: check X server log for errors init: prefdm main process (2764) terminated with status 1 init: prefdm main process ended, respawning gdm-binary[2802]: WARNING: GdmDisplay: display lasted 0.017742 seconds gdm-binary[2802]: WARNING: GdmDisplay: display lasted 0.017553 seconds gdm-binary[2802]: WARNING: GdmDisplay: display lasted 0.017559 seconds gdm-binary[2802]: WARNING: GdmDisplay: display lasted 0.017600 seconds gdm-binary[2802]: WARNING: GdmDisplay: display lasted 0.017587 seconds gdm-binary[2802]: WARNING: GdmDisplay: display lasted 0.017605 seconds gdm-binary[2802]: WARNING: GdmLocalDisplayFactory: maximum number of X display f ailures reached: check X server log for errors init: prefdm main process (2802) terminated with status 1 init: prefdm main process ended, respawning and that eventually terminated with init: prefdm respawning too fast, stopped A process table shows five X servers running, no gdm and I have a blank display. That cure looks considerable worse than a disease. "check X server log for errors" advice is somewhat futile as I do not see any reported. Restoring /etc/sysconfig/network to its previous content makes a graphic display to start again (and I did try to boot more than once with no HOSTNAME line in /etc/sysconfig/network with the same effects every time). Does anybody else on a cc list for this bug got that working?
Ok; that's good information. Any idea what the system hostname is at this time without NM running? ie, remove HOSTNAME from /etc/sysconfig/network, 'chkconfig NetworkManager off', and restart. When that stuff fails, can you grab the output of "hostname" for me? If rc.sysinit *does* indeed set the hostname of the machine to 'localhost' in the absence of another name, then I'd expect all this to work just fine. There's an open bug with GDM where GDM doesn't handle hostname changes correctly, since it uses the machine hostname when it starts for some purposes. Of course, right after it's grabbed the hostname, NetworkManager has probably connected your interface and changed the hostname to something else using reverse-lookup on the IP address, leading to GDM dieing.
> remove HOSTNAME from /etc/sysconfig/network, 'chkconfig NetworkManager off', > and restart These tests on F10 installation with 'HOSTNAME=...' line of any sort in /etc/sysconfig/network missing: - services NM and network off make hostname to 'localhost'; as expected and that boots to level 5 with gdm running but clearly no connections - NM on, network off and booting to level 3; then hostname is set from an address lookup - NM off, network on and configuration adjusted accordingly; hostname is set from an address lookup and gdm starts on level 5 without any problems - NM on, network off and level 5 then see comment #57 With 'HOSTNAME=localhost' in /etc/sysconfig/network and NetworkManager on a hostame is set to 'localhost' and that what is displayed by gdm. As seen from the above gdm is not spooked by an "incomplete" /etc/sysconfig/network because it does not mind that with a service network. I do not know where is really the issue. OTOH for various reasons, including an installed base, it would be really good if NM would be able to ignore "HOSTNAME=localhost.localdomain" or "HOSTNAME=localhost" lines like a service network does. Nothing beyond a startup should really care about a content of /etc/sysconfig/network but making sure that this the case can become "interesting".
NetworkManager-0.7.0.97-5.git20090220.fc10, NetworkManager-openconnect-0.7.0.97-1.fc10, NetworkManager-pptp-0.7.0.97-1.fc10, NetworkManager-openvpn-0.7.0.97-1.fc10, NetworkManager-vpnc-0.7.0.97-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update NetworkManager NetworkManager-openconnect NetworkManager-pptp NetworkManager-openvpn NetworkManager-vpnc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1985
I tried NetworkManager-0.7.0.97-5.git20090220.fc10. With this version I see in my logs "Setting system hostname ... (from address lookup)" even if /etc/sysconfig/network includes "HOSTNAME=localhost.localdomain". Only it appears that this happens too late and I am ending with six X servers running, on displays from 0 to 5, none showing any picture. Corresponding logs in /var/log/gdm/ look like this: Fatal server error: Server is already active for display 0 If this server is no longer running, remove /tmp/.X0-lock and start again. (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor No way to fix that from a console and even with a remote login it is not that obvious but 'telinit 3; telinit 5' does work. Another way to boot is to boot to level 3, get shell and do 'telinit 5'. That will start gdm without any issues. After booting to level 3 a login prompt displays "localhost" even if hostame was set properly. Only after 'pkill -f getty' console prompts will "notice" a new name. Also all log entries are prefixed with "localhost" until 'service rsyslog restart' is done. None of these is an issue if service network instead of NetworkManager is used to set a name from a lookup. It appears that in order for this to really work with NM some kind of a "forced restart" would be required after a new hostname showed up (unless it is possible do do such change "early enough").
"With this version I see in my logs "Setting system hostname ... (from address lookup)" even if /etc/sysconfig/network includes "HOSTNAME=localhost.localdomain"." ^^^ that's the behavior you were requesting (to match the 'network' service behavior), right? So now you're running into the start of problems with dynamic hostnames :) Technically this is a GDM bug, where GDM doesn't properly handle hostname changes that occur while it's starting up. For now, you can either lock the hostname, or we can fix GDM.
> Technically this is a GDM bug ... Technically you are correct although these other issues I mentioned indicate that setting a host name is expected earlier than NM is doing in situations discussed here. If "expected" is the right term I do not know. I have no idea if this was ever spelled out. > For now, you can either lock the hostname, or we can fix GDM. Or I can use service network which handles that without any troubles; including expected log tags and getty prompts.
(In reply to comment #63) > > Technically this is a GDM bug ... > > Technically you are correct although these other issues I mentioned indicate > that setting a host name is expected earlier than NM is doing in situations > discussed here. If "expected" is the right term I do not know. I have no idea > if this was ever spelled out. > > > For now, you can either lock the hostname, or we can fix GDM. > > Or I can use service network which handles that without any troubles; including > expected log tags and getty prompts. That's because 'network' blocks everything until its done all the setup. NetworkManager doesn't do that, and thus exposes bugs in applications that don't handle dynamic network conditions. gdm handles hostname changes just fine *after* it's started, but not while its starting.
Actually because of the way NM works now I can't use the NM and have to fall back to /etc/init.d/network. I have medium to large installations of Fedora systems and for this DHCP which sets the hostname is very important and so the first action after an installation of Fedora is to disable NM, actually I really would love it to use NM but practically I can't, so it would really really helpful if you could find a way to get NM to work with the conditions we have right now.
(In reply to comment #65) > Actually because of the way NM works now I can't use the NM and have to fall > back to /etc/init.d/network. I have medium to large installations of Fedora > systems and for this DHCP which sets the hostname is very important and so the > first action after an installation of Fedora is to disable NM, actually I > really would love it to use NM but practically I can't, so it would really > really helpful if you could find a way to get NM to work with the conditions we > have right now. What are those specific issues that require you to turn off NetworkManager?
NetworkManager-0.7.0.98-1.git20090225.fc10, NetworkManager-openconnect-0.7.0.97-1.fc10, NetworkManager-pptp-0.7.0.97-1.fc10, NetworkManager-openvpn-0.7.0.97-1.fc10, NetworkManager-vpnc-0.7.0.97-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update NetworkManager NetworkManager-openconnect NetworkManager-pptp NetworkManager-openvpn NetworkManager-vpnc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1985
The GDM problem in comment #57 and comment #62 has the potential to cause a significant problem for users who upgrade NetworkManager. My Fedora 10 installation uses NetworkManager and GDM (the defaults), hostname set to localhost.localdomain in /etc/sysconfig/network (which I believe is the default if not overridden in Anaconda) and uses DHCP (the norm). What I expect is a typical laptop or home desktop setup. My network provides me a DHCP IP which reverse resolves in DNS (something that may not be typical). All was stable until the updates-testing upgrade to NetworkManager-0.7.0.98-1.git20090225.fc10.i386. The next reboot, GDM login prompt is presented as normal but the screen blanks and doesn't recover after user login. No error message, no obvious way for joe user to fix it. Obviously I can work around or fix it a number of ways but I would be concerned about the potential impact across the user base because of the "silent" and fatal nature of the problem partway through a stable release.
Yeah, I'm going to disable the "localhost.localdomain" stuff in F9 and F10 until we figure out the fix for GDM. Rawhide will still update the hostname though.
NetworkManager-0.7.0.99-1.fc10,knetworkmanager-0.7-0.8.20080926svn.fc10,NetworkManager-vpnc-0.7.0.99-1.fc10,NetworkManager-openvpn-0.7.0.99-1.fc10,NetworkManager-pptp-0.7.0.99-1.fc10,NetworkManager-openconnect-0.7.0.99-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-1.fc10,knetworkmanager-0.7-0.8.20080926svn.fc10,NetworkManager-vpnc-0.7.0.99-1.fc10,NetworkManager-openvpn-0.7.0.99-1.fc10,NetworkManager-pptp-0.7.0.99-1.fc10,NetworkManager-openconnect-0.7.0.99-1.fc10
NetworkManager-0.7.0.99-1.fc9,NetworkManager-vpnc-0.7.0.99-1.fc9,NetworkManager-openvpn-0.7.0.99-1.fc9,NetworkManager-pptp-0.7.0.99-1.fc9,NetworkManager-openconnect-0.7.0.99-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/NetworkManager-0.7.0.99-1.fc9,NetworkManager-vpnc-0.7.0.99-1.fc9,NetworkManager-openvpn-0.7.0.99-1.fc9,NetworkManager-pptp-0.7.0.99-1.fc9,NetworkManager-openconnect-0.7.0.99-1.fc9
NetworkManager-0.7.0.99-1.fc9, NetworkManager-vpnc-0.7.0.99-1.fc9, NetworkManager-openvpn-0.7.0.99-1.fc9, NetworkManager-pptp-0.7.0.99-1.fc9, NetworkManager-openconnect-0.7.0.99-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.7.0.99-1.fc10, knetworkmanager-0.7-0.8.20080926svn.fc10, NetworkManager-vpnc-0.7.0.99-1.fc10, NetworkManager-openvpn-0.7.0.99-1.fc10, NetworkManager-pptp-0.7.0.99-1.fc10, NetworkManager-openconnect-0.7.0.99-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 476929 has been marked as a duplicate of this bug. ***
What is the status of this bug ? It's now over three years, and NM is still not setting the DHCP hostname, although syslog indicates it is taking notice of it: Oct 25 09:46:06 localhost NetworkManager[2435]: <info> (wlan0): DHCPv4 state changed preinit -> reboot Oct 25 09:46:06 localhost NetworkManager[2435]: <info> address 192.168.3.101 Oct 25 09:46:06 localhost NetworkManager[2435]: <info> prefix 24 (255.255.255.0) Oct 25 09:46:06 localhost NetworkManager[2435]: <info> gateway 192.168.3.100 Oct 25 09:46:06 localhost NetworkManager[2435]: <info> hostname 'ftglap' Oct 25 09:46:06 localhost NetworkManager[2435]: <info> nameserver '192.168.3.100' Oct 25 09:46:06 localhost NetworkManager[2435]: <info> domain name 'griffin.treehouse.com' Oct 25 09:46:06 localhost NetworkManager[2435]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled... Oct 25 09:46:06 localhost NetworkManager[2435]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) started... If you don't want to enable this unconditionally, can we at least have an option for it ?
Any updates on this bug? I just tried CentOS 7 and NetworkManager is ignoring my DHCP provided hostname in an enterprise environment. I'm having difficulty configuring a VM template and image in order to clone multiple instances from this image in an elastic environment. For those running CentOS 7 I've found that removing the /etc/hostname file will cause the hostname to be set from the DHCP response. Is this the recommended way to configure a DHCP provided hostname for use a an image or VM template?
Hard to believe this bug has been open as long as it has. What's the problem with NM setting the hostname to the one it gets back from DHCP if one isn't explicit configured?
well back in 2009 the problem was: "Technically this is a GDM bug, where GDM doesn't properly handle hostname changes that occur while it's starting up. For now, you can either lock the hostname, or we can fix GDM." from c#62. I've no idea if that is still true, and if people now wondering about DHCP hostnames are actually in the same situation as obtained five years ago or if this is something entirely new. but what the hell, let's re-open it and see what dcbw thinks. dcbw, is NM still not setting DHCP hostnames because of the GDM bug from 2009? or what? new report? thanks!
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.