[systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

Thank you Andrei and Reindl for your answers.

Let's stick to the facts for the moment or as much of it as we can.



Martin Pitt schreef op 10-04-16 10:17:

> There are very good reasons for having a mechanism for stable names by
> default. Most importantly, to keep your machine actually
> booting/working .. when names suddenly move around and your server is
> suddenly not online any more, or your firewall silently stops working,
> this is a tad bad. :-)

The fact is that not having this as a default would require a very small
percentage of users to have to configure static ethX names, and the fact
is that if they did not do this, they would land in trouble. The fact is
also that these users need to configure their firewall and from my
experience this is a much more challenging endeavour, or at least, is a
task that requires some thinking and takes some time. The actual time
spent on mapping the interfaces would be abysmally small in comparison.
So much so as to make it negligible from the viewpoint of effort required.

As Reindl Harald says: you have to configure them anyways, even if you
had a ready-made firewall, you would still need to configure which
device is going to fit which role or which zone or whatever.

So zero-configuration from the viewpoint of a functioning system is a
lie in this case anyway. There might be DHCP on one of the nics giving
it automatic address and perhaps a route to the internet, but other than
this nothing would happen to that if those device names would swap
either. So in the old system, the system DID work out of the box given
what a fresly installed system is capable of.

That means that by default and in all cases the system worked out of the
box given a default non-configured firewall and aspects surrounding it.

It is only when you *would* configure a firewall or advanced routing
between NICs that this ethX scheme would no longer function correctly
out of the box. Perhaps while theoretically it would be preferable to
have the least amount of configuration required for any system,
currently you ARE trading configuration in one area for configuration in
another. It is MY opinion that this tradeoff has increased the overall
cost to all users combined. All of these are facts, including the last
part where I state that it is my opinion.

At the same time, I did propose a mechanism in which your current system
would map onto meaningful and consistent and predictable names, but you
did not respond to that suggestion.

Meanwhile I was not fully aware of how unpredictable the names are. My
current NIC is "enp3s0". I have no clue (I honestly don't remember) what
it was on other systems. I do know that the wlan name was readily
incomprehensible or could have been incomprensible.

So again, the fact is: you are saving an abysmally small amount of
configuration time for a very small subset of users that need to
configure their system anyway in a larger extent than what you have
saved them, by far.

Whether that is a fair tradeoff is up for debate and what this thread is
about.


>> "Finally, many distributions support renaming interfaces to user-chosen
>> names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or
>> physical locations as part of their networking scripts. This is a very
>> good choice but does have the problem that it implies that the user is
>> willing and capable of choosing and assigning these names."
> 
> This isn't true -- having the option of customizing the names doesn't
> mean that you *have* to do it. That's precisely why we must provide
> some schema for stable names by default -- because the majority of
> users does not care and should not *have* to care.

That text came from the freedesktop website. That was official systemd
parlance. And in fact, but I do not know: I think the majority of users
do care or would care if you gave them the choice.

Most people actually do like nice and pleasant names in their system,
but whether they care enough to actually go and change it based on
current difficulties in doing so depends entire on how easy it is to do
that.

You say:

"That's precisely why we must provide some schema for stable names by
default -- because the majority of users does not care and should not
*have* to care."

Most people would care less about stable names because to those people
the old names were already stable. So indeed, they should not have to
care, because they didn't and still don't for that matter. They don't
care about stable names.

That's like caring about whether your country code number will change.
People don't care, because it will never change like that.

Regular phone numbers might change and people care about its stability,
yes. Sometimes they care about the numbers looking nice. They care about
stability because number changes are an issue to most people. They care
less about having pretty numbers because in a general sense they do not
remember phone numbers and the ones that do care are usually companies,
because for them it pays to invest in a pretty number.

On the subject of interface (device) names, people who were never at
risk of seeing changing names, do not care about it. They did not gain
anything. They did lose something, which is the ability to remember this
name.

Just yesterday - and the reason I am writing this today - there was
another user on some ubuntu IRC channel who said:

"that's would be better
because my wlan0 new name is like wlx00259c96cafb"

There you have a real user who just got introduced to this scheme
(because he upgraded to 16.04 having skipped 15.04/15.10).

So on the topic of caring, I think you can very confidently state that:

- most users do not care about this stability you have gotten them
- most users when asked would probably say that they like the new
  naming scheme less

You wanted to know about caring, this is caring for you. People do not
care about the advancements you have made.

For most people they are detriments, because even if you can attest that
the benefits of pretty names are small, the benefits of this stability
are zero.

Zero.

By definition, any amount of caring will be greater than that.

PEOPLE DO NOT CARE about what you've "given" them.

They don't care. They don't care about this stability. At all.

They just don't care about it. They did not ask for it (even if they
could have been asking for it) and they probably didn't want it, and now
that they have it, it doesn't mean that they like it just because they
are not vocally submitting bug reports about it.

