Bug 1157816

Summary: resolv.conf is overwritten if resolv.conf.save exists
Product: Red Hat Enterprise Linux 6 Reporter: William Yardley <wby+redhat>
Component: initscriptsAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED ERRATA QA Contact: Jan Ščotka <jscotka>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.5CC: psklenar, ptalbert
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: initscripts-9.03.47-1.el6 Doc Type: Bug Fix
Doc Text:
Cause: If interface was going down and there was resolv.conf.save we have replace resolv.conf by its content, even if during ifup for that interface we had not modified that file. Consequence: Unexpected changes to resolve.conf Fix: Now we replace resolv.conf only in the case that the device was dynamically configured or has DNS options in its ifcfg file. Result: Hopefully resolve.sconf will be updated only in sane cases.
Story Points: ---
Clone Of:
: 1273435 (view as bug list) Environment:
Last Closed: 2015-07-22 07:18:43 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:
Bug Depends On:    
Bug Blocks: 1273435    

Description William Yardley 2014-10-27 18:24:17 UTC
Description of problem:
If /etc/resolv.conf.save exists, restarting the network on the system will overwrite the default resolv.conf, at least in certain cases, even when NM_CONTROLLED=no is set and / or NetworkManager and dhclient are not installed or configured. I have not tested removing DNSX from /etc/sysconfig/network-scripts/ifcfg-em1, but I believe the problem will still exist in either case.

https://www.redhat.com/archives/rhelv6-list/2013-March/msg00010.html
also describes this problem

This is extremely annoying, and results in an important config file unexpectedly and unpredictably being clobbered.

Version-Release number of selected component (if applicable):
9.03.46-1

How reproducible:
Very

Steps to Reproduce:
1. Have /etc/resolv.conf.save exist, with a different config from the existing one
2. Restart networking or reboot the system
3. ???
4. Profit

Actual results:
resolv.conf is overwritten

Expected results:
resolv.conf should not be overwritten

Additional info:
Let me know if you need any further information

Comment 2 William Yardley 2014-10-27 18:33:43 UTC
ps - It looks like setting RESOLV_MODS to no may resolve this, however, I don't see a lot of documentation about this, and it does not default to 'no', so the behavior is still unexpected and unpredictable.

