I always thought this behaviour is a historic, undesirable thing. And not easy discoverable.

Also, because you can create a profile in NetworkManager, that sets both the interface-name (DEVICE) and the mac-address (HWADDR), and on next reboot (!!) udev will rename the device.

If you want to rename a device, use .link files or write a udev rule.

We keep this behavior for ifcfg files (and as long as initscripts package is installed), but it's not at all clear to me that NetworkManager should come up with a replacement for that. Just use plain udev, like on non-Fedora/RHEL distros.


Documentation may needs updating, to say that this only applies if initscripts is installed, and the ifcfg file is present. But possibly discourage this approach in general.

Otherwise, I would close as WONTFIX.


What do you think?

(In reply to Thomas Haller from comment #1)
> I always thought this behaviour is a historic, undesirable thing. And not
> easy discoverable.
> 
> Also, because you can create a profile in NetworkManager, that sets both the
> interface-name (DEVICE) and the mac-address (HWADDR), and on next reboot
> (!!) udev will rename the device.

I guess it depends on who you are. The behavior seems nice to me as
the end user because I essentially told the system to do that. Though
I do admit the fact that it only applies on next boot could be
confusing to some, but that is the same behavior as if you create a
.link file or write a udev rule. You'd still reboot to apply the
change.

> 
> If you want to rename a device, use .link files or write a udev rule.

Yep that's one way to do it. Maybe it's better, but in terms of number
of steps it does add an extra step the user has to do.

> 
> We keep this behavior for ifcfg files (and as long as initscripts package is
> installed), but it's not at all clear to me that NetworkManager should come
> up with a replacement for that. Just use plain udev, like on non-Fedora/RHEL
> distros.
> 
> 
> Documentation may needs updating, to say that this only applies if
> initscripts is installed, and the ifcfg file is present. But possibly
> discourage this approach in general.

Definitely +1 for documentation updates depending on what we decide to
do.

> 
> Otherwise, I would close as WONTFIX.
> 
> 
> What do you think?

The only problem I have with choosing to not implement this behavior
is that we've provided this abstraction to the user where they're
using NetworkManager and they don't know what backend files their
configuration is stored in. It just so happens that one backend file
format is not quite equivalent to the other (i.e. corner cases like
this). So if we switch to keyfiles as the backend (like we are
proposing for RHEL CoreOS 4.6 and Fedora 33) things like this
documentation [1] won't work any longer:

```
nmcli connection modify "Wired connection 1" 802-3-ethernet.mac-address "52:54:00:73:59:15"
nmcli connection modify "Wired connection 1" connection.interface-name "external-2"
```

OR

```
nmcli connection add type ethernet mac "52:54:00:73:59:15" ifname "internal-1"
```

which is probably OK, but we should weigh the benefit/reward of
removing the behavior. Some questions to help us answer this are:

- Is it really hard to keep the equivalent functionality?
- Is it really that ugly? Probably :)
- Are there problems that get caused by the functionality existing?
- Are there problems that get caused by the functionality not existing?


Thanks Thomas for the discussion here. 

[1] https://www.thegeekdiary.com/how-to-set-a-custom-interface-name-with-networkmanager-in-centos-rhel-7/

> So if we switch to keyfiles as the backend (like we are
> proposing for RHEL CoreOS 4.6 and Fedora 33) things like this
> documentation [1] won't work any longer:

I am quite surprised that this is actually a documented approach. I don't think that NetworkManager documents this behaviour. Ok, that might be a documentation bug, but given the general ugliness of this thing, we maybe shouldn't officially suggest doing this.

> - Is it really that ugly? Probably :)

I think that's the main point.

We already have good(?) mechanisms for this (a udev rule or a .link file).
In general, NetworkManager is not in the business for renaming interface (/lib/udev/rename_device aside, of course).

NetworkManager provides an API for configuring the network. That is something what a user may want to configure on a regular basis. I feel, changing the interface name is something that does not require an "API" provided by NetworkManager (or tools that use this API). In the best case, the user just uses the predictable naming scheme and doesn't bother. Alternatively, the user does a one-time-configuration step to deploy a udev-rule/link-file (and possibly reload/reboot).

I would very much prefer, we don't keep this unintuitive(?) way that is RHEL/Fedora only.


What do initscripts maintainers think?

In the ideal case we want administrators to use their own names and the naming should be done as easily as possible. Writing a udev rule or link file is not that intuitive as I would like. So if user is used to one style of configuration, having it there as well could be seen as a nice feature.

Sorry, I am really not in favor of this feature.

What is the problem with writing .link files? It seems most users should stick to predictable names so this would be for experts only. Also, you would only do this once at first boot or when you get a new NIC. I don't see the value using NetworkManager's D-Bus API for achieving that -- especially because it works so unintuitive: you create a profile via NetworkManager's D-Bus API (with right DEVICE/HWADDR), and only after next boot the interface gets renamed.

Granted, some users may be aware of this feature and edit ifcfg files by hand. That functionality keeps working (as long as "initscripts" package is installed and provides "rename_device"). I doubt anybody is knowingly accessing this feature via NetworkManager's D-Bus API. AFAIS it is nowhere documented in NetworkManager, nor would I suggest anybody to use NetworkManager as an API for this.


If writing a .link file is too unintuitive(??), I would suggest we add a command line tool to udev that allows to write such special purpose settings. Or extend systemd-API with a way to do this -- of course, systemd/udev already has an "API" for that: it is a file-based API and documented in `man systemd.link` and `man udev`.



I am closing this as WONTFIX. If you really think this should be done, I encourage you to reopen the bug and convince us (for which we are open).

I opened bug 1875485 to deprecate /usr/lib/udev/rename_device.