Bug 441453 - hostname is always localhost
hostname is always localhost
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
20
All Linux
high Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
: 445741 462131 476929 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-08 03:35 EDT by Akira TAGOH
Modified: 2017-10-06 14:20 EDT (History)
18 users (show)

See Also:
Fixed In Version: 0.7.0.99-1.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 20:32:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mleitner: needinfo-


Attachments (Terms of Use)
messages from NetworkManager (5.33 KB, text/plain)
2009-02-12 19:59 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Akira TAGOH 2008-04-08 03:35:46 EDT
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
Comment 1 Bill Nottingham 2008-04-08 11:34:41 EDT
The 'setting hostname' is done well before any networking. What's the hostname
after you get a DHCP address?
Comment 2 Akira TAGOH 2008-04-08 20:46:10 EDT
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?
Comment 3 Akira TAGOH 2008-04-08 20:48:48 EDT
well, to clarify again, hostname is localhost on rawhide box, after getting IP
address via DHCP.
Comment 4 Dan Williams 2008-04-10 12:12:37 EDT
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 ?
Comment 5 Akira TAGOH 2008-04-10 21:10:42 EDT
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.
Comment 6 Doug Chapman 2008-04-28 16:24:14 EDT
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

Comment 7 Gene Czarcinski 2008-04-29 11:22:29 EDT
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.
Comment 8 Doug Chapman 2008-04-30 11:35:39 EDT
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).
Comment 9 Doug Chapman 2008-04-30 11:49:02 EDT
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.

Comment 10 Doug Chapman 2008-04-30 17:50:14 EDT
(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@redhat.com> - 8.65-1
- disable network by default, in favor of NetworkManager

Comment 11 Dan Williams 2008-05-01 06:33:36 EDT
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?
Comment 12 Doug Chapman 2008-05-01 10:24:00 EDT
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).

Comment 13 Doug Chapman 2008-05-01 10:31:01 EDT
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.

Comment 14 Dan Williams 2008-05-01 10:40:36 EDT
Yeah, we do need to make NM do what you've listed in comment 13.
Comment 15 jonathan baron 2008-05-01 21:40:06 EDT
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.)

Comment 16 jonathan baron 2008-05-02 10:55:11 EDT
(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.)

