Red Hat Bugzilla – Bug 1139536
[RFE] Improve handling of DEVICE and HWADDR in nm-connection-editor
Last modified: 2015-11-19 05:57:19 EST
Description of problem: When installing RHEL 7 guest from RHEL 7.0 DVD using all defaults on a RHEL 6 host, after booting up the system eth0 comes up with "ifup eth0" as expected. After applying updates, disabling NM and enabling network, and changing ONBOOT=yes, everything still works ok after reboot. However, if I remove HWADDR line from ifcfg-eth0 (as part of preparation to clone the guest), the device is not activated after next the reboot. It turns out that initscripts expect either HWADDR and/or DEVICE to be present but on RHEL 7.0 in this case after installation we have only HWADDR and NAME=eth0, not DEVICE. On RHEL 5 / RHEL 6 in similar case we had DEVICE=eth0 present but not NAME=eth0. Filing initially againt initscripts to allow Lukáš to provide more insights.
By the way this is a little bit related to this issue. https://bugzilla.redhat.com/show_bug.cgi?id=1087945
There is nothing what we can do in initscripts. Simply we need either DEVICE or HWADDR in configuration file. I think that there are two issues which should be fixed. 1) connection manager should use matching by device by default- 2) sys-virtprep should no create invalid configuration from valid ifcfg file.
(In reply to Lukáš Nykrýn from comment #3) > There is nothing what we can do in initscripts. Simply we need either DEVICE > or HWADDR in configuration file. Yup, could you please re-assign this to the most likely party then, perhaps anaconda or dracut? > 2) sys-virtprep should no create invalid configuration from valid ifcfg file. This happens also without virt-sysprep although most often this is noticed with it. Just use the steps outlined in comment 0 and you can reproduce this without virt-sysprep. Thanks.
> > 2) sys-virtprep should no create invalid configuration from valid ifcfg file. > > This happens also without virt-sysprep although most often this is noticed > with it. Just use the steps outlined in comment 0 and you can reproduce this > without virt-sysprep. If you don't have HWADDR or DEVICE in your ifcfg file, then it is simply invalid configuration. We can't use the NAME variable. That is variable of NetworkManager and it is not specified that it will match the name of the device.
Note that although virt-sysprep is not involved reproducing this, the issue prevent creating clones with working network using virt-sysprep/virt-clone.
The base of the issues is that ifcfg files are used by two systems, legacy initscripts and NetworkManager. And also that there are number of components that creates and modifies ifcfg files. It is not a problem per se. However, they should play in concert. As said initscrips needs one of HWADDR or DEVICE to match the device. But it seems that dracut/anaconda puts one of them in the file. https://bugzilla.redhat.com/show_bug.cgi?id=1040461#c15 And it seems that they will switch (switched) from HWADDR to DEVICE (interface names should be stable now). So if some script edits an ifcfg file and wants it to be usable by initscripts it has to retain the HWADDR, or DEVICE. Because traditionally there's one ifcfg file per device and the matching is done by the variables. NetworkManager extends this a bit (because it handles ifcfg as connection profiles) and allows missing HWADDR and DEVICE. In that case the file is applicable to any matching device (e.g. Ethernet). What could be done on NM side to improve the situation is: * consider whether the generic NM profiles (without specific MAC and device name) shouldn't be written rather to /etc/NetworkManager/system-connections instead of ifcfg * enhance nm-connection-editor to be able to create files only with DEVICE. Now, if it "bind" the file, it uses HWADDR. However, the root cause here is that a script removes a piece of information from ifcfg file and makes it invalid.
The original issue was caused by incorrect modification of ifcfg files, so not a bug. However, I change the bugzilla to a RFE for potential improvements mentioned in comment #9.
(In reply to Jirka Klimes from comment #9) > What could be done on NM side to improve the situation is: > * enhance nm-connection-editor to be able to create files only with DEVICE. > Added the UI to nm-connection-editor to be able to set interface name. See upstream branch jk/editor-interface-name-rh1139536.
In nmtui, I made interface name and hwaddr be a single widget. I never implemented the pop-up part of it, so for now it's just an entry that accepts either an ifname or a MAC address. When displaying an existing connection, if it has an interface-name or mac-address that refers to a known device, then it will show the other datum in parentheses (ie, something like "enp0s25 (f0:de:f1:9b:15:37)" if interface-name is set, or "f0:de:f1:9b:15:37 (enp0s25)" if mac-address is set, just like the nm-c-e combo boxes). I don't remember if it tries to deal with connections that have both interface-name and mac-address set... that didn't seem like a very useful use case anyway. Anyway, I'm biased, but I think this makes more sense than having them be separate (especially since the MAC combo shows interface names as well). >+static GType >+get_device_type (CEPageGeneral *self) libnm has nm_device_get_setting_type(), which is basically the opposite of this. I wonder if we could add nm_setting_get_device_type()? That wouldn't have been possible in libnm-util/libnm-glib, but maybe we can make it work in libnm? (The biggest problem is that nm_device_wifi_get_type() wouldn't be resolvable at link time in the daemon, since that would be from a plugin...)
(In reply to Dan Winship from comment #13) > In nmtui, I made interface name and hwaddr be a single widget. I never > implemented the pop-up part of it, so for now it's just an entry that > accepts either an ifname or a MAC address. When displaying an existing > connection, if it has an interface-name or mac-address that refers to a > known device, then it will show the other datum in parentheses (ie, > something like "enp0s25 (f0:de:f1:9b:15:37)" if interface-name is set, or > "f0:de:f1:9b:15:37 (enp0s25)" if mac-address is set, just like the nm-c-e > combo boxes). > > I don't remember if it tries to deal with connections that have both > interface-name and mac-address set... that didn't seem like a very useful > use case anyway. > > Anyway, I'm biased, but I think this makes more sense than having them be > separate (especially since the MAC combo shows interface names as well). > I renamed "Device MAC Address:" combo boxes to "Device:" and it now allows: enps025 f0:de:f1:9b:15:37 enp0s25 (f0:de:f1:9b:15:37) f0:de:f1:9b:15:37 (enp0s25) So, either both interface name and MAC address can be set, or just one of them, or none. > >+static GType > >+get_device_type (CEPageGeneral *self) > > libnm has nm_device_get_setting_type(), which is basically the opposite of > this. I wonder if we could add nm_setting_get_device_type()? That wouldn't > have been possible in libnm-util/libnm-glib, but maybe we can make it work > in libnm? (The biggest problem is that nm_device_wifi_get_type() wouldn't be > resolvable at link time in the daemon, since that would be from a plugin...) The function is not needed any more after the rework, because the code is now in particular pages, not the general one. The upstream branch jk/editor-interface-name-rh1139536 has been re-pushed.
page-wifi.c: In function ‘validate’: page-wifi.c:540:49: error: ‘bssid’ may be used uninitialized in this function [-Werror=maybe-uninitialized] NM_SETTING_WIRELESS_BSSID, bssid && *bssid ? bssid : NULL, ^ page-wifi.c:495:14: note: ‘bssid’ was declared here const char *bssid; ^ Rest looks OK to me.
(In reply to Dan Williams from comment #15) > page-wifi.c: In function ‘validate’: > page-wifi.c:540:49: error: ‘bssid’ may be used uninitialized in this > function [-Werror=maybe-uninitialized] > NM_SETTING_WIRELESS_BSSID, bssid && *bssid ? bssid : NULL, > ^ > page-wifi.c:495:14: note: ‘bssid’ was declared here > const char *bssid; > ^ Fixed. > > Rest looks OK to me. Committed to upstream master as 2861681 editor: let users edit connection.interface-name property (rh #1139536)
(In reply to Jirka Klimes from comment #16) > > Committed to upstream master as > 2861681 editor: let users edit connection.interface-name property (rh > #1139536) Backported to nma-1-0: a0b0166 editor: let users edit connection.interface-name property (rh #1139536)
> * enhance nm-connection-editor to be able to create files only with DEVICE. > Now, if it "bind" the file, it uses HWADDR. Using nm-connection-editor from nm-connection-editor-1.0.6-1.el7.x86_64 I can create configuration just with DEVICE: TYPE=Ethernet BOOTPROTO=dhcp DEFROUTE=yes PEERDNS=yes PEERROUTES=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no IPV6_PRIVACY=no NAME="Ethernet connection 1" UUID=8556c4fc-a9d2-460d-bbe1-aeacb173164b DEVICE=eth0 ONBOOT=yes
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/RHSA-2015-2315.html