Bug 1426748
| Summary: | NM changes /etc/resolv.conf even though there is PEERDNS=no in ifcfg-* files part 2 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vladimir Benes <vbenes> |
| Component: | NetworkManager | Assignee: | Francesco Giudici <fgiudici> |
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | aloughla, atragler, bgalvani, desktop-qa-list, fgiudici, lrintel, mleitner, rhepner, rkhan, sukulkar, syangsao, thaller, vbenes |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| 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: | 1405431 | Environment: | |
| Last Closed: | 2017-08-01 09:24:38 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: | 1405431 | ||
| Bug Blocks: | 1393481 | ||
| Attachments: | |||
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. Created attachment 1265010 [details]
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file
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. + /* 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"?
(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. (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? Created attachment 1265469 [details]
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file (NEW)
(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 if ( (priv->rc_manager == NM_DNS_MANAGER_RESOLV_CONF_MAN_FILE) otherwise LGTM! Created attachment 1265652 [details]
Avoid cleaning resolv.conf on exit when not strictly needed if rc-manager=file
(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! New patch prepared and merged upstream: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3ebe71cf064b2ccfa5b4a9423a9725b11f603ffa 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 |
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"