Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Xen schreef op 12-04-16 04:26:

> I didn't even know it was that bad, jeez.
> 
> My apologies.

My sound stopped working as well because it was now a new device ;-)
(different PCI bus number).

The system sees it now as two devices, one of which is not present.

They are the same device of course.

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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 12-04-16 00:14:
> On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote:
 You can put usb devices at the end of the list.
>>>
>>> Why last?  How do you know they go last when scanning?  How do you know
>>> when / if they will show up?  What about 2 USB devices?  3?
>>
>> To me it seems obvious that you initialize onboard devices before USB
>> devices, so it would not be a "how do you know" because you do it yourself.
> 
> How you determine if a device is "onboard" or "offboard"?  Are you going
> to know when all "onboard" devices are found before you do anything
> else?  How?

I don't know, do you know? I am just a nitwit right.

The distinction I made was between USB and non-USB.

If you map the thing onto two separate lists, problem solved.

Regular hardware should not suddenly appear out of nowhere, but I do not
know about that Thunderbolt thing you mentioned.

That would imply that in the old scheme there were amazing problems just
about anywhere. I do not think this was the case.

"Solves real problems". You still have not identified "real problems"
that plagued more than 1% of the population.


>> Also, since the current scheme puts usb devices in a slightly different
>> format you can identify them from the name.
>>
>> You are right in saying that that would cause a list that changes as it
>> is getting populated. But onboard/builtin devices should definitely all
>> be scanned before networking is initialized right?
> 
> Not true at all, drivers are loaded whenever, at pretty much random
> times, when ever the hardware is found by the kernel.  It's
> non-deterministic and you never know when it's done for some busses
> (like USB).

That is completely nonsensical because it would imply that some network
device could be initialized 2 hours after the system had booted.

Don't make me cry.

Are you just pretending ignorance just so you can make stupid statements
about stuff that has always worked? What are you really trying to do?

I have never had any system where some hardware was suddenly found 3
hours down the line.

"whenever" -- no, not whenever, when the system starts.

Stop being so ridiculous please. This whole scheme is ridiculous. The
fact that my networking scripts will fail the moment I remove an add-on
card that has nothing to do with networking is completely and utterly
and downright ridiculous.

All PCI devices are recognised before networking starts, or networking
could never reliably start. The issue that a networking system would be
started before its required device was found, does not exist in reality,
as far as I can know, and if it did exist in reality, it would be a
terribly bad situation and everyone would be crying about it everywhere.

And I hardly doubt it is going to be "very" nondeterministic, I think if
I create and save kernel logs for my system here, it is going to be the
same each and every time.

Also, on my system the ethernet device driver is loaded within 2.6 seconds:

[2.589977] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

Two USB devices (both usbsticks I think) within 2.7 seconds.

The renaming happens slightly after:

[2.656676] r8169 :02:00.0 enp2s0: renamed from eth0

An external hub at 2.9:

[2.889998] hub 1-4:1.0: 4 ports detected

And the last USB message occurs at 3.34 although directly after a number
of storage devices are recognised/initialized.

Of course the rationale for the whole system was randomness in device
recognition (particularly if recognition of multiple devices occurs in a
small time frame, I would guess). Nevertheless, apart from audio and
graphics messages occuring at a later time, within 4 seconds everything
that is vital to the operation of the machine is already recognised.

That means that given 'fixed' devices (present at boot) the whole
biosdev networking tree might already be available and not change anymore.

Of course if you start plugging devices that might change. So you keep
the port numbers for USB. I don't know about other technologies.

What's so hard really.


The thing that IS hard is finding out how to disable the thing without
passing kernel parameters. I had succeeded before, but the data on the
website is not correct. So I don't know how to do it.

It is just unacceptable that if you had some kind of static
configuration (of a network device) your configuration would fail and
your internet would fail because you plugged in some device.

And this is the reality today. You (the designers) made things much worse.

Now if you have some important networking setup, but you plug in a
networking card, the entire thing falls down its face. Or any other
card: the entire thing falls down its face.

