Bug 1344303
Summary: | hostnamectl set-hostname over-writes existing resolv.conf entries | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Anand Nande <anande> | ||||
Component: | NetworkManager | Assignee: | Francesco Giudici <fgiudici> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.2 | CC: | anande, atragler, bfournie, bgalvani, fgiudici, lrintel, mueller, rkhan, rupatel, sukulkar, systemd-maint-list, thaller, thierry.laurion, vbenes | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | NetworkManager-1.8.0-0.4.rc1.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-08-01 09:17:07 UTC | Type: | Bug | ||||
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: | 1393481 | ||||||
Attachments: |
|
> Additional Info: > > NetworkManager is not controlling any of their ifcfg/interfaces - resolv.conf is a global entity. Simply because NM doesn't manager any interfaces, it does not mean that it wouldn't touch resolv.conf. I don't understand, why this user has NetworkManager running, if he doesn't want to use NetworkManager for managing the interfaces. If the user does not want NetworkManager to manage resolv.conf, he should configure /etc/NetworkManager/NetworManager.conf with [main] dns=none Is there a problem with that? which NetworkManager version is used here? (In reply to Thomas Haller from comment #3) > > Additional Info: > > > > NetworkManager is not controlling any of their ifcfg/interfaces - > > resolv.conf is a global entity. Simply because NM doesn't manager any > interfaces, it does not mean that it wouldn't touch resolv.conf. > > > > I don't understand, why this user has NetworkManager running, if he doesn't > want to use NetworkManager for managing the interfaces. > > > > > If the user does not want NetworkManager to manage resolv.conf, he should > configure /etc/NetworkManager/NetworManager.conf with > > [main] > dns=none > > > > Is there a problem with that? Actually, this setting needs to be done on the os-disk-image which has the NetworkManager setting hardcoded. Customer is not ready to go this way. I am checking with the Openstack engineering team if they have any other suggestions. > > > > > which NetworkManager version is used here? $ rpm -qa | grep -i 'networkmanager' NetworkManager-libnm-1.0.6-29.el7_2.x86_64 NetworkManager-1.0.6-29.el7_2.x86_64 NetworkManager-team-1.0.6-29.el7_2.x86_64 NetworkManager-config-server-1.0.6-29.el7_2.x86_64 NetworkManager-tui-1.0.6-29.el7_2.x86_64 Does this NetworkManager behave any funny? (In reply to Anand Nande from comment #4) > (In reply to Thomas Haller from comment #3) > > > Additional Info: > > > > > > NetworkManager is not controlling any of their ifcfg/interfaces - > > > > resolv.conf is a global entity. Simply because NM doesn't manager any > > interfaces, it does not mean that it wouldn't touch resolv.conf. > > > > > > > > I don't understand, why this user has NetworkManager running, if he doesn't > > want to use NetworkManager for managing the interfaces. > > > > > > > > > > If the user does not want NetworkManager to manage resolv.conf, he should > > configure /etc/NetworkManager/NetworManager.conf with > > > > [main] > > dns=none > > > > > > > > Is there a problem with that? > > Actually, this setting needs to be done on the os-disk-image which has > the NetworkManager setting hardcoded. Customer is not ready to go this way. > I am checking with the Openstack engineering team if they have any other > suggestions. The default configuration of NetworkManager lets it manage resolv.conf. If the user doesn't want that, there is not much of an alternative then to change the configuration. If it's easier, the user can also drop it to a separate file /etc/NetworkManager/conf.d/99-no-dns.conf. Or alternatively `chattr +i /etc/resolv.conf` > > which NetworkManager version is used here? > > $ rpm -qa | grep -i 'networkmanager' > NetworkManager-libnm-1.0.6-29.el7_2.x86_64 > NetworkManager-1.0.6-29.el7_2.x86_64 > NetworkManager-team-1.0.6-29.el7_2.x86_64 > NetworkManager-config-server-1.0.6-29.el7_2.x86_64 > NetworkManager-tui-1.0.6-29.el7_2.x86_64 > > Does this NetworkManager behave any funny? It's our RHEL-7.2 latest and greatest. That should be fine :) (In reply to Thomas Haller from comment #3) > > Additional Info: > > > > NetworkManager is not controlling any of their ifcfg/interfaces - > > resolv.conf is a global entity. Simply because NM doesn't manager any > interfaces, it does not mean that it wouldn't touch resolv.conf. Inversely, why would it touch resolv.conf if none of the interface are managed by it? I confirm the same undesired behavior. ifcfg files contain no DNS information. Example: nmcli con show NAME UUID TYPE DEVICE Before: cat /etc/resolv.conf # Generated by NetworkManager search aaaaaaaa nameserver b.c.d.e nameserver f.g.h.i Test: hostnamectl set-hostname test After: cat /etc/resolv.conf # Generated by NetworkManager [... template file ...] The resolv.conf file is defaulted to a template. Why, in this context, the admin would have to also modify /etc/NetworkManager/NetworManager.conf (or create conf.d file) to inform NetworkManager to not manage dns if it is explicitely told to not do so for each interface ifcfg file with "NM_CONTROLLED=no" statements? > > > > I don't understand, why this user has NetworkManager running, if he doesn't > want to use NetworkManager for managing the interfaces. nmcli could be useful to manage bonding of interfaces, as an example. As a developer, I do not want to change global configuration, but want to limit the impact of user's choices on the services deployed, which is why it is expected that the resolv.conf file is not overwritten (for nothing her > > > > > If the user does not want NetworkManager to manage resolv.conf, he should > configure /etc/NetworkManager/NetworManager.conf with > > [main] > dns=none > > > > Is there a problem with that? I do not understand in what condition a NetworkManager not managing any interface would logically overwrite resolv.conf. I would understand if one of the managed interface by NetworkManager would get DNS servers from DHCP though, but it's not the case here. > > > > > which NetworkManager version is used here? Same observed behavior under CentOS7 with: rpm -qa | grep -i 'networkmanager' NetworkManager-tui-1.0.6-27.el7.x86_64 NetworkManager-1.0.6-27.el7.x86_64 NetworkManager-libnm-1.0.6-27.el7.x86_64 NetworkManager-wifi-1.0.6-27.el7.x86_64 and latest: rpm -qa | grep -i 'networkmanager' NetworkManager-tui-1.0.6-29.el7_2.x86_64 NetworkManager-libnm-1.0.6-29.el7_2.x86_64 NetworkManager-1.0.6-29.el7_2.x86_64 NetworkManager-wifi-1.0.6-29.el7_2.x86_64 Regards, Thierry In fact, any change to the /etc/hostname file is cought by nm_dispatcher which results in resolv.conf file to be modified. Jun 22 13:48:46 test NetworkManager[605]: <info> Setting system hostname to 'test' (from system configuration) Jun 22 13:48:46 test dbus[610]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jun 22 13:48:46 test dbus-daemon[610]: dbus[610]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jun 22 13:48:46 test systemd[1]: Starting Network Manager Script Dispatcher Service... Jun 22 13:48:46 test dbus[610]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 22 13:48:46 test dbus-daemon[610]: dbus[610]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jun 22 13:48:46 test systemd[1]: Started Network Manager Script Dispatcher Service. Jun 22 13:48:46 test nm-dispatcher[3006]: Dispatching action 'hostname' (In reply to thierry.laurion from comment #6) > (In reply to Thomas Haller from comment #3) > > > > resolv.conf is a global entity. Simply because NM doesn't manager any > > interfaces, it does not mean that it wouldn't touch resolv.conf. > Inversely, why would it touch resolv.conf if none of the interface are > managed by it? As said, resolv.conf is a global entity. Even if no interfaces are managed, you still have a resolv.conf. Not managing any interfaces, does not imply not managing resolv.conf. Managing resolv.conf has to be configured independently from configuring individual interfaces. > The resolv.conf file is defaulted to a template. Why, in this context, the > admin would have to also modify /etc/NetworkManager/NetworManager.conf (or > create conf.d file) to inform NetworkManager to not manage dns if it is > explicitely told to not do so for each interface ifcfg file with > "NM_CONTROLLED=no" statements? By NM_CONTROLLED=no NM is told not to manage a particular interface. It is not told anything about whether to manage resolv.conf. > I do not understand in what condition a NetworkManager not managing any > interface would logically overwrite resolv.conf. I would understand if one > of the managed interface by NetworkManager would get DNS servers from DHCP > though, but it's not the case here. "no DNS servers" is also a kind of DNS configuration. (In reply to thierry.laurion from comment #6) > The resolv.conf file is defaulted to a template. Why, in this context, the > admin would have to also modify /etc/NetworkManager/NetworManager.conf (or > create conf.d file) to inform NetworkManager to not manage dns if it is > explicitely told to not do so for each interface ifcfg file with > "NM_CONTROLLED=no" statements? As said in comment 3, resolv.conf is global and even if all devices are set as NM_CONTROLLED=no, there are other events in which NM may want to update its content. For example we allow to set a static global DNS configuration through a D-Bus call; or other (real or software) devices might appear and NM would start managing them, depending on configuration, possibly updating DNS information. So in my opinion setting devices as NM_CONTROLLED=no, manually overwriting resolv.conf and hoping that none of this events will happen is a very fragile solution; especially if there are ways to explicitly tell NM not to touch the file. we're struggled over this too in RHEL 7.3. Setting the hostname and having resolv.conf overridden because of that is just unexpected. If you go and ask 100 people if setting the hostname is expected to change your dns server settings I guess nobody will choose the "of course it will" answer. It's really no technical problem, its what one expects to happen when a hostnamectl is run. On the other hand I'll expect NetworkManager to manage /etc/resolv.conf. Wouldn't the service be called "systemd-hostnamed" but "NetworkManager-hostnamed" I maybe would have expected a changed resolv.conf. Now I know how to configure NetworkManager.conf with main/dns=none - but some servers needed to fail before getting this knowledge. (In reply to Thomas Mueller from comment #15) > we're struggled over this too in RHEL 7.3. > > Setting the hostname and having resolv.conf overridden because of that is > just unexpected. If you go and ask 100 people if setting the hostname is > expected to change your dns server settings I guess nobody will choose the > "of course it will" answer. It's really no technical problem, its what one > expects to happen when a hostnamectl is run. Consider that the hostname and DNS are very much related. When the hostname is a FQDN, then NetworkManager adds the domain to the search list. Thus, a change of the hostname, triggers a DNS update, which triggers (depending on configuration) an update of resolv.conf. Note that at various times NetworkManager triggers a DNS update (which may lead to an update of resolv.conf). E.g. on a new DHCP lease or when a connection activates/deactivates. If the behavior (hostname change triggers a resolv.conf update) is a problem for you, then you have a similar problem in other cases as well. If you don't want NetworkManager to touch resolv.conf, configure it not to do so. NM manages resolv.conf on RHEL-7.3, because it is supposedly/arbuably best for many scenarious. In the future, we may want to use systemd-resolved or something else that allows combining DNS information from multiple sources. For now, if the default doesn't suit you, all of this is configurable already and you can manage resolv.conf however you wish. You just need to tell NM about that. (In reply to Thomas Haller from comment #16) > (In reply to Thomas Mueller from comment #15) > > we're struggled over this too in RHEL 7.3. > > > > Setting the hostname and having resolv.conf overridden because of that is > > just unexpected. If you go and ask 100 people if setting the hostname is > > expected to change your dns server settings I guess nobody will choose the > > "of course it will" answer. It's really no technical problem, its what one > > expects to happen when a hostnamectl is run. > > Consider that the hostname and DNS are very much related. When the hostname > is a FQDN, then NetworkManager adds the domain to the search list. Thus, a > change of the hostname, triggers a DNS update, which triggers (depending on > configuration) an update of resolv.conf. My point is still, that hostnamectl does not look like you are editing resolv.conf. but I'm with you that there is a relation of the domain name and the FQDN. I'll update NetworkManager.conf with main/dns=none - no problem. I just wished I knew earlier howto disable the management of resolv.conf. So I proposed a hint to spread the knowledge about the config option in the generated resolv.conf - to send people to the right place when they want to manage resolv.conf themself: https://github.com/NetworkManager/NetworkManager/pull/12 Created attachment 1261967 [details] don't trigger dns reconf on hostname update if no device is active The main point here is this NetworkManager behavior: (*) when the hostname is changed NetworkManager will overwrite resolv.conf The reason behind this is that NetworkManager needs to add "search <domain name>" to /etc/resolv.conf. NetworkManager registers on static hostname changes, so if you perform a hostnamectl set-hostname <fqdn>, it will immediately get aware of it and will end overwriting /etc/resolv.conf to update the "search" option. As already said, the proper way to stop NetworkManager from changing resolv.conf is to put dns=none in NetworkManager.conf or let /etc/resolv.conf to symlink to a custom file. I can understand that an admin updating the hostname may not immediately realize that this would trigger an overwrite of resolv.conf. Anyway, I think NetworkManager behavior is correct. A new "hostname" option will be available in NetworkManager.conf that will allow, when set to "none", to disable hostname management in NetworkManager: this will also allow to skip updating resolv.conf when the hostname changes (see https://bugzilla.redhat.com/show_bug.cgi?id=1422610). What I would add here is to let NetworkManager skip updating resolv.conf on hostname change if it has no active (or activating) devices (this includes the case where all devices are unmanaged): please review the attached patch. lgtm (In reply to Francesco Giudici from comment #19) > Created attachment 1261967 [details] > don't trigger dns reconf on hostname update if no device is active Looks good to me. Patch merged upstream: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b07f6712 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2299 |
systemd-hostnamed does not touch /etc/resolv.conf at all. I guess NM does that. With NM: [0 root@qeos-66 ~]# cp /etc/resolv.conf /root/ [0 root@qeos-66 ~]# hn=$(hostname -f) [0 root@qeos-66 ~]# echo $hn qeos-66.lab.eng.rdu2.redhat.com [0 root@qeos-66 ~]# hostnamectl set-hostname $hn; hostnamectl set-hostname --transient $hn [0 root@qeos-66 ~]# diff /etc/resolv.conf /root/resolv.conf 2c2 < search openstacklocal lab.eng.rdu2.redhat.com --- > search openstacklocal brq.redhat.com Without NM: [0 root@qeos-65 ~]# systemctl stop NetworkManager [0 root@qeos-65 ~]# [0 root@qeos-65 ~]# cp /etc/resolv.conf /root/ [0 root@qeos-65 ~]# hn=$(hostname -f) [0 root@qeos-65 ~]# echo $hn qeos-65.lab.eng.rdu2.redhat.com [0 root@qeos-65 ~]# hostnamectl set-hostname $hn; hostnamectl set-hostname --transient $hn [0 root@qeos-65 ~]# diff /etc/resolv.conf /root/resolv.conf [0 root@qeos-65 ~]#