RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1426748 - NM changes /etc/resolv.conf even though there is PEERDNS=no in ifcfg-* files part 2
Summary: NM changes /etc/resolv.conf even though there is PEERDNS=no in ifcfg-* files ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Francesco Giudici
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1405431
Blocks: 1393481
TreeView+ depends on / blocked
 
Reported: 2017-02-24 18:09 UTC by Vladimir Benes
Modified: 2020-02-14 18:32 UTC (History)
13 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: 1405431
Environment:
Last Closed: 2017-08-01 09:24:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file (1.54 KB, patch)
2017-03-21 10:53 UTC, Francesco Giudici
no flags Details | Diff
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file (NEW) (1.54 KB, patch)
2017-03-22 18:45 UTC, Francesco Giudici
no flags Details | Diff
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file (1.56 KB, patch)
2017-03-23 09:20 UTC, Francesco Giudici
no flags Details | Diff


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

Comment 1 Vladimir Benes 2017-02-24 18:12:41 UTC
part 1 works:

        Scenario: nmcli - ipv4 - preserve resolveconf if ignore_auto_dns
        * Add a new connection of type "ethernet" and options "con-name ethie ifname eth1 ipv4.ignore-auto-dns yes ipv6.ignore-auto-dns yes"
        * Bring "down" connection "ethie"
        * Stop NM
        * Execute "echo 'search boston.com' > /etc/resolv.conf"
        * Execute "echo 'nameserver 1.2.3.4' >> /etc/resolv.conf"
        * Start NM
        When "boston.com" is visible with command "cat /etc/resolv.conf"
         And "nameserver 1.2.3.4" is visible with command "cat /etc/resolv.conf"
        * Restart NM
        When "boston.com" is visible with command "cat /etc/resolv.conf"
         And "nameserver 1.2.3.4" is visible with command "cat /etc/resolv.conf"
        * Restart NM
        Then "boston.com" is visible with command "cat /etc/resolv.conf"
         And "nameserver 1.2.3.4" is visible with command "cat /etc/resolv.conf"


but part 2 where some connection with dhcp was activated doesn't work

        Scenario: nmcli - ipv4 - preserve resolveconf if ignore_auto_dns
        * Bring "up" connection "testeth0"
        * Bring "down" connection "testeth0"
        * Add a new connection of type "ethernet" and options "con-name ethie ifname eth1 ipv4.ignore-auto-dns yes ipv6.ignore-auto-dns yes"
        * Bring "down" connection "ethie"
        #* Stop NM
        * Execute "echo 'search boston.com' > /etc/resolv.conf"
        * Execute "echo 'nameserver 1.2.3.4' >> /etc/resolv.conf"
        #* Start NM
        When "boston.com" is visible with command "cat /etc/resolv.conf"
         And "nameserver 1.2.3.4" is visible with command "cat /etc/resolv.conf"
        * Restart NM
        When "boston.com" is visible with command "cat /etc/resolv.conf"
         And "nameserver 1.2.3.4" is visible with command "cat /etc/resolv.conf"
        * Restart NM
        Then "boston.com" is visible with command "cat /etc/resolv.conf"
         And "nameserver 1.2.3.4" is visible with command "cat /etc/resolv.conf"

Comment 2 Thomas Haller 2017-02-28 12:38:29 UTC
I think part 1 is a bug in NM.

When NM is configured to manage resolv.conf, then it should *always* write something there. I mean, having *no* nameservers is a kind of configuration, and NM should write a resolv.conf with no DNS servers.

The test tests that NM would not clear the externally configured resolv.conf, but  NM should do that.

part 2 is how it's supposed to be.

Comment 4 Francesco Giudici 2017-03-21 10:53:15 UTC
Created attachment 1265010 [details]
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file

Comment 5 Francesco Giudici 2017-03-21 10:55:04 UTC
We discussed a bit and decided to avoid touching resolv.conf when only connections with PEERDNS=no are enabled and rc-manager=file.
NetworkManager still supports managing resolv.conf exclusively but it makes sense to be more tolerant and avoid resetting resolv.conf when not strictly needed, especially when resolv.conf is not symlinked.
So, we want to support both part 1 and part 2 tests.