You say people do not care about those interface names. They care less
about this new stability. Much less.

Because it doesn't affect them.

Now any user who does need to write a firewall suddenly does care.
Any user who does need to use ifup/ifdown now and then, does care.
Any user who does need to write NetworkManager scripts depending on
interface, does care.

My script stopped working from one host to the next because the names
were not the same. The script depended on wlan0. I needed to change it
to whatever.

> This isn't true -- having the option of customizing the names doesn't
> mean that you *have* to do it. That's precisely why we must provide
> some schema for stable names by default -- because the majority of
> users does not care and should not *have* to care.

No, those stable names provide no benefit to the class of users you
describe.

You are creating a logical fallacy for yourself:

1. The people who benefit from stable names are those likely to care
2. Those who care would be ones to think about some mapping
3. Manual mapping would not be an issue for those who care about stable
   names.

Whereas you say that the stable names are required for people who do not
care or should not care.

These are two disjunct groups of users.

A. People who have no need for stability and do not configure their
   system
B. People who have a need for stability and already configure their
   systems.

Now you are creating this situation:

C. People who have a need for stability do not need to configure their
   system
D. People who have no need for stability, may need to do it regardless
   (or may want to do it regardless) because to them the change has been
   detrimental.


But group C does not exist because they need to configure their systems
anyway.

You can dream of group C but they are irrelevant because the system does
not exist that benefits from this stability and yet needs no configuration.





>> What is really the amount of systems or proportion thereof that have
>> multiple NICs?
> 
> I actually think "most" (at least an ethernet and a wifi card), but
> this question is also fairly irrelenvant -- even if it's just 5% we
> still want those to function correctly.

You can say that you want that, but this question was about what people
want. This question was about dissecting the two quite disjunct groups
of people with very different requirements (as per this scenario and
topic) and different levels of skill and different needs in configuring
their systems, and then seeing if the current default is actually a fair
thing.

If there is only 0.001% that benefit at a cost to 99.999% of people
(just exaggerating, perhaps) then you might still say that is irrelevant
because you want it, but why is what you want so important? Shouldn't it
be about fairness for users?

You try to downplay the cost to the average user saying that average
user does not care about presentation and manual usability of a network
interface name. That that average user would never want to write any
script. Or manually configure an interface. That the average user also
does not care about seeing something recognisable and understandable,
which also helps in learning about the system and learning about Linux
--- because these new names..... they do not lead to understanding,
familiarity or knowledge.

They make it harder to get to know the system as well.

So what I am saying is that the practical advantage, no matter how
noble, of a multi-NIC system that never gets in trouble... is indeed
irrelevant or at least insignificant, considering that to those people
that do get in trouble, the cost of fixing it is abysmally small.

Yes it is a noble cause. No it does not matter in the grand scheme of
things. Yes it would be helpful if this issue was solved for real. No
the current solution does not improve the lives of people.

For most people it worsens it. Even if they are not affected by it to
any large degree, since the advantages are none, any amount of detriment
will be felt.

People do not like it, how hard is that to understand.

Mr. Lennart Poettering himself has once uttered the words akin to
"achieving the right technical solution in opposition to political
objections". Such "dislike" is exactly what would be qualified in this
case as "political objection". People dislike it, but we ignore them,
because we know what's best for them.


So you have three issues here:

1. The burden of configuring the system is now placed on users that do
not need any advanced configuration. You say that they don't need to.
You say that they don't care about it. But have you asked users? Have
you done research? Have you put up questionaires? Have you asked
questions such as "If it was easy to revert to the old scheme, would you
do it?". Have you actually been *interested* in their opinions?

2. A non-configured system (as per configuration of firewall and routing
roles) does not benefit from this stability. Only a configured system
(most usually, manually) will benefit from the newfound stability.

3. The burden of fixing the issue for users that did need it, was not great.



>> Any user running a system with multiple NICs should be willing and
>> capable of choosing and assigning these names.
> 
> To be frank, this is the attitude of the 90's when you had to sit down
> with a thick book and spend a week until your Linux system was up and
> running.

But again that user with multiple NICs needs to configure anyway, and
like Andrei said, this particular thing worked for most users.

> If a user wants to customize the names, nothing stops them, and it's
> well-documented how to do that. But that doesn't mean that we aren't
> responsible for being correct and safe by default.

So who is paying you? Whom are you doing it for?

What person is going to hold you responsible?

What person requires this kind of sacrifice to the system?

Why is it not an issue if the user wants to customize the names (I have
told you why it is not easy or pleasant) -- but at the same time it is
an issue if the system maintainer NEEDS to configure it to have a stable
system?

Nothing was stopping that system maintainer either.

I agree that having this randomness is not nice. But fixing it no matter
the cost, is not nice either. You say there is no cost. There is.

