Bug 707812

Summary: Network Manager deletes DNS when private network downed.
Product: Red Hat Enterprise Linux 6 Reporter: Travis Gummels <tgummels>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED NOTABUG QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: jrb, tpelka
Target Milestone: rc   
Target Release: 6.2   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 14:44:06 UTC Type: ---
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: 756082, 782183, 787802, 840699    

Description Travis Gummels 2011-05-26 02:59:54 UTC
Description of problem:

Network Manager deletes DNS when private network downed.

Adam: I noticed one other thing.
I have 2 interfaces. eth0 and eth1. eth0 configured with DNS1= and DNS2= for DNS servers.
eth1 on a private network segment, so no DNS servers.
iftup eth0, and everything looks good, DNS goes in resolv.conf
ifup eth1, all still good.
ifdown eth1 (so eth0 still up) and resolv.conf loses all nameservers.
No sure if that's really NM, or if that's a problem with the ifup/ifdown stuff.
me: that sounds like a good bug.
I can just imagine that happening and I think I know why.

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


How reproducible:
100%

Steps to Reproduce:
1. eth0 public network with defined DNS, eth1 private network
2.ifup eth0 all ok
3.ifup eth1 all ok
4.ifdown eth1 resolve.conf emptied of contents
  
Actual results:
resolve.conf emptied of contents

Expected results:
resolve.conf only modified for lines related to ethernet device being toggled.

Additional info:

Comment 2 Dan Williams 2011-06-14 23:25:38 UTC
Is NetworkManager allowed to control eth1 or has eth1 been excluded from NM via NM_CONTROLLED=no?

Comment 5 Dan Williams 2011-12-15 21:07:58 UTC
Any response for the question in comment 2?

Comment 7 Dan Williams 2012-01-04 20:31:45 UTC
The problem is that since eth0 isn't controlled by NM, there's no way to tell NM what's happening when eth0 is configured.  That's the problem with a shared file like resolv.conf.  If two things are touching it neither knows about the other.  NM only knows about the details of things that you let it manage, so if eth0 isn't managed by NM, anything that happens with eth0 is obviously out of the control and awareness of NM.  We can only realistically handle the case where (a) something is set up before NM starts and (b) NM never brings any devices up or down.  But in the scenario where NM is allowed to manage some devices and not allowed to manage other devices, it has no idea about default routes or resolv.conf information of those other devices.

(it's worse for DNS than routing because at least routes are tagged with an interface.  DNS is global but there's no indication that a nameserver is only valid for one interface and not for another...)

Is there any particular reason eth0 cannot be managed by NM?  Is eth0 a bridge or vlan?

Comment 12 RHEL Program Management 2012-07-10 06:54:19 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 13 RHEL Program Management 2012-07-11 00:03:31 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 15 Dan Williams 2012-08-09 20:15:42 UTC
What ifcfg files are there in /etc/sysconfig/network-scripts?  Also, can you attach /var/log/messages when the problem occurs?