Bug#815534: systemd: should migrate config from /etc/udev/rules.d/70-persistent-net.rules

[Russell Coker]

On Mon, 22 Feb 2016 07:00:01 PM Martin Pitt wrote:
> > To preserve the functionality of systems where the sysadmin deliberately
> > named interfaces as well as systems where the sysadmin just configured
> > things to work with the defaults that udev put in
> > 70-persistent-net.rules I think that the upgrade of systemd should at
> > least give the option of creating /etc/systemd/network/*.link files for
> > the user.
> 
> That seems rather complicated, in some cases not possible (udev rules
> can match on more attributes than *.link files), and rather error
> prone IMHO.

While it won't always be easy/possible I think that the vast majority of 
installations will match on the MAC as that is the easiest modification of 
rules that are automatically added.

If it offered to generate link files for the easy cases that would be a 
significant benefit to many users.

> I think it's much safer to keep the originally created
> 70-persistent-net.rules on upgrades, as only this guarantees that
> after the upgrade the network names are exactly the same as before the
> upgrade.

Currently that doesn't seem to be happening.  If it had worked that way I 
probably wouldn't even have noticed the change.

> The suggestion to remove it and update your firewall config etc. is
> done because the persistent naming schema used the same namespace as
> the kernel, and thus is inherently racy and broken. The mechanism
> (udev rule vs. *.link file) is irrelevant there, i. e. converting to
> link files would not gain anything.

That is only for people who had names that match kernel names.  As I don't 
assign names like eth0 to devices on my systems this hasn't been a problem for 
me.

> So, my questions: What do you want achieved with that conversion? Why
> is that severity "important"?

I had a system stop responding to pings over the weekend.  When I had it 
rebooted it didn't talk to the Internet.  I had to visit it to discover that 
the ethernet device had a new name which is why rebooting it didn't bring it 
back from whatever problem it had.

Unexpected device renames cause significant inconvenience when servers are in 
locations that are difficult to access.  It is very important that devices which 
are only accessed over the Internet stay connected.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/