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

[Steven J. Long]

On Sat, Jan 12, 2013 William Hubbs wrote:
> Steven J. Long wrote:
> > 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.
> >
> > 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."
>
> Isn't this the very definition of the kernel-based names?

Not if you read what Christopher wrote in his reply to you:

> > Christopher Head wrote:
> > > 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.

Amazingly convenient. Anyone would think the kernel devs had gone through this
themselves! ;)

IME that setup describes pretty much every end-user desktop or laptop computer
I've come across, except the *very* occasional analyst with 2 NICs, and users
I don't count as end-users-- in whose name all the awful hackage is supposedly
carried out.

> if you do not
> have a persistent net rules file, you are subject to the kernel's naming
> order, and I have heard of situations in the past when people upgrade
> their kernels, etc, and when they reboot their interface names are
> changed around.

Yes, I've heard of that too, and I'm all for giving them the ability to
set things up exactly how they like, just like I've always been in favour
of an initrd *if* you need it (or are a binary distro.) Granted that's always
meant encrypted rootfs to me, but a bluetooth keyboard is just as valid: it's
the user's choice/system, give them what they need to set it up and run it (and
leave you alone.)

What I'm not in favour of is making the simple cases more difficult, to deal
with the complex ones. It's completely brain-dead thinking.

More importantly, advances in the code don't change the principle:
 you don't break backward compatibility for a default install;
 you don't require people to opt into anything in order to keep their
existing config running, MOST especially if they have not even tweaked anything.
You put out the last version, so if something's not supported in the new one,
you write code to handle the change gracefully, if it's needed.

Or you get a well-earnt basting.

I guess in distro context you have to allow: unless it's a whole new
package, or at worst a major version change. But the principle still
applies, *more* stringently to a coder than a distro packager, irrespective
of how people learning nowadays might carry on.

Or just give up any pretence of caring about your users (and where I come
from, the majority of the pay that you nearly burnt-out to earn, since you
have to cover another 2 or 3 months of remedial work caused by your own
stupidity.)

> > 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.
>
> The following is taken from the wiki:
>
> You basically have three options:
<3 options that all require an admin opt-in to keep their existing
 config running>

There you go: the exact wrong way to do it. As Poettering might say:
"C'mon man, seriously? (whiny voice and pleading looks)"

Honestly, the guy's a complete amateur.
-- 
#friendly-coders -- Where you can unwind when some nub starts throwing
    the word "integration" around.