Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames

[Xen]

Reindl Harald schreef op 14-04-16 12:02:
> 
> 
> Am 14.04.2016 um 11:45 schrieb Jetchko Jekov:
>> On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald >  > can iterate over.
>>  >
>>  > $ ip -o a | awk '{print $2}' | uniq
>>
>> blub - gives a (incomplete) list of the current interfaces - so
>> what is
>> the advantage you wnated to demonstrate?
>>
>> wrong
>> that gives you  *configured IP addresses* on interfaces. if there are
>> interfaces without addresses obviously they wont be listed ...
> 
> don't tell me what something gives when you have the input and output
> even in your quoted mail

You realize this guy is doing the same thing to you that you've done to me?

He is going to come up with reasons why what you say is not true, and
even if you say "I have to pick my apples in fall because they are ripe"
he is going to suggest deep freezing the entire orchard so you can pluck
them in winter ;-)".

"ip -o a" does not agree with any purpose I had in using ifconfig here
and shows much less info.

That's like suggesting me to use an oven because ovens are better than
pans, even if I was trying to fry something and not bake.

Anyway thanks for responding to this.

If there is anything I hate it is people who are only concerned with
what is "better" instead of what is more useful. Or more suited to the
task at hand. Or whatever.

> 
>> for list of interfaces command is
>> ip [-o] l[ink] [show]
>>
>> and I would point out that output of ifconfig wont give you complete
>> list of interfaces as opposed to ip link show
>>
>> [root@rh:~]$ ip -o a | awk '{print $2}' | uniq
>> lo
>> vmnet8
>> br-lan
>>
>> [root@rh:~]$ ifconfig | grep mtu
>> bond0: flags=5187  mtu 1472
>> br-lan: flags=4163  mtu 1472
>> eth0: flags=6211  mtu 1472
>> eth1: flags=6211  mtu 1472
>> lo: flags=73  mtu 65536
>> vmnet8: flags=4163  mtu 1500
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames

[Reindl Harald]

Am 14.04.2016 um 11:45 schrieb Jetchko Jekov:

On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald  can iterate over.
 >
 > $ ip -o a | awk '{print $2}' | uniq

blub - gives a (incomplete) list of the current interfaces - so what is
the advantage you wnated to demonstrate?

wrong
that gives you  *configured IP addresses* on interfaces. if there are
interfaces without addresses obviously they wont be listed ...


don't tell me what something gives when you have the input and output 
even in your quoted mail



for list of interfaces command is
ip [-o] l[ink] [show]

and I would point out that output of ifconfig wont give you complete
list of interfaces as opposed to ip link show

[root@rh:~]$ ip -o a | awk '{print $2}' | uniq
lo
vmnet8
br-lan

[root@rh:~]$ ifconfig | grep mtu
bond0: flags=5187  mtu 1472
br-lan: flags=4163  mtu 1472
eth0: flags=6211  mtu 1472
eth1: flags=6211  mtu 1472
lo: flags=73  mtu 65536
vmnet8: flags=4163  mtu 1500




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames

[Jetchko Jekov]

On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald 
wrote:

>
>
> Am 13.04.2016 um 18:51 schrieb Sam Tresler:
> > I didn't make it through the rest of your post, but thought I'd chime in
> > with `ifconfig` has been deprecated since 2009.
> >
> > 2009. I don't get deep into the distros, but I really wish they'd stop
> > shipping it.
> >
> > `man ip` should give you info on the right tool you need to retrieve
> > your network info. From there it is just some pipework to get a list you
> > can iterate over.
> >
> > $ ip -o a | awk '{print $2}' | uniq
>
> blub - gives a (incomplete) list of the current interfaces - so what is
> the advantage you wnated to demonstrate?
>
> wrong
that gives you  *configured IP addresses* on interfaces. if there are
interfaces without addresses obviously they wont be listed ...

for list of interfaces command is
ip [-o] l[ink] [show]

