Bug 875085 - NetworkManager-0.9.6.4-1 doesn't set anymore hostname to value returned from dhcp
NetworkManager-0.9.6.4-1 doesn't set anymore hostname to value returned from ...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
17
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-09 08:47 EST by derrien
Modified: 2013-01-23 11:10 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-21 22:58:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
[PATCH] update hostname in ACTIVATED handler (1.24 KB, patch)
2012-11-14 09:11 EST, Jirka Klimes
no flags Details | Diff
[PATCH] v2: update hostname in ACTIVATED handler (1.13 KB, patch)
2012-11-15 04:17 EST, Jirka Klimes
no flags Details | Diff
[PATCH] v3: update hostname in ACTIVATED handler (1.78 KB, patch)
2012-11-15 04:41 EST, Jirka Klimes
no flags Details | Diff
my /var/log/messages (112.77 KB, text/plain)
2012-11-21 10:30 EST, Guy Streeter
no flags Details

  None (edit)
Description derrien 2012-11-09 08:47:06 EST
Description of problem:

With NetworkManager-0.9.4.0-7.git20120403.fc17.x86_64 :

Nov  8 17:09:02 localhost NetworkManager[644]: <info> (p3p1): device state change: ip-config -> activated (reason 'none') [70 100 0]
Nov  8 17:09:02 localhost NetworkManager[644]: <info> Policy set 'Boot Disk' (p3p1) as default for IPv4 routing and DNS.
Nov  8 17:09:02 localhost NetworkManager[644]: <info> Setting system hostname to 'sedna' (from DHCPv4)
Nov  8 17:09:02 localhost NetworkManager[644]: <info> Activation (p3p1) successful, device activated.
Nov  8 17:09:02 localhost NetworkManager[644]: <info> Activation (p3p1) Stage 5 of 5 (IPv4 Commit) complete.

so hostname is sedna

After update with NetworkManager-0.9.6.4-1.fc17.x86_64 :

Nov  9 10:41:31 localhost NetworkManager[645]: <info> (p3p1): device state change: ip-config -> activated (reason 'none') [70 100 0]
Nov  9 10:41:31 localhost NetworkManager[645]: <info> Policy set 'Boot Disk' (p3p1) as default for IPv4 routing and DNS.
Nov  9 10:41:31 localhost NetworkManager[645]: <info> Activation (p3p1) successful, device activated.
Nov  9 10:41:31 localhost NetworkManager[645]: <info> Activation (p3p1) Stage 5 of 5 (IPv4 Commit) complete.

and then hostname is localhost

Version-Release number of selected component (if applicable): 0.9.6.4-1.fc17.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Dan Winship 2012-11-09 10:11:21 EST
NM was always only ever supposed to set the hostname if you didn't already have a hostname set. However, at some point Fedora switched from storing the hostname in /etc/sysconfig/network to storing it in /etc/hostname instead, and NM hadn't been updated for this. Now it has been, and so the expected behavior is that if there is a hostname in /etc/hostname, then NM will not change it. Does that match what you're seeing? If so, this is NOTABUG.
Comment 2 derrien 2012-11-09 10:50:49 EST
[root@localhost (Fedora 17) ~]$ ls -l /etc/hostname
ls: cannot access /etc/hostname: No such file or directory

and HOSTNAME seems still to be in /etc/sysconfig/network
Comment 3 Martin F 2012-11-11 22:48:55 EST
I have the same problem and have additional info.

I've two PCs with Fedora 17 x86_64, one with NetworkManager 0.9.4.0-9.git20120521 (haven't updated) and one with NetworkManager 0.9.6.4-1.

The newer one always fails to set the hostname retrieved by dhclient and reverts to localhost without domain name.

I had enabled NetworkManager-wait-online.service, and there is no HOSTNAME entry in /etc/sysconfig/network, and no /etc/hostname file. The /etc/hosts only contains localhost related aliases, since all hostnames are resolved through DNS, which seems to work fine on both machines.

