Re: [gentoo-dev] Re: call for testers: udev predictable network interface names

[Alec Warner]

On Fri, Jan 11, 2013 at 6:11 PM, Steven J. Long
<slong@××××××××××××××××××.uk> wrote:
> Christopher Head wrote:
>> William Hubbs <williamh@g.o> wrote:
>>
>> > There is a way for users to opt out if we default this to on, but I
>> > think the new naming scheme has advantages over the traditional eth*
>> > wlan* etc names.
>>
>> I think it should be taken with a grain of salt. The page mentions how
>> it lets you replace a failed NIC without losing its name. But given a
>> simple computer with just one NIC, if the NIC fails and is replaced
>> (perhaps by a different type of NIC in a different slot, or perhaps an
>> onboard NIC disabled in the BIOS and replaced by an add-in), the name
>> could change, while the kernel’s automatically assigned name will not:
>> eth0 (this also applies to a computer with one Ethernet NIC and one
>> wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki
>> page, even though it applies to a heck of a lot of systems. Perhaps
>> something to include when the Gentoo docs are put together, as part of
>> the balance of reasons to choose one way or the other?
>>
> That's a very good point. For the vast majority of users all these
> "desktop" changes are supposed to help, it's not at all relevant.
> Obviously it's good to have the functionality should you need it, but
> again it appears that simple cases are being made complex, just to allow
> for someone else's complex cases. Which is faulty logic.

I think the wiki page explains the motivations well. They are similar
to the disk changes that were made years ago (porting apps to use
UUIDs to ensure you have the correct disk, even when disk order
changes.) The MAC address is obviously the first UUID one thinks of;
however they talk about why they did not end up choosing the MAC
address as the UUID for network devices.

As an example; I have a server with two ethernet ports. One is onboard
(driverA) and the other is a pci-express card (driverB.) It turns out
driverB doesn't work, but sometimes driverB gets put as eth0. Then the
machine cannot get on the network. We work around this by blacklisting
driverB (so it is never loaded as an ethernet device) but it might be
saner to adopt this new udev and simply configure the network to use
driverA always.

>
> While many packages have default configurations, changing the default
> setup for base system packages in the absence of any configuration is
> not generally a good idea, unless you know for a fact it's not going to
> mess anything up (which is a big ask given that you're distributing
> source.)
>
> Especially given the arguments presented as a motivation, that all this
> has "serious security implications, for example in firewall rules which
> are coded for certain naming schemes, and which are hence very sensitive
> to unpredictable changing names."
>
> If you're certain that every user with a current simple setup, who
> uses the kernel default names, and has such a firewall setup isn't
> going to suddenly find their interface name changed when they reboot,
> fair play to you. If not, allow the admin to opt-in, rather than force
> them to opt-out when something breaks.
>
> That's the usual manner to introduce something new or changed, and for
> good reason. After all, those who are aware of it and interested,
> already know to configure it, or are looking for help to do so. Most
> other users don't care, and don't want the maintenance headache.

I agree it is one way to introduce something new; I wouldn't say it is
the only way (or even the 'usual' way.)

>
> --
> #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
>