and I would point out that output of ifconfig wont give you complete list
of interfaces as opposed to ip link show

[root@rh:~]$ ip -o a | awk '{print $2}' | uniq
> lo
> vmnet8
> br-lan
>
> [root@rh:~]$ ifconfig | grep mtu
> bond0: flags=5187  mtu 1472
> br-lan: flags=4163  mtu 1472
> eth0: flags=6211  mtu 1472
> eth1: flags=6211  mtu 1472
> lo: flags=73  mtu 65536
> vmnet8: flags=4163  mtu 1500
>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames

[Reindl Harald]

Am 13.04.2016 um 18:51 schrieb Sam Tresler:

I didn't make it through the rest of your post, but thought I'd chime in
with `ifconfig` has been deprecated since 2009.

2009. I don't get deep into the distros, but I really wish they'd stop
shipping it.

`man ip` should give you info on the right tool you need to retrieve
your network info. From there it is just some pipework to get a list you
can iterate over.

$ ip -o a | awk '{print $2}' | uniq


blub - gives a (incomplete) list of the current interfaces - so what is 
the advantage you wnated to demonstrate?


[root@rh:~]$ ip -o a | awk '{print $2}' | uniq
lo
vmnet8
br-lan

[root@rh:~]$ ifconfig | grep mtu
bond0: flags=5187  mtu 1472
br-lan: flags=4163  mtu 1472
eth0: flags=6211  mtu 1472
eth1: flags=6211  mtu 1472
lo: flags=73  mtu 65536
vmnet8: flags=4163  mtu 1500



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] on the default for, PredictableNetworkInterfaceNames

[Sam Tresler]

>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.


I didn't make it through the rest of your post, but thought I'd chime in 
with `ifconfig` has been deprecated since 2009.


2009. I don't get deep into the distros, but I really wish they'd stop 
shipping it.


`man ip` should give you info on the right tool you need to retrieve 
your network info. From there it is just some pipework to get a list you 
can iterate over.


$ ip -o a | awk '{print $2}' | uniq




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

Greg KH schreef op 11-04-16 22:19:

>> My device is enp3s0, which implies 3rd bus number, which it indeed is:
>>
>> E: ID_PATH=pci-:03:00.0
>>
>> Are you telling me there are systems where this is not guaranteed to be
>> stable?
> 
> Yes, including your own.

So biosdev is not guaranteed to be stable either.

> 
>> Maybe these two numbers are coincidentally the same and not
>> related. It's an onboard chip (as most) and so not really geograpically
>> located.
> 
> Put a new PCI device in your system, or boot it in a docking station, or
> plug in some thunderbolt devices before booting and then look at this
> number.

This is my system:

01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT
640] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller
(rev a1)
02:00.0 Parallel controller: Oxford Semiconductor Ltd Device c100
02:00.1 Serial controller: Oxford Semiconductor Ltd Device c101
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
04:06.0 Multimedia audio controller: C-Media Electronics Inc
CMI8738/CMI8768 PCI Audio (rev 10)
04:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link)

01, 02 and 04 are physical cards. In this list, only 03 is not physical.
It seems obvious that this would change if I changed anything, but. Well
that makes writing configuration files based on it troublesome to begin
with.

For instance this might mean that if I remove the com/lpt card, my
ethernet interface name will change (it might change from enp3s0 to enp2s0).

I have no thunderbolt/docking station here, but that would be even
worse. I thought you people said the current system would be very stable.


> But, it's the best that the system can do, as obviously your bios does
> not provide a slot name for the PCI device, otherwise the naming scheme
> would have picked that.

Name or number? I only see a provision for slot numbers.

If indeed adding devices would change all of this then there is no
reason at all to stick with the current naming scheme over something a
little simpler.

> Go file a bug for your laptop manufacturer to properly provide the
> needed PCI slot number, and then your id will not change.

Actually it is a regular motherboard but I will put this to the test.