Unless, I guess, if you say, the motherboard/bios is somehow perfect to
this scheme. Well, mine is not and it is a regular AMD Gigabyte
motherboard from around 2009.

We can see what would happen on my other system (recently purchased, but
might be an older motherboard).

But that might take a 

Re: [systemd-devel] Configuring ethernet link fails with No such device

[David Miller]

From: Stefan Agner 
Date: Mon, 11 Apr 2016 15:46:08 -0700

> What is the expectation/definition when link configuration should be
> possible? Only after the network device got opened or before?

Only after it is open.  Drivers almost always have the entire chip in
powerdown state when it is not open, so we wouldn't be able to
properly do link settings even if we wanted to when the device is
closed.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Xen schreef op 11-04-16 23:13:

> No. You are causing pain and suffering to millions of people.
> 
> You (...) have not inquired with anyone whether they really wanted this.
> 
> So you push something and then you say "oh, but you can opt out".
> 
> So you place the burden on the user. It doesn't belong there.
> 
> It's the same with email spam marketeers. They send you unsollicited
> spam, and then they say "You only have to press this link to opt out".
> Courts throw these practices out the window, in business it is not legal.
> 
> It doesn't take much effort to think of a better scheme. But you don't
> think along, you only try to prove that my scheme can't work. And it is
> really not hard to imagine something that will work.
> 
> But now I am going to test my interface name stability. See ya.


So I put it to the test.

I remove an addon card that has nothing to do with networking, and my
interface name has changed from enp3s0 to enp2s0, as predicted.

So the system is not stable AND it is not predictable.

FAIL.

THIS IS WORSE THAN BEFORE.

You people (the ones who have designed it) you can really in all
seriousness maintain you have done a good job?

I am sorry I have held back.

You have created a system that is stable across reboots (probably) BUT
now it is unstable with regards to any hardware change to the system.

Yes, blame my motherboard manufacturor.

Well I guess I have already silenced myself here. Sorry about that.

The trick to turn it off on the website doesn't work:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

So in order to do the remapping we have access to PCI, which is
unstable, and MAC which prevents redeployable images. We could map the
biosdev to a linear list or set of lists, which would solve most
problems for everyone, except if you use multiple USB devices, so you
just use a different scheme for that. Problem solved right.

Does anyone know how I can disable the renaming in some other way than
using kernel options? The above doesn't work. I cannot find the answer
anywhere.

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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote:
> >> You can put usb devices at the end of the list.
> > 
> > Why last?  How do you know they go last when scanning?  How do you know
> > when / if they will show up?  What about 2 USB devices?  3?
> 
> To me it seems obvious that you initialize onboard devices before USB
> devices, so it would not be a "how do you know" because you do it yourself.

How you determine if a device is "onboard" or "offboard"?  Are you going
to know when all "onboard" devices are found before you do anything
else?  How?

> Also, since the current scheme puts usb devices in a slightly different
> format you can identify them from the name.
> 
> You are right in saying that that would cause a list that changes as it
> is getting populated. But onboard/builtin devices should definitely all
> be scanned before networking is initialized right?

Not true at all, drivers are loaded whenever, at pretty much random
times, when ever the hardware is found by the kernel.  It's
non-deterministic and you never know when it's done for some busses
(like USB).

Best of luck,

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

[systemd-devel] Configuring ethernet link fails with No such device

[Stefan Agner]

Hi All,

I traced an issue in which we tried configuring duplex mode and speed in
a systemd-udevd .link file failed with the following error:
"Could not set speed or duplex of eth0 to 0 Mbps (half): No such device"

The FEC driver (fec_main.c) does not initialize phy_dev until the device
has been opened, and therefor the callback fec_enet_(get|set)_settings
returns -19.

What is the expectation/definition when link configuration should be
possible? Only after the network device got opened or before?

Or in other words: Is this a Kernel or systemd issue? At what point is
link configuration "guaranteed" to work?