My expectation (and, I think, a reasonable person's) is that if DHCP is not enabled, and Network Manager is not being used, that resolv.conf should not be automatically overwritten.

Comment 3 Lukáš Nykrýn 2014-10-29 12:23:18 UTC
/etc/resolv.conf.save is created because you have DNSX specified.
RESOLV_MODS should not be used anymore. Documented way is to set PEERDNS=no

Comment 4 William Yardley 2014-10-29 19:36:12 UTC
[root@retr-test-01 ~]# cat /etc/resolv.conf
; pushed from Spacewalk
options timeout:2
options single-request-reopen
search example.edu
nameserver 10.0.235.5
nameserver 10.0.239.153
nameserver 10.0.139.100
[root@retr-test-01 ~]# cat /etc/resolv.conf.save
; pushed from Spacewalk
options timeout:2
options single-request-reopen
search example.edu
nameserver 10.0.139.100
nameserver 10.0.239.153

[root@retr-test-01 ~]# grep DNS /etc/sysconfig/network-scripts/ifcfg-eth*
[root@retr-test-01 ~]# /etc/init.d/network restart
[...]
[root@retr-test-01 ~]# cat /etc/resolv.conf
options timeout:2
options single-request-reopen
; pushed from Spacewalk
search example.edu
nameserver 10.0.139.100
nameserver 10.0.239.153



[root@retr-test-01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:50:56:94:16:d1
IPV6INIT=yes
MTU=1500
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID="bb91dbea-3773-42d8-a9d9-2e476f53c6d0"
IPADDR=192.168.32.7
NETMASK=255.255.255.0
GATEWAY=192.168.32.254
USERCTL=no

[eth1 is similar]


[root@retr-test-01 ~]# cat /etc/resolv.conf
; pushed from Spacewalk
options timeout:2
options single-request-reopen
search example.edu
nameserver 10.0.235.5
nameserver 10.0.239.153
nameserver 10.0.139.100
[root@retr-test-01 ~]# cat /etc/resolv.conf.save
; pushed from Spacewalk
options timeout:2
options single-request-reopen
search example.edu
nameserver 10.0.139.100
nameserver 10.0.239.153

[root@retr-test-01 ~]# grep DNS /etc/sysconfig/network-scripts/ifcfg-eth*
[root@retr-test-01 ~]# /etc/init.d/network restart
[...]
[root@retr-test-01 ~]# cat /etc/resolv.conf
options timeout:2
options single-request-reopen
; pushed from Spacewalk
search example.edu
nameserver 10.0.139.100
nameserver 10.0.239.153



[root@retr-test-01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:50:56:94:16:d1
IPV6INIT=yes
MTU=1500
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID="bb91dbea-3773-42d8-a9d9-2e476f53c6d0"
IPADDR=192.168.32.7
NETMASK=255.255.255.0
GATEWAY=192.168.32.254
USERCTL=no

[eth1 is similar]



Also, despite the code in /etc/sysconfig/network-scripts/ifdown-post:

if [ "$PEERDNS" != "no" -o -n "$RESOLV_MODS" -a "$RESOLV_MODS" != "no"
]; then

I'm seeing this:

[root@retr-test-01 ~]# cat /etc/resolv.conf
; pushed from Spacewalk
options timeout:2
options single-request-reopen
search example.edu
nameserver 10.0.235.5
nameserver 10.0.239.153
nameserver 10.0.139.100

[root@retr-test-01 ~]# cat /etc/resolv.conf.save
; pushed from Spacewalk
options timeout:2
options single-request-reopen
search example.edu
nameserver 10.0.239.153
nameserver 10.0.139.100

[root@retr-test-01 ~]# grep ^PEERD /etc/sysconfig/network-scripts/ifcfg-eth*
/etc/sysconfig/network-scripts/ifcfg-eth0:PEERDNS=no
/etc/sysconfig/network-scripts/ifcfg-eth1:PEERDNS=no

[root@retr-test-01 ~]# /etc/init.d/network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down interface eth1:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  Determining if ip address 192.168.32.7 is already
in use for device eth0...
                                                           [  OK  ]
Bringing up interface eth1:  Determining if ip address 172.16.17.7 is already in
use for device eth1...
cat /et                                                    [  OK  ]
[root@retr-test-01 ~]# cat /etc/resolv.conf
options timeout:2
options single-request-reopen
; pushed from Spacewalk
search example.edu
nameserver 10.0.239.153
nameserver 10.0.139.100

So it would seem that unless PEERDNS is set to NO on all interfaces,
including loopback interface(s), resolv.conf.save will get pushed over
resolv.conf?

Comment 5 Lukáš Nykrýn 2015-01-08 12:47:33 UTC
Maybe we should do what we have in sysconfig.txt and remove the resolve.conf only in the case that this was a ppp device or it had DNS specified or it was dynamically configured.

Mostly untested patch:

diff --git a/sysconfig/network-scripts/ifdown-post b/sysconfig/network-scripts/ifdown-post
index bcf4765..0f2285f 100755
--- a/sysconfig/network-scripts/ifdown-post
+++ b/sysconfig/network-scripts/ifdown-post
@@ -18,7 +18,8 @@ source_config
 
 /etc/sysconfig/network-scripts/ifdown-routes ${REALDEVICE} ${DEVNAME}
 
-if [ "$PEERDNS" != "no" -o -n "$RESOLV_MODS" -a "$RESOLV_MODS" != "no" ]; then
+if [ "$PEERDNS" != "no" -o -n "$RESOLV_MODS" -a "$RESOLV_MODS" != "no" ] && \
+   [ "${DEVICETYPE}" = "ppp" -o "${DEVICETYPE}" = "ippp" -o -n "${DNS1}" -o "${BOOTPROTO}" = "bootp" -o "${BOOTPROTO}" = "dhcp" ] ; then
     if [ -f /etc/resolv.conf.save ]; then
        change_resolv_conf /etc/resolv.conf.save
        rm -f /etc/resolv.conf.save

Comment 6 Lukáš Nykrýn 2015-01-12 12:47:48 UTC
*** Bug 1056779 has been marked as a duplicate of this bug. ***

Comment 10 errata-xmlrpc 2015-07-22 07:18:43 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://rhn.redhat.com/errata/RHBA-2015-1380.html