Hide Forgot
Setting "NM_CONTROLLED" now works correctly across all the `ifcfg-*` files When the "NM_CONTROLLED=no" parameter was set for an interface in its `ifcfg-*` file, other interfaces in some cases inherited this configuration. This behaviour prevented the *NetworkManager* daemon from controlling these interfaces. The issue has now been resolved, and setting the "NM_CONTROLLED" parameter now works correctly across all the `ifcfg-*` files. As a result, the user can choose which interface is controlled by *NetworkManager*, and which is not.
Description of problem: (Actually found on CentOS 7, but I have no idea if that is the right place to report it or not) /etc/init.d/network loops over all interfaces on line 86, on line 87 it unsets some environment variables: unset DEVICE TYPE SLAVE However the following environment variables are set: eval $(LANG=C grep -F "DEVICE=" ifcfg-$i) eval $(LANG=C grep -F "TYPE=" ifcfg-$i) eval $(LANG=C grep -F "SLAVE=" ifcfg-$i) eval $(LANG=C grep -F "NM_CONTROLLED=" ifcfg-$i) If you have an eth0 that sets NM_CONTROLLED to "no", and an eth1 that doesn't set NM_CONTROLLED at all, then NM_CONTROLLED will still be set to "no". This means that all interfaces after the first one (ordered lexically) are going to not be controlled by NetworkManager... I was dealing with some other issues, so I may or may not have actually hit a bug because of this, but figured I'd report it anyway. Recommendation: add NM_CONTROLLED to be unset as well.
Thanks for report. Fixed in upstream https://git.fedorahosted.org/cgit/initscripts.git/commit/ We will include it in some future version of initscripts for rhel/centos7 Of course as a workaround you can explicitly set NM_CONTROLLED=yes for the other devices.
Argh, here is the correct link to upstream https://git.fedorahosted.org/cgit/initscripts.git/commit/?id=db3e951ab5333a003cfd8276437fb00a71fae334
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://access.redhat.com/errata/RHBA-2017:2286