The only problem is hostname is localhost with the newer NetworkManager. Of course this causes problems with autofs, sssd, openldap, etc. The old one works perfectly in all fronts.
Comment 4 Jirka Klimes 2012-11-14 09:09:15 EST
It looks like hostname change slipped out from ACTIVATED policy change handler
in this commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=500315329765831d242d51d6a46f1e05869c15d2
Comment 5 Jirka Klimes 2012-11-14 09:11:41 EST
Created attachment 644903 [details]
[PATCH] update hostname in ACTIVATED handler
Comment 6 Dan Winship 2012-11-14 11:13:00 EST
Hm... why doesn't that code just use update_routing_and_dns() like everything else?
Comment 7 Dan Williams 2012-11-14 12:49:38 EST
(In reply to comment #5)
> Created attachment 644903 [details]
> [PATCH] update hostname in ACTIVATED handler

Diagnosis looks good but I think the update_system_hostname() call should be inside the nm_dns_manager_begin_updates()/nm_dns_manager_end_updates() block just above the routing update calls to ensure we batch up DNS changes.  The hostname can affect the DNS configuration.
Comment 8 Jirka Klimes 2012-11-15 04:17:41 EST
Created attachment 645519 [details]
[PATCH] v2: update hostname in ACTIVATED handler
Comment 9 Jirka Klimes 2012-11-15 04:41:41 EST
Created attachment 645529 [details]
[PATCH] v3: update hostname in ACTIVATED handler

(In reply to comment #6)
> Hm... why doesn't that code just use update_routing_and_dns() like
> everything else?
I think the reason is that the code here adds new IP configs.

But, I wonder if this patch could work.
The difference against current code is that it calls update_ip4_dns()/update_ip6_dns() (via update_routing_and_dns()) even if no IP configs were added. Could that be a problem?
Comment 10 Guy Streeter 2012-11-16 16:56:50 EST
This is a serious difficulty for me since I have things running on my system that depend on knowing the hostname. Are these messages significant? They started showing up around the same time as the NetworkManager update and the hostname reverting to localhost.

Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.own: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.60': no such name
Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.settings.modify.hostname: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.60': no such name
Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-network: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.68': no such name
Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.sleep-wake: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.68': no such name
Nov 12 17:09:16 localhost NetworkManager[641]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wifi: (3) GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.68': no such name
Comment 11 Fabrice Robin 2012-11-19 05:31:59 EST
Same problem here, even with version 0.9.6.4-2 which is in updates-testing repository.

With new machines, sssd (with ldap config and SRV record use) cannot work because it cannot find the network domain name.

Only "hostname -F" shows the "good" fqdn provided by the dhcp server.
Other hostname options print only "localhost".

This is a high problem in my company because the only workaround is to put a hostname manually in /etc/sysconfig/network
Comment 12 Fedora Update System 2012-11-20 04:00:47 EST
NetworkManager-0.9.6.4-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.6.4-3.fc17
Comment 13 derrien 2012-11-20 04:44:40 EST
Works for me
Comment 14 Fedora Update System 2012-11-20 04:53:21 EST
NetworkManager-0.9.6.4-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.6.4-2.fc16
Comment 15 Jirka Klimes 2012-11-20 07:25:47 EST
(In reply to comment #13)
> Works for me
Great!  Would you click the link and add a karma then? :)
Comment 16 Jirka Klimes 2012-11-20 07:31:41 EST
(In reply to comment #10)
> This is a serious difficulty for me since I have things running on my system
> that depend on knowing the hostname. Are these messages significant? They
> started showing up around the same time as the NetworkManager update and the
> hostname reverting to localhost.
> 

Guy, please try the update.

As for the warning messages, they are unrelated. Probably, a short-lived process
called a NM D-Bus call, but exited before NM had a chance to get its identity.
Comment 17 Guy Streeter 2012-11-20 11:09:35 EST
This did not fix the problem for me. I installed the new version and rebooted.

[streeter@localhost ~]$ hostname
localhost

[streeter@localhost ~]$ rpm -qa NetworkManager\*
NetworkManager-gtk-1:0.9.6.4-3.fc17.x86_64
NetworkManager-gnome-1:0.9.6.4-3.fc17.x86_64
NetworkManager-openconnect-0.9.4.0-7.git20120612.fc17.x86_64
NetworkManager-1:0.9.6.4-3.fc17.x86_64
NetworkManager-glib-1:0.9.6.4-3.fc17.x86_64

[streeter@localhost ~]$ cat /etc/hostname
cat: /etc/hostname: No such file or directory

[streeter@localhost ~]$ cat /etc/sysconfig/network
NETWORKING=yes
##HOSTNAME=localhost.localdomain
NTPSERVERARGS=iburst

[streeter@localhost ~]$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:23:ae:ab:af:ce brd ff:ff:ff:ff:ff:ff
    inet 10.15.1.193/24 brd 10.15.1.255 scope global em1
    inet6 fe80::223:aeff:feab:afce/64 scope link 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 52:54:00:09:1c:cb brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master virbr0 state DOWN qlen 500
    link/ether 52:54:00:09:1c:cb brd ff:ff:ff:ff:ff:ff

[streeter@localhost ~]$ host 10.15.1.193
193.1.15.10.in-addr.arpa domain name pointer baby.hsv.redhat.com.
Comment 18 Fedora Update System 2012-11-20 23:08:38 EST
Package NetworkManager-0.9.6.4-3.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.6.4-3.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-18689/NetworkManager-0.9.6.4-3.fc17
then log in and leave karma (feedback).
Comment 19 Jirka Klimes 2012-11-21 04:42:29 EST
(In reply to comment #17)
> This did not fix the problem for me. I installed the new version and
> rebooted.
> 
Hmm, I re-tested again and it set hostname correctly for me.
Guy, can you restart NetworkManager again, check whether hostanme is set with 'hostname' commnad  and attach /var/log/messages (from the point where NetworkManager started)?
Comment 20 Fabrice Robin 2012-11-21 05:06:17 EST
Problem is fixed for me with NetworkManager-0.9.6.4-3.fc17
Thanks
Comment 21 Guy Streeter 2012-11-21 10:29:49 EST
Jirka,
 Restarting NetworkManager sets the hostname.

[root@localhost ~]# hostname
localhost
[root@localhost ~]# systemctl restart NetworkManager.service
[root@localhost ~]# hostname
baby.hsv.redhat.com

But it doesn't get set on boot (it used to, before the NM update). I will attach the messages file including the bootup and the NM restart.

thanks,
--Guy
Comment 22 Guy Streeter 2012-11-21 10:30:54 EST
Created attachment 649275 [details]
my /var/log/messages
Comment 23 Martin F 2012-11-21 16:10:32 EST
(In reply to comment #3)
> I have the same problem and have additional info.
Confirming that NetworkManager-0.9.6.4-3.fc17 fixed for me.
Comment 24 Fedora Update System 2012-11-21 22:58:48 EST
NetworkManager-0.9.6.4-3.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 25 Guy Streeter 2012-11-26 10:30:52 EST
Do I need to open a separate BZ for my system that still won't set the hostname until I restart NM after bootup.?
Comment 26 Jirka Klimes 2012-11-27 07:57:03 EST
Patch from comment #9 pushed to upstream master and nm-0-9-6 branch.
Comment 27 Fedora Update System 2012-11-27 08:56:44 EST
NetworkManager-0.9.7.0-8.git20121004.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.7.0-8.git20121004.fc18
Comment 28 Jirka Klimes 2012-11-27 09:10:26 EST
(In reply to comment #25)
> Do I need to open a separate BZ for my system that still won't set the
> hostname until I restart NM after bootup.?

Well, it may be better to track it in a separate bug.
Also, it would be good if you can enable debugging logs in NM, reboot and attach /var/log/messages to that bug report.

To enable debugging, you can e.g. temporarily change ExecStart= in /usr/lib/systemd/system/NetworkManager.service to:
ExecStart=/usr/sbin/NetworkManager --no-daemon --log-level=DEBUG
and reboot.
Comment 29 Fedora Update System 2012-11-29 01:39:52 EST
NetworkManager-0.9.7.0-8.git20121004.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 30 Fedora Update System 2013-01-23 11:10:25 EST
NetworkManager-0.9.6.4-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

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