You can only maintain this by downplaying the cost.

And like Andrei said, the names are not predictable.

That in itself is a cost --- of changing scripts, and making it
impossible to remember the names.

It is *NOT* easy to customize the names the way it is now, even if you
could do it in 10 minutes, you first have to go online to search for it,
then you need to find either MAC address or PCI location (apparently)
and then you need to write a config file for every interface, there are
no example files on disk in that directory, the only one that is
available doesn't help, and you depend on the man page entirely, but no
user is going to know about "systemd.network" so will have to try to
find it online.

You can say stuff about "udev properties" but this is incomprehensible.
I do not even know how to find the persisent path.

I have no freaking clue. I could look it up online, but I'm trying by
myself. I have no clue. "enp3s0" is not a /dev/ device name. Ifconfig
does not show anything useful. lspci might provide something I can use
to construct it, but I'm not sure. "dmesg | grep enp3s0" confirms this,
but I still need to manually construct the entire string.

In my KInfoCenter the information is not shown either - MAC address is,
but not PCI path.

So I look online and find "udevadm info" -- but like I said, I don't
know the device name to use. I execute "find /sys | grep enp3s0" and
discover "/sys/devices/pci0000:00/0000:00:0a.0/0000:03:00.0/net/enp3s0".

I also discover "/sys/class/net/enp3s0". Okay, finally. Now I can do
"udevadm info /sys/class/net/emp3s0" and then finally there is my
pci..... string.

That took a while for a new user.

First without prior knowledge it is impossible to know how to do "man
systemd.link" to find the info.

Then without much knowledge it is easy to find udevadm info. But. What
about the device path. You need to find it using find and grep.

You say it is easy to customize. It is not. If you have all the
knowledge, yes.

But what makes a system user-unfriendly is requiring lots of knowledge.

So no I do not consider it well documented, or at least I could not find it.

Meanwhile I don't even need it because I can turn the thing off.
However, that is only documented online as far as I know.



> From my POV of a desktop-oriented developer and distro engineer who
> sees a lot of bug reports -- "most users" don't care. It's totally
> irrelevant on a desktop where the network is usually configured
> dynamically (NetworkManager) and it's mostly irrelevant for virtual
> environments which most of the time only have one network card which
> the OS installer sets up by default. It is highly relevant for
> embedded setups (think RasPi board) and servers with multiple NICs,
> and there a location-based naming matches people's intuition a lot
> better than the old MAC-based enumeration from
> persistent-net-generator.

You are still talking about some minority. I consider myself a pretty
proficient computer user. I do not know what enp3s0 means. Some of the
wlan names are much worse. I'm a desktop user and it is not irrelevant
for me.

*Currently* I am not doing any scripting or advanced stuff which means
that indeed I have not yet saw fit to rename it (turn it off) -- not
because I didn't want to, but because of the effort required.

NetworkManager has been buggy and I have had to resort to manual
wpa_supplicant as well on a prior laptop.

Even if it had no practical implications to date on this here system
(just a regular desktop in a home LAN) I still wanted to change it, I
still wanted to undo it.

For instance, when I changed the DHCP server on my network, I have had
to manually configure my interface. Now NetworkManager got in the way so
I had to do it through NM regardless, but it would have been a lot more
pleasant if it had been eth0.

Scripts I write are more portable if this renaming is turned off.

So I'm a bit of a "under the hood" person. The moment you take a single
step under the hood, it becomes relevant.

The moment you edit your connection per the NM applet, it becomes
relevant. (The name is shown there and it is incomprehensible).

You try to keep people from diving under the hood but this is not the
reality of a Linux system.

In Windows it is equally absurd that you have to write "Local Area
Network Connection 1" or something similar to use the command line tools.

And then in a different language version your script won't work because
the names have been localized.

"a location-based naming matches people's intuition a lot better than
the old MAC-based enumeration from persistent-net-generator"

There is probably no difference between what you do now, and using those
PCI addresses.

enp3s0 and emp3s1 and not going to be more intuitive than eth0 and eth1,
if someone can count on those names. Yup the names will stay the same
even if you take the first card out. Then enable it for those kinds of
people, not for everyone.


>> So we may have 5% or less of all systemd/linux networking users that
>> actually requires this.
>> The 5% or less that does require it is not the type of user that would
>> not be able to adjust the naming scheme.
> 
> That's a rather strong assumption, and IMHO it's unnecessary to make.

First you say it is easy to change it if you want it. Then you say it is
a strong assumption to say that multiple-NIC people will not have a hard
time doing it. Which is it gonna be?

When it's the people you don't care about, it is easy, but when it is
the people you do care about, it is hard?

Seems a rather flexible proposition, this.


>> Now you are causing 95% of users that really need to turn it off.
> 
> This is not true, and a dangerous piece of advice to give to anybody.

