Bug 1344303 - hostnamectl set-hostname over-writes existing resolv.conf entries
Summary: hostnamectl set-hostname over-writes existing resolv.conf entries
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.2
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Francesco Giudici
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1393481
TreeView+ depends on / blocked
 
Reported: 2016-06-09 11:28 UTC by Anand Nande
Modified: 2017-08-01 09:17 UTC (History)
14 users (show)

Fixed In Version: NetworkManager-1.8.0-0.4.rc1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:17:07 UTC


Attachments (Terms of Use)
don't trigger dns reconf on hostname update if no device is active (3.40 KB, patch)
2017-03-10 15:53 UTC, Francesco Giudici
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 normal SHIPPED_LIVE Moderate: NetworkManager and libnl3 security, bug fix and enhancement update 2017-08-01 12:40:28 UTC

Comment 2 Lukáš Nykrýn 2016-06-09 12:08:22 UTC
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 ~]#

Comment 3 Thomas Haller 2016-06-09 15:55:35 UTC
> 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?

Comment 4 Anand Nande 2016-06-14 07:23:19 UTC
(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?

Comment 5 Thomas Haller 2016-06-14 10:47:11 UTC
(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 :)

Comment 6 thierry.laurion 2016-06-22 17:38:27 UTC
(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

Comment 7 thierry.laurion 2016-06-22 17:53:07 UTC
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'

Comment 8 Thomas Haller 2016-07-05 08:18:23 UTC
(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.

Comment 9 Beniamino Galvani 2016-07-05 08:34:44 UTC
(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.

Comment 15 Thomas Mueller 2016-12-02 16:37:05 UTC
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.

Comment 16 Thomas Haller 2016-12-03 11:18:49 UTC
(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.

Comment 17 Thomas Mueller 2016-12-03 14:36:02 UTC
(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

Comment 19 Francesco Giudici 2017-03-10 15:53:11 UTC
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.

Comment 20 Thomas Haller 2017-03-13 12:19:37 UTC
lgtm

Comment 21 Beniamino Galvani 2017-03-13 12:45:40 UTC
(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.

Comment 22 Francesco Giudici 2017-03-16 17:32:39 UTC
Patch merged upstream:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b07f6712

Comment 24 errata-xmlrpc 2017-08-01 09:17:07 UTC
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


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