>> In all of the examples though, this is not a coincidence and these
>> numbers are identical. This PCI path is used for the biosdev name.
>>
>> You are saying it is not stable?
> 
> Yes, see above.

So there goes all that effort..


> The naming scheme starts with the most stable thing it can find and
> works downward.  PCI ids are usually "good enough" for almost everyone,
> like you are seeing on your system.  But they do change, which is why
> most sane BIOSes provide PCI slot information, as those correspond
> directly to the hardware location in the system.

If the ethernet name does change if I take out a non-related card, it is
much worse than in the old system.

I will check, thanks.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Greg KH]

On Mon, Apr 11, 2016 at 07:59:30PM +0200, Xen wrote:
> Greg KH schreef op 11-04-16 15:42:
> > On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
> >> The predictability issue seems to be due to using a MAC address.
> >>
> >> AFAIK a reinstall will not change PCI bus devices etc.
> > 
> > No, PCI device numbers change all the time, they are not guaranteed to
> > be stable at all.  Yes, lots of machines do not have them change, but a
> > non-small number do.  Most of the time they change only if you have
> > changed a PCI device (which includes thunderbolt and docking stations,
> > quite common these days), or when you update your BIOS, but my favorite
> > machine would renumber the whole bus every other boot for no good reason
> > at all.
> > 
> > So don't think of PCI bus numbers as static, they aren't, sorry.
> 
> That implies that the whole PCI addressing is not something you can
> depend on to begin with. I'm sorry, from their inclusion in the mapping
> feature, I assumed that it would be something dependable. You basically
> say that even on a single machine, that whole feature might not work
> reliably, and hence should not be used.
> 
> However, this currently confuses me because my own ethernet device is
> numbered by biosdev according to "PCI geographical location".
> 
> Maybe that is not a bus number, but:
> 
> [P]ps[f][d]
> 
> My device is enp3s0, which implies 3rd bus number, which it indeed is:
> 
> E: ID_PATH=pci-:03:00.0
> 
> Are you telling me there are systems where this is not guaranteed to be
> stable?

Yes, including your own.

> Maybe these two numbers are coincidentally the same and not
> related. It's an onboard chip (as most) and so not really geograpically
> located.

Put a new PCI device in your system, or boot it in a docking station, or
plug in some thunderbolt devices before booting and then look at this
number.

But, it's the best that the system can do, as obviously your bios does
not provide a slot name for the PCI device, otherwise the naming scheme
would have picked that.

Go file a bug for your laptop manufacturer to properly provide the
needed PCI slot number, and then your id will not change.

> In all of the examples though, this is not a coincidence and these
> numbers are identical. This PCI path is used for the biosdev name.
> 
> You are saying it is not stable?

Yes, see above.

The naming scheme starts with the most stable thing it can find and
works downward.  PCI ids are usually "good enough" for almost everyone,
like you are seeing on your system.  But they do change, which is why
most sane BIOSes provide PCI slot information, as those correspond
directly to the hardware location in the system.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

Greg KH schreef op 11-04-16 15:42:
> On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
>> The predictability issue seems to be due to using a MAC address.
>>
>> AFAIK a reinstall will not change PCI bus devices etc.
> 
> No, PCI device numbers change all the time, they are not guaranteed to
> be stable at all.  Yes, lots of machines do not have them change, but a
> non-small number do.  Most of the time they change only if you have
> changed a PCI device (which includes thunderbolt and docking stations,
> quite common these days), or when you update your BIOS, but my favorite
> machine would renumber the whole bus every other boot for no good reason
> at all.
> 
> So don't think of PCI bus numbers as static, they aren't, sorry.

That implies that the whole PCI addressing is not something you can
depend on to begin with. I'm sorry, from their inclusion in the mapping
feature, I assumed that it would be something dependable. You basically
say that even on a single machine, that whole feature might not work
reliably, and hence should not be used.

However, this currently confuses me because my own ethernet device is
numbered by biosdev according to "PCI geographical location".

Maybe that is not a bus number, but:

[P]ps[f][d]

