Bug 733425
Summary: | anaconda doesn't honour reverse DNS lookup and sets hostname to localhost.localdomain | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Orion Poplawski <orion> |
Component: | lorax | Assignee: | Martin Gracik <mgracik> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | anaconda-maint-list, awilliam, bcl, dcbw, dmach, jklimes, jonathan, mgracik, sandro, tflink, vanmeeuwen+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | RejectedBlocker, AcceptedNTH | ||
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 19:59:30 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 713566 |
Description
Orion Poplawski
2011-08-25 16:51:57 UTC
It is the same after boot: [root@localhost ~]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=localhost.localdomain 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' Perhaps dupe of bug 706073 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. 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. 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. 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. 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? 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. 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. 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. shall we really close this, now anaconda 16.22 is stable? 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.) Good enough for me. |