Bug 1157816 - resolv.conf is overwritten if resolv.conf.save exists
Summary: resolv.conf is overwritten if resolv.conf.save exists
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: Jan Ščotka
URL:
Whiteboard:
: 1056779 (view as bug list)
Depends On:
Blocks: 1273435
TreeView+ depends on / blocked
 
Reported: 2014-10-27 18:24 UTC by William Yardley
Modified: 2016-11-25 13:05 UTC (History)
2 users (show)

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.
Clone Of:
: 1273435 (view as bug list)
Environment:
Last Closed: 2015-07-22 07:18:43 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1380 normal SHIPPED_LIVE initscripts bug fix update 2015-07-20 17:58:24 UTC

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


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