My device is enp3s0, which implies 3rd bus number, which it indeed is:

E: ID_PATH=pci-:03:00.0

Are you telling me there are systems where this is not guaranteed to be
stable? Maybe these two numbers are coincidentally the same and not
related. It's an onboard chip (as most) and so not really geograpically
located.

In all of the examples though, this is not a coincidence and these
numbers are identical. This PCI path is used for the biosdev name.

You are saying it is not stable?

Regards.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Greg KH]

On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
> The predictability issue seems to be due to using a MAC address.
> 
> AFAIK a reinstall will not change PCI bus devices etc.

No, PCI device numbers change all the time, they are not guaranteed to
be stable at all.  Yes, lots of machines do not have them change, but a
non-small number do.  Most of the time they change only if you have
changed a PCI device (which includes thunderbolt and docking stations,
quite common these days), or when you update your BIOS, but my favorite
machine would renumber the whole bus every other boot for no good reason
at all.

So don't think of PCI bus numbers as static, they aren't, sorry.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

Martin Pitt schreef op 11-04-16 10:40:
> Reindl Harald [2016-04-10 17:44 +0200]:
>>> Because we had a mechanism for stable (but not predictable) interfaces
>>> names, the 75-persistent-net-generator.rules thingy. Without either,
>>> the first time you plugged in a second card/USB dongle/add an ibmveth
>>> etc., chaos would start.
>>
>> that worked perfectly
> 
> Hahahahno. :/
> 
> It had an inherent race condition of renaming devices to the same
> namespace than the kernel uses (thus creating collisions), and did not
> work at all in virtualized environments (see the long and ever-growing
> MAC blacklist).

So you can use a different namespace, and use hardware addresses right
(PCI bus etc.).

Even if you use BIOS device names you can get something stable even if
it is not "predictable".

> Apart from that it had several design problems: it was not predictable
> (names changed across reinstalls), prevented the ability of creating
> one OS image and installing it on many pieces of hardware (as the MAC
> addresses are device specific) and needed constant writability of
> /etc.

The predictability issue seems to be due to using a MAC address.

AFAIK a reinstall will not change PCI bus devices etc.

When you say "one OS image and installing it on many pieces of hardware"
you are apparently talking about identical hardware. That too is solved
by using a real hardware address.

What benefit has the "predictable" naming scheme when you consider:

1. It is going to be different from computer to computer
2. An enumeration scheme based on real hardware addresses will only
   change when hardware is removed/added (assuming for the moment
   adding usb dongles does not change "hard" components).

The only situation I can readily imagine is when someone repeatedly
plugs in 2 different networking devices and wants routing to be
different for each one of them.

In the scenario I describe you would not be able to have persistent
rules for these removable devices because they would be reordered or
might change order when plugging back in. (Then again, creating
persistent rules based on removable devices might be a pain anyway).

So where is the usage scheme where: having a persistent important
firewall or routing configuration agrees with a scenario of regularly
changing or adding/removing hardware in such a way the number of devices
actually change (most important scenario).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Reindl Harald]

Am 11.04.2016 um 10:40 schrieb Martin Pitt:

Reindl Harald [2016-04-10 17:44 +0200]:

Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without either,
the first time you plugged in a second card/USB dongle/add an ibmveth
etc., chaos would start.


that worked perfectly


Hahahahno. :/

It had an inherent race condition of renaming devices to the same
namespace than the kernel uses (thus creating collisions), and did not
work at all in virtualized environments (see the long and ever-growing
MAC blacklist).


on VMware guests with just one NIC it was never a problem
there would be *nothing* to rename and even the udev stuff would not 
have been needed and that first try of "persistent" introduced the 
problem that you have to edit a udev-conf file instead leave the kernel 
in peace


on physical machines with just one NIC ist was never a problem


Apart from that it had several design problems: it was not predictable
(names changed across reinstalls), prevented the ability of creating
one OS image and installing it on many pieces of hardware (as the MAC
addresses are device specific) and needed constant writability of
/etc


