Hide Forgot
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).
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
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.
(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.
(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).
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.
(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.
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.
(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 ***