It seems that the FEC driver used to probe the PHY earlier, it has been
moved to the open callback with commit 418bd0d4df ("netdev/fec: fix
ifconfig eth0 down hang issue")...

There has been a similar report on the systemd-devel mailing list a
while ago, probably the same underlying issue:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg33186.html

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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 11-04-16 22:21:
> On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
>> It will just not be "predictable" when you remove or add hardware,
>> because that reorders the resulting lists.
>>
>> Ie, if you have:
>>
>> ethernet0
>> ethernet1
>> ethernet2
>>
>> And you add a new device, it might become:
>>
>> ethernet0
>> ethernet1
>> ethernet2  <-- new device
>> ethernet3
>>
>> But is that really an issue?
> 
> Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
> naming scheme at all"

Apparently you just said the current scheme is identical to that as well
(for my system).

I thought the reason for this system was stability across reboots.

If the biosdev system is stable across reboots, this one will be as
well. The old system was not stable across reboots, so what you say is
not true.


>> You can put usb devices at the end of the list.
> 
> Why last?  How do you know they go last when scanning?  How do you know
> when / if they will show up?  What about 2 USB devices?  3?

To me it seems obvious that you initialize onboard devices before USB
devices, so it would not be a "how do you know" because you do it yourself.

Also, since the current scheme puts usb devices in a slightly different
format you can identify them from the name.

You are right in saying that that would cause a list that changes as it
is getting populated. But onboard/builtin devices should definitely all
be scanned before networking is initialized right?

That means that part of the list is going to be stable for networking is
used.

Last, because regular onboard devices do not suddenly evaporate after
having been initalized.

This conceptually separates the list so that usb devices cannot change
the 'hardware' devices or its list (as it is the first part that is
never going to change again during the running of the system).

That is why "last" (makes sense, no?).

So indeed if you had multiple usb devices that you keep plugging and
unplugging, indeed they would not have stable names.

The provision for USB identification depends entirely on port numbers:

"For USB devices the full chain of port numbers of hubs is composed."

That means if you pull out some device and put it in a different port,
its name will change.

Given this fact, the stability you get is minimal at best.

So now is the question, under what scenario are you going to be basing
advanced routing configuration on fixed usb port numbers Wouldn't
that be insane to begin with?

Now you have a certain routing setup but it only works if you use the
same usb ports and hubs for connecting it

Is that a real scenario? No, it isn't. More common would be the scenario
to have ONE usb device that you use in whatever port.

In the current system, it constantly changes name. In my proposed
system, it would probably always have the same name. Because an usb port
number is not meaningful.

So now you have the corner case scenario where someone uses 2 usb
devices of the same kind in fixed port positions and wants to build some
kind of routing on that.

In general you would not do anything of that kind but okay. USB and
"fixed system" is not exactly in agreement with each other. But okay.

Now you have your 2nd USB device plugged in but your first isn't. Second
based on port number / path.

If both were plugged in you would have:

wireless0  <-- first device
wireless1  <-- second device

(Just assuming these are wireless dongles)

Now you only plug the second and it becomes:

wireless1  <-- second device

Now at some point you plug the first, and the name changes.

Dynamically, while having a running system.

In the current system, their names do not change because they are based
on port.

I do not know what the "old" system did. I'm sure this never happened
because people thought about it. I'm sure you can base device names on
something else if that is necessary.

You could even turn it into "wireless-usb-u1u4i6" or something similar.

People do not care about the names of usb devices. Mostly.

They accept that these names might be quite random from their point of view.

So if you must, keep basing your name on that. I mean, what's the issue.

wlp0s29u1u2 is however pretty nondescript. Why not something a tad longer.

Something that does not require knowledge of the scheme to know that "u"
designates port number. In order to divine that this is an usb device.

Nobody who plugs in USB devices is going to want it to conform to
"eth0". That is just nonsense. People don't want that. Every computer
has a built in LAN port (except for some laptops etc). We expect it to
have an easy name. Every laptop has a built-in wlan port. We expect it
to have an easy name. Anything extra -- temporary usb connections and
the like, we don't care as much.

Since these port numbers change, you cannot base any persistent routing
on usb devices anyway. Not anything that cannot be automatically
configured. The only thing that is required is stabilty across the

Re: [systemd-devel] ReadOnlyDirectories and new mounts

[Reindl Harald]

Am 11.04.2016 um 21:22 schrieb Yuriy M. Kaminskiy:

I have long-running service with tight restrictions:

ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/foobar
ReadWriteDirectories=-/var/log/foobar
ReadWriteDirectories=-/var/run

I mounted some new directory on main system, and noticed that
newly-mounted directories have read-write permissions inside service
mount namespace


expected behavior like explained in the documentation
the same applies for "ReadOnlyDirectories=-/whatever" when the folder 
appears after the service was started




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]

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] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
> It will just not be "predictable" when you remove or add hardware,
> because that reorders the resulting lists.
> 
> Ie, if you have:
> 
> ethernet0
> ethernet1
> ethernet2
> 
> And you add a new device, it might become:
> 
> ethernet0
> ethernet1
> ethernet2  <-- new device
> ethernet3
> 
> But is that really an issue?

Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
naming scheme at all"