if you have just one NIC "eth0" ist very predictable
that's the majority of machines

WLAN was alwas "wlan0" and so did not collide and machines with one 
ethernet card and a WLAN card count as "with just one NIC"


in other words: while maintaing a ton of different machines over a 
decade i had not a singel time the problems 
"PredictableNetworkInterfaceNames" are pretending to solve but now i 
have to add for every single install "net.ifnames=0 biosdevname=0" to 
the kernel params which was not needed in the past




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Martin Pitt]

Reindl Harald [2016-04-10 17:44 +0200]:
> >Because we had a mechanism for stable (but not predictable) interfaces
> >names, the 75-persistent-net-generator.rules thingy. Without either,
> >the first time you plugged in a second card/USB dongle/add an ibmveth
> >etc., chaos would start.
> 
> that worked perfectly

Hahahahno. :/

It had an inherent race condition of renaming devices to the same
namespace than the kernel uses (thus creating collisions), and did not
work at all in virtualized environments (see the long and ever-growing
MAC blacklist).

Apart from that it had several design problems: it was not predictable
(names changed across reinstalls), prevented the ability of creating
one OS image and installing it on many pieces of hardware (as the MAC
addresses are device specific) and needed constant writability of
/etc.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Reindl Harald]

Am 10.04.2016 um 16:57 schrieb Martin Pitt:

Andrei Borzenkov [2016-04-10 11:31 +0300]:

It had been working out of the box for quite a lot of users actually.


Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without either,
the first time you plugged in a second card/USB dongle/add an ibmveth
etc., chaos would start.


that worked perfectly and chaos only started as it's funtionality went 
away while people knew how to use it


nothing easier to handel than a single textfile with all mac/name 
mappings where any new interface appears on bottom and you can also 
leave the older entries for not present in case of removeable hardware




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [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,

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Martin Pitt]

Andrei Borzenkov [2016-04-10 11:31 +0300]:
> It had been working out of the box for quite a lot of users actually.

Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without either,
the first time you plugged in a second card/USB dongle/add an ibmveth
etc., chaos would start.

> Again - configuring location based naming was pretty easy in the past.

Again -- nothing changed wrt. manually configuring interface names if
you desire so.

> You need to explain why your new naming scheme is better than that.

See "Why" on
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Also, it's not "my" schema, but I do think it's a fairly good
compromise between all the bad options how to do interface naming.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Reindl Harald]

Am 10.04.2016 um 10:17 schrieb Martin Pitt:

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


no - because you have to configure them anyways - multiple network 
interfaces don't know magically their roles


to be frank the attitude above of the 2000's on single NIC systems (like 
most virtual machines) leads in *everybody* has to configure something 
if it comes to virtual servers and iptables rules while having just 
"eth0" as all the years before on such setups would be safe and make it 
possible to just re-use your existing scripts




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Andrei Borzenkov]

10.04.2016 11:17, Martin Pitt пишет:
> Hello,
> 
> Xen [2016-04-09 20:29 +0200]:
>> 1. I believe most users do not like the "enp5s0" scheme
>> 2. I do not think there are any good reasons for making it the default.
> 
> 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. :-)
> 

There was no problem having interface names based on PCI location before
as well. So this is irrelevant. If PCI enumeration changes between
reboot, your new names will change as well.

>> "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.
> 
>> 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.
> 

Most of those users have single eth0 and single wlan0. So yes, from
perspective of interface naming they have single NIC with given name
pattern.

>> 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.
> 

It had been working out of the box for quite a lot of users actually.

> 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.
> 
>> The new biosdev scheme is so meaningless that mostly any user WILL want
>> to change this scheme to become something meaningful, but the obstacles
>> to it are too great currently for the regular user.
> 
> 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.
> 

Again - configuring location based naming was pretty easy in the past.
You need to explain why your new naming scheme is better than that.

