Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Scott Schmit]

On Tue, Jan 29, 2013 at 01:58:30PM -0500, Bill Nottingham wrote:
> Tomasz Torcz (tomek at pipebreaker.pl) said: 
> > > It might be worth considering that we keep the one special case and
> > > change the 'eno' prefix in udev to 'em'... this will help some.
> > 
> >   This could be dangerous.  If I understand right, there is not guarantee
> > "em1" would become "eno1" in 100% of cases.  Iptables saved config would
> > still need to be checked and verified.
> 
> It won't, but having it be the same in the case where it *does* have
> the same idea as biosdevname of 'first embedded interface', it could be
> useful to have the same name.

Well, of course.  But in the happy path, everything always works. :)

I know that on my computers, I've only ever had one em1, but a) it's not
clear to me whether my em1's will translate to eno1 or to some enp0s0
name b) I'm not sure that I'm typical.

As they say, the plural of anecdote isn't data.

In the cases where there are multiple em*, some of which will no longer
be considered "embedded" things get nasty.  In the current proposal,
stuff will outright break because there's no match.  With the proposed
compatibility names, things could seem to work at first and only later
is the damage realized.  Example:

Current:
em1 -> enp2s0
em2 -> eno1
em3 -> eno2

Now with compatibility:
em1 -> enp2s0
em2 -> em1
em3 -> em2

Say that em1 is external traffic (hardened rules), em2 is management
traffic (allows ssh/pretty much anything), and em3 is internal traffic
(no ssh, etc).

Sure, there's some breakage here, so they probably won't miss that the
em2's shifted, but it's possible they'll miss a config or two specific
to em2.  This is also a case where keeping the "em" prefix didn't really
help anybody out anyway (and makes it harder to search & replace -- "is
that the old em2 or the new em2?").

If we can be sure that this sort of shifting will be rare, then sure,
keeping em* is helpful.  If we can't, we're creating headaches.  Change
is hard, no matter what, but let's be careful who we're really helping
(the user with only one embedded interface that maybe never notices
anyway or the admin with multiple embedded interfaces for whom the above
scenario is actually worse?).  I don't have data of which is better, but
I thought I'd point the conflict out.


IMHO, the fact that this affects wlan* is going to be more painful.  It
took me some time to re-train my fingers to stop typing eth1 when I
wanted wlan0, but it was really nice knowing on a new laptop which was
which.  (I'm not saying we need to keep wlan0, but prefixing with wl
instead of en might be better.)

I'll admit that GNOME 3 / the installer hide the names now, but when I
upgraded from Fedora 16 to Fedora 17, dhcp4 broke & I had to set up my
network interface manually until I could get the appropriate packages
updated -- knowing which was my wired interface was really helpful then!
(And yes, upgrades don't rename anything. Imagine it was a 19 -> 20
upgrade with the same problem.)

-- 
Scott Schmit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4104 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130131/5a9465fc/attachment.bin>