> You can put usb devices at the end of the list.

Why last?  How do you know they go last when scanning?  How do you know
when / if they will show up?  What about 2 USB devices?  3?

It looks like you really want the old-style naming scheme, which is
great, you have the ability to roll back to that.  Please do so.

thanks,

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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
> It will just not be "predictable" when you remove or add hardware,
> because that reorders the resulting lists.
> 
> Ie, if you have:
> 
> ethernet0
> ethernet1
> ethernet2
> 
> And you add a new device, it might become:
> 
> ethernet0
> ethernet1
> ethernet2  <-- new device
> ethernet3
> 
> But is that really an issue?

Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
naming scheme at all"

> You can put usb devices at the end of the list.

Why last?  How do you know they go last when scanning?  How do you know
when / if they will show up?  What about 2 USB devices?  3?

It looks like you really want the old-style naming scheme, which is
great, you have the ability to roll back to that.  Please do so.

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

[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

[systemd-devel] ReadOnlyDirectories and new mounts

[Yuriy M. Kaminskiy]

I have long-running service with tight restrictions:

   ReadOnlyDirectories=/
   ReadWriteDirectories=-/proc
   ReadWriteDirectories=-/var/lib/foobar
   ReadWriteDirectories=-/var/log/foobar
   ReadWriteDirectories=-/var/run

I mounted some new directory on main system, and noticed that 
newly-mounted directories have read-write permissions inside service 
mount namespace:


   nsenter -t `pidof foobar` -m cat /proc/self/mounts|grep -w rw

That's pretty bad, but I'm not sure how it can be solved.

Of course, I can set MountFlags=private, and it will break mount 
propagation to service mount namespace - however, it will also break 
*umount* propagation, which also can be extremely problematic (if 
removable device was mounted when service is (re)started, such service 
will keep it mounted even after "host/main" system unmounted device).


Or systemd may be fixed to watch for new mounts, then perform something 
akin `nsenter -t $MAINPID mount -o remount,ro $new_mounted_path`, 
however there will be window between mount and service namespace fixup.


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

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 11-04-16 01:05:
> On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote:
>> Michael Biebl schreef op 11-04-16 00:22:
>>> So why don't you implement such a scheme? Talk is cheap
>>
>> Criticising an idea by saying "do it yourself" is even cheaper.
>>
>> MUCH MUCH cheaper.
>>
>> Idiot.
> 
> No he isn't.  The developers here put a lot of thought and energy
> working with numerous hardware requirements an user cases in order to
> come up with the current situation.  It works for almost everyone, which
> is vastly better than the previous scheme of "first driver loaded
> wins!", which barely worked for anyone, and caused so many problems it
> wasn't funny (just ask any of us who have been in support for a distro
> about the problems...)

I am sorry, I had wanted to explain. It is really no ones business why
you are not doing a certain thing.

For all you know someone is not capable of programming. For all you know
someone is not versed in C, or does not have the health to do such a thing.