When NetworkManager changes resolv.conf it will track internally that resolv.conf has been modified. If then all the connections are teared down, an empty resolv.conf will be written.

If NetworkManager is stopped, it will check its internal flag tracking if it ever changed resolv.conf: if it is enabled, it will clean resolv.conf, also if it was already empty.

When rc-manager=file it makes sense to skip cleaning resolv.conf on exit if the last write from NetworkManager already generated a file without nameservers. In this case, just reset the "changed resolv.conf" tracking flag.

Please review the attached patch.

Comment 6 Beniamino Galvani 2017-03-21 22:14:05 UTC
+   /* If we have ended with an empty resolv.conf avoid resetting it again on stop,
     * maybe some external changes have been applied to resolv.conf */
    if (   (NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE)

 if (   (priv->rc_manager == NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE)

+       && !nameservers
+       && !options)

Don't we need to check also searches to verify the condition "empty
resolv.conf"?

Comment 7 Francesco Giudici 2017-03-22 09:28:10 UTC
(In reply to Beniamino Galvani from comment #6)
> +   /* If we have ended with an empty resolv.conf avoid resetting it again
> on stop,
>      * maybe some external changes have been applied to resolv.conf */
>     if (   (NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE)
> 
>  if (   (priv->rc_manager == NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE)
> 
> +       && !nameservers
> +       && !options)
> 
> Don't we need to check also searches to verify the condition "empty
> resolv.conf"?

Well, I was not completely clear... resolv.conf is updated a last time when quitting if the internal "touched" flag is true.
The point is that the search option will be (also) filled with the domain part of the hostname, so also if you have all the connections not active you will never have an empty resolv.conf if you have FQDN hostname: you will get one with the search option.
This is why we need to skip the searches from the check.

Comment 8 Beniamino Galvani 2017-03-22 17:56:12 UTC
(In reply to Francesco Giudici from comment #7)

> Well, I was not completely clear... resolv.conf is updated a last time when
> quitting if the internal "touched" flag is true.
> The point is that the search option will be (also) filled with the domain
> part of the hostname, so also if you have all the connections not active you
> will never have an empty resolv.conf if you have FQDN hostname: you will get
> one with the search option.
> This is why we need to skip the searches from the check.

Ok, then can you replace "an empty resolv.conf" with "no nameservers in resolv.conf" in the comment?

Comment 9 Francesco Giudici 2017-03-22 18:45:46 UTC
Created attachment 1265469 [details]
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file (NEW)

Comment 10 Francesco Giudici 2017-03-22 18:47:22 UTC
(In reply to Beniamino Galvani from comment #8)
> (In reply to Francesco Giudici from comment #7)
> 
> > Well, I was not completely clear... resolv.conf is updated a last time when
> > quitting if the internal "touched" flag is true.
> > The point is that the search option will be (also) filled with the domain
> > part of the hostname, so also if you have all the connections not active you
> > will never have an empty resolv.conf if you have FQDN hostname: you will get
> > one with the search option.
> > This is why we need to skip the searches from the check.
> 
> Ok, then can you replace "an empty resolv.conf" with "no nameservers in
> resolv.conf" in the comment?

Sure, patch updated.
Thanks

Comment 11 Beniamino Galvani 2017-03-22 20:56:05 UTC
 if (   (priv->rc_manager == NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE)

otherwise LGTM!

Comment 12 Francesco Giudici 2017-03-23 09:20:07 UTC
Created attachment 1265652 [details]
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file

Comment 13 Francesco Giudici 2017-03-23 09:21:13 UTC
(In reply to Beniamino Galvani from comment #11)
>  if (   (priv->rc_manager == NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE)
> 
> otherwise LGTM!

sure, patch updated

Thanks!

Comment 14 Francesco Giudici 2017-03-23 17:04:45 UTC
New patch prepared and merged upstream:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3ebe71cf064b2ccfa5b4a9423a9725b11f603ffa

Comment 16 errata-xmlrpc 2017-08-01 09:24:38 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.