Comment 17 Dan Williams 2008-05-02 11:50:33 EDT
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.
Comment 18 Bug Zapper 2008-05-14 05:07:46 EDT
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
Comment 19 JM 2008-06-06 17:21:19 EDT
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?
Comment 20 Michal Jaegermann 2008-06-08 20:38:50 EDT
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.
Comment 21 Dan Williams 2008-06-09 13:21:35 EDT
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.
Comment 22 Michal Jaegermann 2008-06-09 13:53:14 EDT
> 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.
Comment 23 Dan Williams 2008-08-15 15:55:07 EDT
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?
Comment 24 Michal Jaegermann 2008-08-15 18:14:17 EDT
> 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).
Comment 25 Dan Williams 2008-09-08 09:28:00 EDT
*** Bug 445741 has been marked as a duplicate of this bug. ***
Comment 26 Dan Williams 2008-09-22 20:21:49 EDT
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.
Comment 27 Michal Jaegermann 2008-09-29 14:41:32 EDT
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'.
Comment 28 Dan Williams 2008-10-01 09:49:17 EDT
Michael: let's keep that discussion in bug 464417, thanks.  Still trying to figure out why that's happening.
Comment 29 Michal Jaegermann 2008-10-01 12:19:33 EDT
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.
Comment 30 Dan Williams 2008-10-19 23:00:12 EDT
*** Bug 462131 has been marked as a duplicate of this bug. ***
Comment 31 Fedora Update System 2008-11-23 18:05:00 EST
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
Comment 32 Fedora Update System 2008-11-23 18:07:29 EST
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
Comment 33 Fedora Update System 2008-11-26 01:14:59 EST
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
Comment 34 Fedora Update System 2008-11-26 01:19:02 EST
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
Comment 35 Kazutoshi Morioka 2008-11-26 05:30:42 EST
This is a bug of /bin/ipcalc. "ipcalc --silent --hostname IPADDR/PREFIX" do not work on F10.
Comment 36 Kazutoshi Morioka 2008-11-26 08:11:45 EST
(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.
Comment 37 Fedora Update System 2008-12-21 18:37:32 EST
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.
Comment 38 Fedora Update System 2008-12-21 18:42:41 EST
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.
Comment 39 Michal Jaegermann 2008-12-25 14:41:47 EST
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?
Comment 40 JM 2009-01-12 08:02:17 EST
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".
Comment 41 Dan Williams 2009-02-04 19:17:39 EST
(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?
Comment 42 Michal Jaegermann 2009-02-04 20:43:32 EST
> 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.
Comment 43 Akira TAGOH 2009-02-04 20:49:42 EST
(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.
Comment 44 Dan Williams 2009-02-12 15:49:14 EST
(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)
Comment 45 Michal Jaegermann 2009-02-12 16:39:28 EST
> 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?
Comment 46 Dan Williams 2009-02-12 17:36:21 EST
(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.
Comment 47 Michal Jaegermann 2009-02-12 19:59:46 EST
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.
Comment 48 Dan Williams 2009-02-13 10:12:00 EST
(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.
Comment 49 Michal Jaegermann 2009-02-13 12:04:33 EST
> 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.
Comment 50 Dan Williams 2009-02-13 12:22:53 EST
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?
Comment 51 Michal Jaegermann 2009-02-13 12:52:58 EST
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
Comment 52 Dan Williams 2009-02-13 14:21:19 EST
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.
Comment 53 Michal Jaegermann 2009-02-13 14:31:47 EST
> 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'.
Comment 54 Dan Williams 2009-02-17 07:19:17 EST
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.
Comment 55 Michal Jaegermann 2009-02-17 11:45:20 EST
> 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.
Comment 56 Dan Williams 2009-02-17 11:56:39 EST
(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.
Comment 57 Michal Jaegermann 2009-02-17 12:42:15 EST
> 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?
Comment 58 Dan Williams 2009-02-17 14:09:56 EST
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.
Comment 59 Michal Jaegermann 2009-02-17 16:13:56 EST
> 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".
Comment 60 Fedora Update System 2009-02-24 15:50:07 EST
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
Comment 61 Michal Jaegermann 2009-02-26 02:31:24 EST
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").
Comment 62 Dan Williams 2009-02-26 11:19:46 EST
"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.
Comment 63 Michal Jaegermann 2009-02-26 11:42:02 EST
> 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.
Comment 64 Dan Williams 2009-02-26 12:21:18 EST
(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.
Comment 65 JM 2009-02-27 08:04:31 EST
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.
Comment 66 Dan Williams 2009-02-27 18:14:54 EST
(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?
Comment 67 Fedora Update System 2009-02-27 22:24:38 EST
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
Comment 68 Paul Jenner 2009-03-02 14:12:03 EST
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.
Comment 69 Dan Williams 2009-03-02 14:36:33 EST
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.
Comment 70 Fedora Update System 2009-03-06 12:35:03 EST
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
Comment 71 Fedora Update System 2009-03-06 12:51:53 EST
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
Comment 72 Fedora Update System 2009-03-08 15:30:22 EDT
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.
Comment 73 Fedora Update System 2009-03-08 15:31:52 EDT
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.
Comment 74 Dan Williams 2009-04-17 17:32:19 EDT
*** Bug 476929 has been marked as a duplicate of this bug. ***
Comment 75 Frank Griffin 2012-10-25 14:51:41 EDT
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 ?
Comment 76 Jeff McCune 2014-07-08 13:05:35 EDT
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?
Comment 77 Philip Prindeville 2014-09-10 20:24:56 EDT
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?
Comment 78 Adam Williamson 2014-09-10 21:24:23 EDT
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!
Comment 79 Fedora End Of Life 2015-05-29 04:34:53 EDT
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.
Comment 80 Fedora End Of Life 2015-06-29 20:32:20 EDT
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.

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