If you are really that unimaginative to consider that there might
actually be good reasons why someone does not do a certain thing, you
are an idiot.

People like cheap labour.

I will keep it at that for now.


> If you have an alternative proposal, great, it can be fit into the
> existing system (note the heirachy of names that are picked depending on
> just how well your hardware describes itself.)  Please propose that.

I just did.

I proposed transforming the tree-like biosdev names into a linear
display, the way you can traverse a tree and produce a list.

If the biosdev names are a model of the networking hardware, that does
not imply it has to be the presentation.

You can transform the biosdev names (that are now stable, or unique)
into a presentation that agrees with the "old" names:

ethernet0
ethernet1
loopback
wireless0

bridge0

Whatever. Most systems do not have more than 1 or 2 networking devices.
If you have 2 physical nics, you probably won't also have wireless. If
you have wireless + ethernet, you might not have a 2nd wired ethernet.

You can traverse the biosdev tree and produce a list.

That was my proposal.


> If you don't like the current scheme, that's also fine, there is a
> trivial way to "opt-out" of it.
> 
> So I don't understand your complaints, you don't like the current
> scheme, yet you don't have any proposal other than "I liked the original
> way", which you still have access to.  So really, there isn't anything
> to change here that I can see, unless you have a new naming scheme that
> can be implemented as well?

That was what my whole message was about.

However, the biosdev names are not available for mapping.

Only the MAC and PCI are (as far as I know).

The naming scheme is not really important (from the viewpoint of the
creators' requirements) -- only the stability is.

Even if you lose some information when you transform the tree to a list,
or several lists, this does not impact the stability. It might impact
the predictability -- whatever it is worth, but not the stability.

Having names such as "ethernet0" "ethernet1" gives less information, but
a user does not need that information.

If the biosdev "tree" for a system is stable, then so will be a linear
transformation of that (a traversal into a list or several lists).

However this is not trivial for a user to implement because the biosdev
names are already the result of a mapping and cannot be changed.

You can only operate on their source, which is a tad complex for an
ordinary user to do, and would throw away the work the people have done.

So why not:

enp3s0 --> ethernet0
wlXX --> wireless0
lo --> loopback
br0 --> bridge0

and so forth?

It is readable, it is user friendly, if biosdev is stable, so will this
be stable. It has all the benefits of biosdev scheme except for:
predictability.

But is this not actually MORE predictable?

- If the biosdev ordering does not change, neither will this.
- The first ethernet device will again be called ethernet0 on all systems
- The first wireless device will again be called wireless0 on all systems

- You use the work the systemd people have done as a foundation to
create the stability, but you do away with the presentation of it as
something the user needs to see.

So I say simply TRANSFORM THE TREE.

Turn it into lists. What do you lose?

It will just not be "predictable" when you remove or add hardware,
because that reorders the resulting lists.

Ie, if you have:

ethernet0
ethernet1
ethernet2

And you add a new device, it might become:

ethernet0
ethernet1
ethernet2  <-- new device
ethernet3

But is that really an issue?

You can put usb devices at the end of the list.

Regards, Bart.
___
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] How to log to journald using fifo?

[Lennart Poettering]

On Sun, 10.04.16 22:57, Samuel Williams (space.ship.travel...@gmail.com) wrote:

> Hello,
> 
> 
> I've been trying to figure out the best way to support legacy applications
> that don't support syslog for logging. The best we can do, I think, is to
> use fifo and have another process read the fifo to journald.

Note that on systemd everything logged out stdout or stderr ends up in
the journal anyway. And you can specify /dev/stderr or /proc/self/fd/2
as path referring to stderr on Linux generally, if you need.

> Finally, if this is a good approach, is this method worth putting into
> systemd/journald as a standard service? If so, how do I submit a PR or
> where to begin?

Specific work-arounds around other, unrelated pieces of software are
not really what we we'd like to add to systemd directly. Sorry.

Lennart

-- 
Lennart Poettering, Red Hat
___
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