And the fact that it is mistakenly named "predictable" makes things no
better, because it is anything else than predictable - please try to
predict interface names on random system out there *before* you have
installed Linux on it.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Martin Pitt]

Hello,

Xen [2016-04-09 20:29 +0200]:
> 1. I believe most users do not like the "enp5s0" scheme
> 2. I do not think there are any good reasons for making it the default.

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. :-)

> "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.

> 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.

> 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.

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.

> The new biosdev scheme is so meaningless that mostly any user WILL want
> to change this scheme to become something meaningful, but the obstacles
> to it are too great currently for the regular user.

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.

> 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.

> 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.

> 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.

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.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

I just want to add another opinion, but I am going to keep it really short.

1. I believe most users do not like the "enp5s0" scheme
2. I do not think there are any good reasons for making it the default.

As a single illustration, I will cite this reason from the website:

"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."


Now the entire change is solely due apparently due to, or for, systems
that have multiple nics all complying to a certain naming scheme such as
"eth".

What is really the amount of systems or proportion thereof that have
multiple NICs?

So I am not saying this solution is a bad solution, I am saying the
default is a bad default.

Any user running a system with multiple NICs should be willing and
capable of choosing and assigning these names.

The new biosdev scheme is so meaningless that mostly any user WILL want
to change this scheme to become something meaningful, but the obstacles
to it are too great currently for the regular user.

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.

Even if these biosdev names would be mapped by default to comprehensible
names such as eth0 and wlan0, it would be better for the vast majority
that does NOT have 2 NICs.

There is really nothing against working internally with these names. But
it shouldn't be the presentation.

"We believe it is a good default choice to generalize the scheme
pioneered by "biosdevname"."

How on earth can you believe it is a good default choice if it caters to
only <5% of users, while 95% suffer for it?

That is not something that could ever be a good default.

"Assigning fixed names based on firmware/topology/location information
has the big advantage that the names are fully automatic, fully
predictable, that they stay fixed even if hardware is added or removed
(i.e. no reenumeration takes place) and that broken hardware can be
replaced seamlessly."

95% of users do not replace networking hardware.

Setting up firewall rules for multiple zones requires manual
intervention regardless, or a form of automatic intervention that could
also decide on, and configure a network name mapping.

So what problem did you really solve here?



Now you are causing 95% of users that really need to turn it off.

To create the system they like, but most of them won't do it, because it
is not an easy configuration option either.

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.

And if it does need to be on by default, at least create a default
mapping to the old names for everyone.



Perhaps this is something for distributions to decide, but changing
something downstream always requires more effort.

I do not know how big the class of installations that benefit from it.
But to my understanding cloud instances and VPSes generally won't.

So why not cater to the majority, and for the minority create an easy
way to turn it on and map it to meaningful names?

I. turn it off by default, allow it turned on by simple config
II. turn it on by default, create good default mapping to meaningful
names
III. turn it off by default, but make it a breeze to create the mapping

Those are really your options.

Currently:

A. It is hard to turn off
B. It is not instantly clear how to do the mapping

A user needs to read
https://www.freedesktop.org/software/systemd/man/systemd.link.html and
won't find any examples that actually allow mapping the biosdev names,
so any user now has to find the MAC address or Path just to return to
something meaningful.

So if BIOSDEV has benefits, why not use it as a thing to map against?

And, creating multiple files for multiple mappings is not a convenient
and easy thing to do. Why not allow for something that can do this in
one single file?

Why not:

enp3s0: eth0
enp3s1: eth1

as a simple file format?

Why not create something like that by default?

Now you have solved the randomness in kernel registration, while still
having the naming scheme everyone loves.

This is much too much work for any normal user.

The knowhow to turn the feature off is not readily accessible on any system.

Ideally this knowhow must be present in a config file.

"80-net-setup-link.rules" is not something you can remember.

Distributions can make the same choice, but cannot really change the
configuration file format, nor the mapping ability based on the biosdev
names. What you've done here simply makes no sense.

In law a judge would say that you have placed an unreasonable burden on
the majority of