Bug 1139536

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