Bug 733425 - anaconda doesn't honour reverse DNS lookup and sets hostname to localhost.localdomain
anaconda doesn't honour reverse DNS lookup and sets hostname to localhost.loc...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: lorax (Show other bugs)
16
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Martin Gracik
Fedora Extras Quality Assurance
RejectedBlocker, AcceptedNTH
:
Depends On:
Blocks: F16-accepted/F16FinalFreezeExcept
  Show dependency treegraph
 
Reported: 2011-08-25 12:51 EDT by Orion Poplawski
Modified: 2013-07-04 08:58 EDT (History)
11 users (show)

See Also:
Fixed In Version: lorax-16.4.3-1.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-25 15:59:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2011-08-25 12:51:57 EDT
Description of problem:

In %post, uname -n returns localhost.localdomain, it should return the hostname as assigned by dhcp.

Version-Release number of selected component (if applicable):
16.14.6
Comment 1 Orion Poplawski 2011-08-25 12:54:12 EDT
It is the same after boot:

[root@localhost ~]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=localhost.localdomain
Comment 2 Orion Poplawski 2011-08-25 12:58:02 EDT
From anaconda.syslog:
15:16:49,0 INFO NetworkManager: <info> Activation (eth0) Stage 4 of 5 (IP4 Configure Get) started...
15:16:49,0 INFO NetworkManager: <info>   address 10.10.11.101
15:16:49,0 INFO NetworkManager: <info>   prefix 16 (255.255.0.0)
15:16:49,0 INFO NetworkManager: <info>   gateway 10.10.0.1
15:16:49,0 INFO NetworkManager: <info>   hostname 'vmrawhide.cora.nwra.com'
15:16:49,0 INFO NetworkManager: <info>   nameserver '10.10.10.1'
15:16:49,0 INFO NetworkManager: <info>   nameserver '10.10.10.2'
15:16:49,0 INFO NetworkManager: <info>   domain name 'cora.nwra.com'
Comment 3 Orion Poplawski 2011-08-25 18:48:35 EDT
Perhaps dupe of bug 706073
Comment 4 Jirka Klimes 2011-08-31 03:12:05 EDT
NetworkManager tries to set hostname in the following order:

1) a configured hostname (from settings)
2) automatic hostname from the default device's config (DHCP, VPN, etc)
3) the original hostname when NM started
4) reverse-DNS lookup

So, when you have HOSTNAME configured in /etc/sysconfig/network, it takes precedence.
In your case (localhost.localdomain) you can use NM_IGNORE_HOSTNAME_LOCALHOST=yes to ignore localhost hostname. Or simply remove the HOSTNAME.

See also bug 719100 that actually fixed reading DHCP host-name option.
Comment 5 Orion Poplawski 2011-08-31 11:08:15 EDT
When the installer boots, I don't think there is an /etc/sysconfig/network.  And I'm not sure who is generating the final one.
Comment 6 Orion Poplawski 2011-09-06 14:44:50 EDT
Looking in the installer root there is an /etc/sysconfig/network with:

HOSTNAME=localhost.localdomain

It has a funky Aug 25 timestamp so I'm assuming it comes from anaconda somehow.

Lates devel tree with 16.16.
Comment 7 Radek Vykydal 2011-09-09 07:31:52 EDT
We need to stop creating /etc/sysconfig/network in our install images (by lorax) so that it doesn't override settings 2) - 4) for NetworkManager (from comment 4). I tested that this actually fixes the problem in case of 4):

