Bug 888329

Summary:	Initscripts should ask NetworkManager if it is managing an interface
Product:	Red Hat Enterprise Linux 6	Reporter:	Antoni Segura Puimedon <asegurap>
Component:	NetworkManager	Assignee:	Dan Williams <dcbw>
Status:	CLOSED DUPLICATE	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	asegurap, bazulay, danken, dcbw, initscripts-maint-list, jklimes, lnykryn, lpeer, notting, psimerda, rkhan, tpelka
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-25 23:32:23 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:

Description Antoni Segura Puimedon 2012-12-18 14:05:31 UTC

Description of problem:
initscripts is able to use NetworkManager's nmcli to ifup and ifdown interfaces. To decide whether NM or plain initscripts flow is used, initscripts checks the existence and value of NM_CONTROLLED.

The problem with that is that NM_CONTROLLED=no by itself does not mean that the interface will not be managed by NetworkManager. For example, if HWADDR is missing from ifcfg, the interface will be managed by NM in any case.

The best way to know for sure if NM is controlling a device is asking it via DBUS.

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

How reproducible: 100%

Steps to Reproduce:
1. Create an ifcfg with NM_CONTROLLED=no and no HWADDR field
2. execute ifup

Actual results:
ifup does not use nmcli

Expected results:
ifup should use nmcli since NM states that the interface is managed.

Additional info:
The proposed flow for initscripts would be:

#Get the string em1 substituted by $1
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetDeviceByIpIface string:"em1"

#Substitute "/org/freedesktop/NetworkManager/Devices/1" with the objpath returned by the previous command.
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager/Devices/1 org.freedesktop.DBus.Properties.Get string:"org.freedesktop.NetworkManager.Device" string:"state"

# use NM for ifup or ifdown if and only if the state returned by the previous command is different than 10 (which in NM means unmanaged).

Comment 1 Antoni Segura Puimedon 2012-12-18 14:16:15 UTC

I'd like to add, that an alternative fix would be that NetworkManager would just honor the NM_CONTROLLED setting regardless of HWADDR (as there are some devices like bonds that have potentially changing mac addresses) and that they would use the ip device name just like you can get it in org.freedesktop.NetworkManager.GetDeviceByIpIface

Comment 2 Lukáš Nykrýn 2012-12-18 14:18:25 UTC

From sysconfig.txt:
"NM_CONTROLLED=yes|no 
If set to 'no', NetworkManager will ignore this connection/device."
So I think that this behavior should be fixed in NM and only if it can't be fixed there we should talk about workaround it in initscripts.

Comment 4 Pavel Šimerda (pavlix) 2012-12-18 15:16:04 UTC

(In reply to comment #1)
> I'd like to add, that an alternative fix would be that NetworkManager would
> just honor the NM_CONTROLLED setting regardless of HWADDR (as there are some
> devices like bonds that have potentially changing mac addresses) and that
> they would use the ip device name just like you can get it in
> org.freedesktop.NetworkManager.GetDeviceByIpIface

This will not change any soon.

Comment 5 Pavel Šimerda (pavlix) 2012-12-18 15:26:44 UTC

(In reply to comment #2)
> From sysconfig.txt:
> "NM_CONTROLLED=yes|no 
> If set to 'no', NetworkManager will ignore this connection/device."
> So I think that this behavior should be fixed in NM and only if it can't be
> fixed there we should talk about workaround it in initscripts.

AFAIK NetworkManager doesn't handle files without HWADDR at all, I don't think this is a viable solution. Let's wait for Dan's comment on this.

But what Antoni is asking for, is actually not a workaround for a NM bug. He just wants the network scripts to ignore *all* interfaces that NetworkManager manages.

That could happen at any time. You can have conflicting configuration in /etc/sysconfig/network-scripts and /etc/NetworkManager/system-connections, for example.

But there's no NM tool network scripts could ask when NM is not started (yet).

Comment 6 Bill Nottingham 2012-12-18 18:38:35 UTC

Having it changed to ignore all interfaces that NM manages would be a change of behavior that isn't really appropriate for a minor RHEL update, in my opinion.

Comment 7 Antoni Segura Puimedon 2012-12-18 20:42:31 UTC

(In reply to comment #6)
> Having it changed to ignore all interfaces that NM manages would be a change
> of behavior that isn't really appropriate for a minor RHEL update, in my
> opinion.

Well, if it can't be for 6.4, at least I think they should play nice for Fedora 17+ and the future major version of RHEL.

Comment 8 RHEL Program Management 2012-12-24 06:53: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 11 Dan Williams 2013-02-25 23:32:23 UTC

(In reply to comment #7)
> (In reply to comment #6)
> > Having it changed to ignore all interfaces that NM manages would be a change
> > of behavior that isn't really appropriate for a minor RHEL update, in my
> > opinion.
> 
> Well, if it can't be for 6.4, at least I think they should play nice for
> Fedora 17+ and the future major version of RHEL.

Yes, this is likely to be fixed in F19+ and future versions of RHEL.  See bug 824130, which I'm duping this bug to since the fix for both is the same.

*** This bug has been marked as a duplicate of bug 824130 ***