First of all, it is not dangerous. Practically no one requires the
stability you espouse. Second of all, it was not advice. If you read it
as advice, it means you have a stake in users not being informed about
certain things, or not getting certain ideas that you think would be bad
for them. That's a bit the same thing as keeping people from "dangerous
ideas" (forbidden books etc). In practice, it means you are going to
censor certain thoughts or ideas, because they would cause people to
choose differently.

To any user who comes into the chat channels to complain about the new
names, I advise them to turn it off. According to you, that would be
dangerous. Yet there is no danger involved at all. They do not have
multiple NICs and do not run important firewalls where important roles
are defined in a business setting, where people run important junction
points in important networks where nothing may go wrong, while at the
same time having no network administrator skills at all.

You seem to be protecting a certain kind of business where a certain
kind of failure would be disastrous, and want to prevent any kind of
mistake happening in that kind of environment at all costs.

You want to prevent the situation where a system administrator forgets
to make the change after having installed a new Linux system, configures
his router or firewall and then ends up seeing disaster strike. In this
situation, you judge the convenience cost to regular users to be
irrelevant as to compared to the cost to a real "business" that would be
impacted by say a data breach.

Now someone is going to be looking for the one responsible, and you
don't want it to be you.

I mean, that's not lacking of sympathy ;-).


>> At the very least create a configuration file where this is a simple
>> named option. And then, at the very least, don't turn it on by default.
> 
> All of this is very easy to configure.

The point to begin with is that you need to know the name of
"./udev/rules.d/80-net-setup-link.rules" and I am not even sure if it is
the correct one - the name changed between systemd versions.

Creating symlinks to /dev/null, putting stuff into a file you don't know
what, or changing kernel parameters, all do not fall within the bounds
of "easy to configure".

Basically, it requires anyone that wants to do this, to search for it on
the internet. And that might not even be easy to find for a casual user.
It's not "easy to configure".

At the very least distributions could prompt the choice to users - with
full information, and not lies - and then see how many users would
choose the new scheme.

As it stands users are usually misinformed about security.

Granted, if it actually *was* easy to turn off, it wouldn't be so much
of an issue. But this depends on installation environments and GUI
options, as well as not lying about the security risks.

It is rare that a desktop OS would require the feature at all, but who
knows.

Personally? If I were to install Ubuntu or Kubuntu.

I would want the system to be turned on, and then have the names mapped
to "ethernet0" and "wireless0".

That would be my preference. That is what I would like. It is more
comprehensible than the old names. However, for the system to configure
this by default: the names are not predictable!!!!.

The installer would need to load a system where this renaming already
happens, find the network interfaces, acquire their PCI bus IDs, then
create a scheme for their mappings, and then put the configuration files
for that in /etc/systemd/network.

Then you would have a proper mapping by default, that is not as stable
(if you actually remove a NIC) but it is stable as long as you keep the
same amount of NICs available.

Apparently this system was already in place and could have been used.

This solves the security risk for the largest part, except for the fact
that to those with the knowhow to discern, it is not actually
"predictable". But why should it be.


> In the end, the root cause of this is that Linux' handling of network
> devices is so completely different than just about every other device.
> For the latter (nodes in /dev) we can easily have aliases so that we
> can provide suitable names for every use case (by-serial, by-uuid,
> by-label, etc.), but this is impossible with network devices
> unfortunately. So there simply is no naming schema that fits
> everybody's needs, and every default that we pick will have to be
> changed in some circumstance. But I believe that the current one is a
> fairly safe, reasonable, and most importantly, *working* default, at
> the price of having to adjust to slighly "odd" names.

There is simply no naming schema that fits everyone's needs, so you pick
the one that suits the 5%.

"Every default we pick will have to be changed in some circumstance" --
I am glad you attest to that.

Then limit the amount of times those circumstances occur?

You have caused the majority of users to pay the price and the cost for
a minority of users in which a certain "oops, forgot to configure" could
be disastrous according to that business running that server, and not
even that, but according to a certain perspective, a disaster could happen.

One man's death is another man's bread, but apart from that.

You (or the ones designing it) seem to have done a risk analysis. Risk
is defined as chance of something happening times the cost if it did happen.

So a cost of $10 with a risk of 100% for a billion users would amount to
a cost of $10b anually, so to speak.

A cost of $10b with a risk of 0.5% for a single user would amount to a
cost of $50m anually, and if you make that 200 users, the number is the
same.

And it is really only meant to catch the scenario where an important
computer with multiple interfaces (e.g. a kind of router, usually) has
not received this necessary change, and now the reboot causes the entire
system to fail, but it might fail in a way you do not notice.

And for this you have caused all Linux systems to have changed,
incomprehensible, and hard to use/understand/remember interface names.

And the question has been whether that is a good trade-off, and whether
a better trade-off would not be possible.