09:53:13,0 INFO NetworkManager: <info> Activation (p3p1) Stage 4 of 5 (IP4 Configure Get) scheduled...
09:53:13,0 INFO NetworkManager: <info> Activation (p3p1) Stage 4 of 5 (IP4 Configure Get) started...
09:53:13,0 INFO NetworkManager: <info>   address 10.34.39.64
09:53:13,0 INFO NetworkManager: <info>   prefix 24 (255.255.255.0)
09:53:13,0 INFO NetworkManager: <info>   gateway 10.34.39.254
09:53:13,0 INFO NetworkManager: <info>   nameserver '10.34.39.2'
09:53:13,0 INFO NetworkManager: <info>   domain name 'anaconda.englab.brq.redhat.com'
09:53:13,0 INFO NetworkManager: <info>   domain name 'englab.brq.redhat.com'
09:53:13,0 INFO NetworkManager: <info>   domain name 'brq.redhat.com'
09:53:13,0 INFO NetworkManager: <info>   domain name 'redhat.com'
09:53:13,0 INFO NetworkManager: <info> Activation (p3p1) Stage 5 of 5 (IP Configure Commit) scheduled...
09:53:13,0 INFO NetworkManager: <info> Activation (p3p1) Stage 4 of 5 (IP4 Configure Get) complete.
09:53:13,0 INFO NetworkManager: <info> Activation (p3p1) Stage 5 of 5 (IP Configure Commit) started...
09:53:14,0 INFO NetworkManager: <info> (p3p1): device state change: ip-config -> activated (reason 'none') [70 100 0]
09:53:14,0 INFO NetworkManager: <info> Policy set 'System p3p1' (p3p1) as default for IPv4 routing and DNS.
09:53:14,0 INFO NetworkManager: <info> Activation (p3p1) successful, device activated.
09:53:14,0 NOTICE dbus: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
09:53:14,0 INFO NetworkManager: <info> Activation (p3p1) Stage 5 of 5 (IP Configure Commit) complete.
09:53:14,0 INFO NetworkManager: <info> Setting system hostname to 'dhcp64.anaconda.englab.brq.redhat.com' (from address lookup)

Nevertheless, it doesn't work for case 2) so I wonder if the bug 719100 is actually fixed, according to BZ we are using version of NM that should have the fix:

10:13:46,0 INFO NetworkManager: <info> NetworkManager (version 0.8.9997-7.git20110721.fc16) is starting...

but:

10:14:13,0 INFO NetworkManager: <info> (p4p1): DHCPv4 state changed preinit -> bound
10:14:13,0 INFO NetworkManager: <info> Activation (p4p1) Stage 4 of 5 (IP4 Configure Get) scheduled...
10:14:13,0 INFO NetworkManager: <info> Activation (p4p1) Stage 4 of 5 (IP4 Configure Get) started...
10:14:13,0 INFO NetworkManager: <info>   address 192.168.146.146
10:14:13,0 INFO NetworkManager: <info>   prefix 24 (255.255.255.0)
10:14:13,0 INFO NetworkManager: <info>   gateway 192.168.146.1
10:14:13,0 INFO NetworkManager: <info>   hostname 'mamard.ovno.rovno'
10:14:13,0 INFO NetworkManager: <info>   nameserver '192.168.146.1'
10:14:13,0 INFO NetworkManager: <info>   domain name 'ovno.rovno'
10:14:13,0 INFO NetworkManager: <info> Activation (p4p1) Stage 5 of 5 (IP Configure Commit) scheduled...
10:14:13,0 INFO NetworkManager: <info> Activation (p4p1) Stage 4 of 5 (IP4 Configure Get) complete.
10:14:13,0 INFO NetworkManager: <info> Activation (p4p1) Stage 5 of 5 (IP Configure Commit) started...
10:14:13,0 INFO dhclient: bound to 192.168.146.146 -- renewal in 718 seconds.
10:14:14,0 INFO NetworkManager: <info> (p4p1): device state change: ip-config -> activated (reason 'none') [70 100 0]
10:14:14,0 INFO NetworkManager: <info> Policy set 'System p4p1' (p4p1) as default for IPv4 routing and DNS.
10:14:14,0 INFO NetworkManager: <info> Activation (p4p1) successful, device activated.

whereas in F15 where it works:

10:21:34,0 INFO NetworkManager: <info> (p4p1): DHCPv4 state changed preinit -> bound
10:21:34,0 INFO NetworkManager: <info> Activation (p4p1) Stage 4 of 5 (IP4 Configure Get) scheduled...
10:21:34,0 INFO NetworkManager: <info> Activation (p4p1) Stage 4 of 5 (IP4 Configure Get) started...
10:21:34,0 INFO NetworkManager: <info>   address 192.168.146.146
10:21:34,0 INFO NetworkManager: <info>   prefix 24 (255.255.255.0)
10:21:34,0 INFO NetworkManager: <info>   gateway 192.168.146.1
10:21:34,0 INFO NetworkManager: <info>   hostname 'mamard.ovno.rovno'
10:21:34,0 INFO dhclient: bound to 192.168.146.146 -- renewal in 798 seconds.
10:21:34,0 INFO NetworkManager: <info>   nameserver '192.168.146.1'
10:21:34,0 INFO NetworkManager: <info>   domain name 'ovno.rovno'
10:21:34,0 INFO NetworkManager: <info> Activation (p4p1) Stage 5 of 5 (IP Configure Commit) scheduled...
10:21:34,0 INFO NetworkManager: <info> Activation (p4p1) Stage 4 of 5 (IP4 Configure Get) complete.
10:21:35,0 INFO NetworkManager: <info> Activation (p4p1) Stage 5 of 5 (IP Configure Commit) started...
10:21:36,0 INFO NetworkManager: <info> (p4p1): device state change: ip-config -> activated (reason 'none') [70 100 0]
10:21:36,0 INFO NetworkManager: <info> Policy set 'System p4p1' (p4p1) as default for IPv4 routing and DNS.

see:
10:21:36,0 INFO NetworkManager: <info> Setting system hostname to 'mamard.ovno.rovno' (from DHCPv4)

10:21:36,0 NOTICE dbus-daemon: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
10:21:36,0 INFO NetworkManager: <info> Activation (p4p1) successful, device activated.
Comment 8 Orion Poplawski 2011-09-26 15:50:09 EDT
I can confirm case 4 working as well in F16 RC2:

11:27:47,0 INFO NetworkManager: NetworkManager[677]: <info> Setting system hostname to 'makani.cora.nwra.com' (from address lookup)

All of my machines have reverse DNS so I really can't test case #2.  Should this get assigned back to NM?
Comment 9 Radek Vykydal 2011-09-29 11:35:53 EDT
We patched lorax so that /etc/sysconfig/network is no more written. The change is applied in F16 beta rc3, so the case 4) from is fixed in the compose, but the case 2) still doesn't work for me.

Jirka, can you please take a look at comment #7 ? It seems to me that bug #719100 is not fixed in F16 beta rc3.
Comment 10 Tim Flink 2011-10-03 12:48:02 EDT
Discussed in the 2011-09-30 blocker bug review meeting. Rejected as a blocker bug for Fedora 16 final because it doesn't hit any of the release criteria. However, it sounds like a fix is underway and it would be nice to see fixed - accepted as NTH for Fedora 16 final.
Comment 11 Radek Vykydal 2011-10-20 11:34:21 EDT
So, the DNS lookup part (case 4) of the bug is fixed in F16 TC1, the DHCP part (case 2) should be fixed in NM in master in bug #719100.

I am passing NTH proposal to the NM bug, and closing this one as modified.
Comment 12 Adam Williamson 2011-10-24 20:57:46 EDT
shall we really close this, now anaconda 16.22 is stable?
Comment 13 Radek Vykydal 2011-10-25 08:41:05 EDT
Yes, the DNS part is really fixed in F16, images of which (e.g. tc1, tc2) are built with lorax containing the fix (Fixed in Version lorax-16.4.3-1.fc16). (Process-wise this bug perhaps belongs to lorax component.)
Comment 14 Adam Williamson 2011-10-25 15:59:30 EDT
Good enough for me.

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