Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Thu, 2017-07-27 at 10:05 +, Sam Morris wrote:
> You'd have to use BindsTo=sys-subsystem-net-devices-blah.device. But 
> BindsTo= and device units are a bit fiddly, see  systemd/systemd/issues/4413>.

I had a systemd enthusiast sitting beside me who recommended that.  I
was suspicious after reading the description of BindsTo
in systemd.unit(5).  It makes absolutely no mention of that behaviour. 
I thought I was vindicated when it failed.

Now you are telling it was merely buggy code and buddy doco.  That
means latent may have been right.  It's rare, but I guess it had to
happen sometime.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Sam Morris]

On Sat, 15 Jul 2017 22:44:46 +1000, Russell Stuart wrote:

> On Sat, 2017-07-15 at 07:46 +0200, Tollef Fog Heen wrote:
>> Doesn't something like:
>> 
>> [Unit]
>> Description=My hook for foo.link After=foo.link BindsTo=foo.link
>> 
>> [Service]
>> Type=oneshot ExecStart=/usr/local/sbin/whatever RemainAfterExit=yes
>> 
>> [Install]
>> WantedBy=multi-user.target
>> 
>> work to hook into when a link unit is activated?
>> 
>> (Or just a Wants and Before in the foo.link unit)
> 
> When I discovered .link and .network files the first thing I looked up
> in the doco was whether that sort of thing was possible.  I decided it
> wasn't and wrote it off as useless for me.
> 
> Now you've made me check for real.  After setting up the unit files you
> suggested I get this message in journalctl:
> 
>   Failed to add dependency on foo.link, ignoring: Invalid argument

You'd have to use BindsTo=sys-subsystem-net-devices-blah.device. But 
BindsTo= and device units are a bit fiddly, see .

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Wed, Jul 19, 2017 at 10:53:34PM +0200, Guus Sliepen wrote:

> rename mac/00:16:0a:26:99:c6/=en0
> auto en0
> iface en0 ...

This should now work in ifupdown 0.8.22.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Wed, Jul 19, 2017 at 11:32:38PM +0200, Adam Borowski wrote:

> Well, but on the way up, /eth0/=en0 or mac/.../=en0 will match logical
> interface "en0", and on the way down, and subsequent manual ups, it will
> match the kernel name "en0".  Am I missing something?

Yes, /eth0/=en0 will match kernel name eth0, both up and down. On up, it
will configure eth0 with the iface en0 stanza. On down, it deconfigures
it based on the stanza it was brought up with.

This also allows something like:

auto /eth*/=eth
iface eth inet dhcp

When doing ifup -a, this will bring up all eth* interfaces with DHCP.
But you can also ifup/ifdown each individual interface that matches eth*
by its kernel name.

> > rename mac/00:16:0a:26:99:c6/=en0
> > auto en0
> > iface en0 ...
> 
> Slightly more typing, but that'd work, too.

In 0.8.21 I added an undocumented feature:

iface en0 ...
auto

Is equivalent to:

auto en0
iface en0 ...

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Adam Borowski]

On Wed, Jul 19, 2017 at 10:53:34PM +0200, Guus Sliepen wrote:
> On Mon, Jul 17, 2017 at 06:22:14PM +0200, Guus Sliepen wrote:
> 
> > > Thus, what about this:
> > > auto mac/00:16:0a:26:99:c6/=en0
> > > iface en0 inet6 static
> > >   address 3:1415:9265:3589:7932:3846:2643:3832/64
> > >   gateway 3:1415:9265:3589::1
> > >   rename
> > > 
> > > With the rename command taking an optional argument (the new name) that
> > > defaults to the logical name (ie, after =).
> > 
> > Yes, that should be implementable.
> 
> Actually, that is not as easy as it sounds. It works in the above
> example because mac/00:16:0a:26:99:c6 would still match en0 after the
> rename, but that is not always true. For example, doing auto /eth0/=en0
> means the pattern eth0 matches on ifup, but it no longer matches when
> you do ifdown. Also, ifupdown supports changing the MAC address of an
> interface, so even mac/.../ patterns are problematic.

Well, but on the way up, /eth0/=en0 or mac/.../=en0 will match logical
interface "en0", and on the way down, and subsequent manual ups, it will
match the kernel name "en0".  Am I missing something?

> It's better to split it:
> 
> rename mac/00:16:0a:26:99:c6/=en0
> auto en0
> iface en0 ...

Slightly more typing, but that'd work, too.

> And do the renames whenever ifup is run, before it processes anything
> else.

That's obvious, in both cases.


-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Mon, Jul 17, 2017 at 06:22:14PM +0200, Guus Sliepen wrote:

> > Thus, what about this:
> > auto mac/00:16:0a:26:99:c6/=en0
> > iface en0 inet6 static
> > address 3:1415:9265:3589:7932:3846:2643:3832/64
> > gateway 3:1415:9265:3589::1
> > rename
> > 
> > With the rename command taking an optional argument (the new name) that
> > defaults to the logical name (ie, after =).
> 
> Yes, that should be implementable.

Actually, that is not as easy as it sounds. It works in the above
example because mac/00:16:0a:26:99:c6 would still match en0 after the
rename, but that is not always true. For example, doing auto /eth0/=en0
means the pattern eth0 matches on ifup, but it no longer matches when
you do ifdown. Also, ifupdown supports changing the MAC address of an
interface, so even mac/.../ patterns are problematic.

It's better to split it:

rename mac/00:16:0a:26:99:c6/=en0
auto en0
iface en0 ...

And do the renames whenever ifup is run, before it processes anything
else.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Mon, Jul 17, 2017 at 05:12:07AM +0200, Adam Borowski wrote:

> > That's indeed an interesting issue. Currently, ifupdown doesn't rename
> > interfaces. You could add a line like:
> > 
> > post-up ip link set $IFACE name $LOGICAL
> > 
> > Which will do what you want, except ifupdown doesn't track interface
> > renames this way and will get very confused. In particular, ifdown will
> > not work anymore. So some code should be added to ifupdown to support
> > interface renaming.
> 
> This is what I assumed your new code does -- it seemed an obvious and
> natural thing to do.

Well, it just matched an existing interface to a logical iface stanza,
it didn't need to rename anything. The use case is anything outside of
ifupdown and its plugins that might use interface names, such as for
example netfilter-persistent.

> As Ben noticed, the post-up stanza above can't work as Linux doesn't allow
> renaming interfaces at that point. It can't work in pre-up either as
> ifupdown wouldn't know about the rename.

Ah, indeed.

> Thus, what about this:
> auto mac/00:16:0a:26:99:c6/=en0
> iface en0 inet6 static
>   address 3:1415:9265:3589:7932:3846:2643:3832/64
>   gateway 3:1415:9265:3589::1
>   rename
> 
> With the rename command taking an optional argument (the new name) that
> defaults to the logical name (ie, after =).

Yes, that should be implementable.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Adam Borowski]

On Sun, Jul 16, 2017 at 01:54:27PM +0200, Guus Sliepen wrote:
> On Sat, Jul 15, 2017 at 10:25:22PM -0300, Henrique de Moraes Holschuh wrote:
> > It is indeed Very Cool, but it might not solve one little thing:
> > iptables firewalling.
> > 
> > Is that a way to trigger an ifrename using this, so that the network
> > device ends up being named "foo" ?
> 
> That's indeed an interesting issue. Currently, ifupdown doesn't rename
> interfaces. You could add a line like:
> 
>   post-up ip link set $IFACE name $LOGICAL
> 
> Which will do what you want, except ifupdown doesn't track interface
> renames this way and will get very confused. In particular, ifdown will
> not work anymore. So some code should be added to ifupdown to support
> interface renaming.

This is what I assumed your new code does -- it seemed an obvious and
natural thing to do.

As Ben noticed, the post-up stanza above can't work as Linux doesn't allow
renaming interfaces at that point.  It can't work in pre-up either as
ifupdown wouldn't know about the rename.

Thus, what about this:
auto mac/00:16:0a:26:99:c6/=en0
iface en0 inet6 static
address 3:1415:9265:3589:7932:3846:2643:3832/64
gateway 3:1415:9265:3589::1
rename

With the rename command taking an optional argument (the new name) that
defaults to the logical name (ie, after =).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Naming of network devices - how to improve it in buster

[Ben Hutchings]

On Sun, 2017-07-16 at 13:54 +0200, Guus Sliepen wrote:
> On Sat, Jul 15, 2017 at 10:25:22PM -0300, Henrique de Moraes Holschuh wrote:
> 
> > > > This will match any interface that has MAC address 01:23:45:67:89:ab,
> > > > and will use the "foo" stanzas to configure it.
> > > 
> > > Awesome!  This sounds like the best solution so far.
> 
> As Adam discovered, there was still a bug preventing this from actually
> working for allow-* interfaces, but a fix has just been uploaded.
> 
> > It is indeed Very Cool, but it might not solve one little thing:
> > iptables firewalling.
> > 
> > Is that a way to trigger an ifrename using this, so that the network
> > device ends up being named "foo" ?
> 
> That's indeed an interesting issue. Currently, ifupdown doesn't rename
> interfaces. You could add a line like:
> 
>   post-up ip link set $IFACE name $LOGICAL
> 
> Which will do what you want, except ifupdown doesn't track interface
> renames this way and will get very confused.
[...]

Linux doesn't allow renaming an interface while it's up.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.



signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Sat, Jul 15, 2017 at 10:25:22PM -0300, Henrique de Moraes Holschuh wrote:

> > > This will match any interface that has MAC address 01:23:45:67:89:ab,
> > > and will use the "foo" stanzas to configure it.
> > 
> > Awesome!  This sounds like the best solution so far.

As Adam discovered, there was still a bug preventing this from actually
working for allow-* interfaces, but a fix has just been uploaded.

> It is indeed Very Cool, but it might not solve one little thing:
> iptables firewalling.
> 
> Is that a way to trigger an ifrename using this, so that the network
> device ends up being named "foo" ?

That's indeed an interesting issue. Currently, ifupdown doesn't rename
interfaces. You could add a line like:

post-up ip link set $IFACE name $LOGICAL

Which will do what you want, except ifupdown doesn't track interface
renames this way and will get very confused. In particular, ifdown will
not work anymore. So some code should be added to ifupdown to support
interface renaming.

Note that there is a package called "ifrename" that has a nice way of
configuring interface renaming, and works independently of your init
system, udev et cetera. But I can see how it would be nice to have
renaming integrated in ifupdown.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Sat, 15 Jul 2017, Adam Borowski wrote:
> > This will match any interface that has MAC address 01:23:45:67:89:ab,
> > and will use the "foo" stanzas to configure it.
> 
> Awesome!  This sounds like the best solution so far.

It is indeed Very Cool, but it might not solve one little thing:
iptables firewalling.

Is that a way to trigger an ifrename using this, so that the network
device ends up being named "foo" ?

-- 
  Henrique Holschuh

Re: Naming of network devices - how to improve it in buster

[Adam Borowski]

On Sat, Jul 15, 2017 at 10:30:59PM +0200, Guus Sliepen wrote:
> On Tue, Jul 11, 2017 at 06:04:29PM +0200, Guus Sliepen wrote:
> 
> > This is not impossible to do. I actually have some code to make ifupdown
> > use interface matching, I'm afraid I was too late in the stretch cycle
> > to have a well-tested implementation. I will try to add this early in
> > buster so it can be tested properly and any kinks resolved.
> 
> Initial support for interface matching has been uploaded, so once it
> hits your mirror you can apt-get upgrade to ifupdown 0.8.20 and use it.
> An example to match an interface by MAC address:
> 
> allow-hotplug mac/01:23:45:67:89:ab/=foo
> 
> This will match any interface that has MAC address 01:23:45:67:89:ab,
> and will use the "foo" stanzas to configure it.

Awesome!  This sounds like the best solution so far.

I haven't yet looked at the implementation (did not hit my mirror yet, and
I got other stuff to finish at the moment), but from your description it
sounds like this would fit most use cases.

Especially if you could somehow add "first and only wired/wifi interface in
the system", that doesn't fail in case it is used erroneously when there's
more than one interface after all.  This would fix most of SoC/VM use cases
I've seen "predictable" names fail horribly.

We'd also need something that generates the interfaces file (during d-i?)
using your syntax, but let's have your system tested and finished first.


Big fat kudos!  Add this to the pool of beers I owe you. :þ

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Tue, Jul 11, 2017 at 06:04:29PM +0200, Guus Sliepen wrote:

> This is not impossible to do. I actually have some code to make ifupdown
> use interface matching, I'm afraid I was too late in the stretch cycle
> to have a well-tested implementation. I will try to add this early in
> buster so it can be tested properly and any kinks resolved.

Initial support for interface matching has been uploaded, so once it
hits your mirror you can apt-get upgrade to ifupdown 0.8.20 and use it.
An example to match an interface by MAC address:

allow-hotplug mac/01:23:45:67:89:ab/=foo
iface foo inet dchp
iface foo inet6 auto

auto type/1/2=bar
iface bar inet static
address 192.168.1.1/24

This will match any interface that has MAC address 01:23:45:67:89:ab,
and will use the "foo" stanzas to configure it. It will also match the
second Ethernet interface (whose /sys/class/net/interfaces/$IFACE/type
file contains the line "1") and bring it up using the "bar" stanza.
Details are in the interfaces(5) manpage.

You can also use pattern matching on the ifup and ifdown command line.
You cannot use pattern matching in "iface" stanzas (yet).

The reason I used the / is that this is, as far as I know, the only
character that is never allowed in interface names on Linux. On that
note, the above examples will not work on Hurd and FreeBSD, support for
pattern matching on those platforms besides just the interface name will
follow later.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Sat, 2017-07-15 at 07:46 +0200, Tollef Fog Heen wrote:
> Doesn't something like:
> 
> [Unit]
> Description=My hook for foo.link
> After=foo.link
> BindsTo=foo.link
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/local/sbin/whatever
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=multi-user.target
> 
> work to hook into when a link unit is activated?
> 
> (Or just a Wants and Before in the foo.link unit)

When I discovered .link and .network files the first thing I looked up
in the doco was whether that sort of thing was possible.  I decided it
wasn't and wrote it off as useless for me.

Now you've made me check for real.  After setting up the unit files you
suggested I get this message in journalctl:

  Failed to add dependency on foo.link, ignoring: Invalid argument

So now I'm fairly convinced the above isn't a thing.  systemd unit
files and udev unit files live in two different worlds - they can't
refer to each other.

That aside, it wouldn't work for my most advance use case anyway.  My
issue is I have boxes literally 1000's of km's away.  Occasionally it
all goes wrong, the only way to fix it is ssh in but "all" includes the
internet connection.

My fix was to detect when a mobile phone was plugged in via USB, then
create a vpn connection home. This is all doable with a few lines in
/etc/network/interfaces - the hard bit is detecting when some random
USB device is a mobile phone.  Standard udev rules can't do it, and so
systemd.link being less powerful doesn't have a hope.  This isn't a
reflection on either of them really - it's a very specialised use case.
  However, I do expect them to provide an escape route.  Udev does - it
can run a program to decide.  systemd.link can't.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Luca Capello]

Hi there,

On Fri, 14 Jul 2017 23:55:09 -0400, Anthony DeRobertis wrote:
> On 07/11/2017 03:08 PM, Nikolaus Rath wrote:
> > 
> > I wonder if anyone actually uses /dev/disk/by-path?
> 
> It's useful for a quick "ls -l /dev/disk/by-path | grep 'sda$;" to figure
> out which port a disk is plugged into. I'm sure there are other ways,
> probably better ones... but that one is easy to remember when I've been
> paged by a disk failure.

Fully agree, which is the reason at work we decided to use names as in
/dev/disk/by-path for disks in ZFS pools, it is easier then to match a
failed disk when needed to replace it.

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Ian Campbell]

On Sat, 2017-07-15 at 10:46 +0200, Marc Haber wrote:
> On Thu, 13 Jul 2017 09:36:58 -0700, Josh Triplett
>  wrote:
> >But if you run into a command that accepts filenames but for which
> >bash-completion doesn't complete filenames, *please* report it as a
> bug
> >on the package providing the bash completions for that command.
> 
> To have it end up like #685223?

One (or even multiple) bad experience(s) does not invalidate the
recommendation to file bugs when you find them. Leaving aside whether
or not #685223 is representative of the corpus of such bugs as a whole,
if everyone took such a defeatist attitude towards the possibility of
bugs being fixed then no bugs would ever be filed and the quality of
Debian would be crap.

Ian.

Re: Naming of network devices - how to improve it in buster

[Tollef Fog Heen]

]] Marc Haber 

> On Thu, 13 Jul 2017 19:37:52 +0200, Tollef Fog Heen 
> wrote:
> >]] Marc Haber 
> >> My finger memory will still type tcpdump -i eth0 before the brain can
> >> intervene ten years from now.
> >
> >In that particular case, I'll recommend you either leaving out the -i
> >switch completely or just doing `-i any`.  I find it's rare I care about
> >what interface traffic happens on.  YMMV, of course.
> 
> As a general paranoid type of guy, my foot nails curl up when I see a
> tcpdump command line without -i. I don't know where this originates
> from. Did tcpdump support the "listen on all interfaces" semantics
> without -i from the beginning?

I don't think it listens on all interfaces without -i, it just listens
on the first one (I think the first one with a configured address, which
in the trivial case is the one you want).  I don't know why it tickles
your spider sense to run it without -i.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Naming of network devices - how to improve it in buster

[Marc Haber]

On Thu, 13 Jul 2017 09:36:58 -0700, Josh Triplett
 wrote:
>But if you run into a command that accepts filenames but for which
>bash-completion doesn't complete filenames, *please* report it as a bug
>on the package providing the bash completions for that command.

To have it end up like #685223?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Naming of network devices - how to improve it in buster

[Marc Haber]

On Thu, 13 Jul 2017 19:37:52 +0200, Tollef Fog Heen 
wrote:
>]] Marc Haber 
>> My finger memory will still type tcpdump -i eth0 before the brain can
>> intervene ten years from now.
>
>In that particular case, I'll recommend you either leaving out the -i
>switch completely or just doing `-i any`.  I find it's rare I care about
>what interface traffic happens on.  YMMV, of course.

As a general paranoid type of guy, my foot nails curl up when I see a
tcpdump command line without -i. I don't know where this originates
from. Did tcpdump support the "listen on all interfaces" semantics
without -i from the beginning?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Naming of network devices - how to improve it in buster

[Tollef Fog Heen]

]] Russell Stuart 

> As for *.link files, syntactically they like all systemd stuff are a
> huge improvement on what came before them.  But the old ugly udev rules
> have one thing over them - they provide hooks for scripts to cover
> cases they haven't thought of.  Scripts seem to be an anathema to the
> author's of systemd.  While that remains true they will never be able
> to replace udev rules in all cases.

Doesn't something like:

[Unit]
Description=My hook for foo.link
After=foo.link
BindsTo=foo.link

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/whatever
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

work to hook into when a link unit is activated?

(Or just a Wants and Before in the foo.link unit)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Naming of network devices - how to improve it in buster

[Anthony DeRobertis]

On 07/14/2017 08:01 PM, Russell Stuart wrote:

(b) Those who enter the debian device names manually into config
 files, and have machines that network device names even though
 no one armed with a screw driver has been near the thing.
 These people would very much care.  I was asking whether they
 exist.  So far I've seen person say they are one.


Then let me add myself to that list. I have a couple of firewall-routers 
at work, which have both onboard and PCI Ethernet cards. The onboard and 
PCI cards use chips from different companies, thus different drivers. So 
whether the first onboard port or the first PCI port becomes eth0 
(according to the kernel) depends on which module loads/initializes 
first. That changes each boot. (Or at least it did last time I checked).


I think the same is true for the mid-tower at home that's my home server 
& firewall—I wanted more ports, so I added a card. So the kernel order 
will again depend on module load/init order.


However, the new fixed names don't matter to me—I've always set custom 
names (not just on these machines, but most machines with multiple 
NICs). I rename the interfaces things like "lan", "dmz", "comcast", 
"verizon", etc. depending on what's connected to the port.


OTOH, my laptop runs Network Manager. I don't really care what the 
interfaces are called there, or if they're stable. Though it's a slight 
pain when I need to troubleshoot something and am faced with a long USB 
WiFi adapter interface name. (Actually, I set up teaming in Network 
Manager, which seems to require stable names hard-coded in the JSON 
config field—so this isn't quite true any longer. But let's ignore this, 
as I presume it's either due to me missing something or a feature that 
isn't yet 100% done in Network Manager)

Re: Naming of network devices - how to improve it in buster

[Anthony DeRobertis]

On 07/11/2017 03:08 PM, Nikolaus Rath wrote:


I wonder if anyone actually uses /dev/disk/by-path?


It's useful for a quick "ls -l /dev/disk/by-path | grep 'sda$;" to 
figure out which port a disk is plugged into. I'm sure there are other 
ways, probably better ones... but that one is easy to remember when I've 
been paged by a disk failure.


Also useful to make sure all the ports on an array are being e.g., 
monitored, even after changing a disk (which of course changes the 
/dev/disk/by-id/). Of course, a lot of times just doing all devices 
instead makes sense.

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Fri, 2017-07-14 at 18:31 -0700, Russ Allbery wrote:
> I didn't think anyone was claiming they would, so I'm not sure why
> you felt like it was necessary to say this.

It's the same reason you feel like it was necessary to say this, I
guess:

On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote:
> I just also don't particularly care; I've stopped using ifupdown and
> am using *.link units for network configuration

How is you stopping using ifupdown relevant to interface renaming?  It
isn't.  Nonetheless I find it interesting to learn how others solve the
same problems I face, and appreciated you taking the time to make the
comment.  But your approach doesn't work for me and I thought others
might be interested to know why that is so.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Russ Allbery]

Russell Stuart  writes:
> On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote:

>> Right, I'm completely happy with the current behavior.  I have no
>> objections to the change.  I just also don't particularly care; I've
>> stopped using ifupdown and am using *.link units for network
>> configuration, which makes all of this trivial and uninteresting and
>> means I don't care in the slightest what names are assigned to
>> interfaces.

> Which means that while true, this was largely irrelevant:

It was only relevant in that you had said that you suspected the root
problem that people are attempting to solve here was a non-problem because
devices always got consistent names anyway.  This isn't true in my
experience, and I wanted to be sure that you knew that.

The rest of the discussion is about *how* to give devices consistent names
by default.  I have no particular opinion on that, since I do that with
systemd using *.link or *.network files, which works great, which I would
recommend to anyone else, and which makes the whole thing a non-issue as
far as I'm concerned.

I'm happy to bow out of the process of consensus on how to solve
consistent naming for all the people who don't want to use the systemd
facility that handles this.

> As for *.link files, syntactically they like all systemd stuff are a
> huge improvement on what came before them.  But the old ugly udev rules
> have one thing over them - they provide hooks for scripts to cover cases
> they haven't thought of.  Scripts seem to be an anathema to the author's
> of systemd.  While that remains true they will never be able to replace
> udev rules in all cases.

I didn't think anyone was claiming they would, so I'm not sure why you
felt like it was necessary to say this.  Lest there be any doubt, I of
course agree with your last sentence.

systemd's approach of providing declarative interfaces to do specific
things rather than a rat's nest of shell scripts is a huge feature for me,
personally, but I'm happy to co-exist in the project with people who think
differently.  :)  I do wish we'd learn from that for our maintainer
scripts, though

-- 
Russ Allbery (r...@debian.org)   

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote:
> Right, I'm completely happy with the current behavior.  I have no
> objections to the change.  I just also don't particularly care; I've
> stopped using ifupdown and am using *.link units for network
> configuration, which makes all of this trivial and uninteresting and
> means I don't care in the slightest what names are assigned to
> interfaces.

Which means that while true, this was largely irrelevant:

On Thu, 2017-07-13 at 09:07 -0700, Russ Allbery wrote:
> Er, I saw this all the time without udev persistent naming.  Every
> time we rebooted one of our servers, the four onboard NICs (of which
> we were only using one -- long story, but basically that's just what
> the systems came with out of the box and my employer at the time
> wasn't a big enough customer to customize the hardware) would get
> randomly different ethN device names assigned to them.  That's *why*
> udev persistent naming was so important when we were using ifupdown
> to manage static network configuration on servers.

As I saw it the discussion pertinent to two classes of people:

(a) Those who typed in the device names regularly.  As far as I can
tell those people either don't see kernels interface names changing
or don't care about it.  I gather from the responses here there 
quite a few people fit into this category.

I am sort of one.  I often use my laptop to configure some
recalcitrant device.  I like most don't see the kernel assigned
names change (because as Greg Kroah-Hartmanboth said, it's very
rare), and I wouldn't care if they did change because the are 
managed by Network Manager.  But when I'm doing the "bash (pun
intended) some device into submission" thing I use a USB dongle
which I have to manually configure and I detest having to enter
the new scheme's 16 character interface name multiple times.

(b) Those who enter the debian device names manually into config
files, and have machines that network device names even though
no one armed with a screw driver has been near the thing.
These people would very much care.  I was asking whether they
exist.  So far I've seen person say they are one.

To put it another way: there are a lot of opinions being expressed
here, but I suspect most aren't coming from people with skin in the
game.

As for *.link files, syntactically they like all systemd stuff are a
huge improvement on what came before them.  But the old ugly udev rules
have one thing over them - they provide hooks for scripts to cover
cases they haven't thought of.  Scripts seem to be an anathema to the
author's of systemd.  While that remains true they will never be able
to replace udev rules in all cases.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Fri, 2017-07-14 at 11:20 -0300, Henrique de Moraes Holschuh wrote:
> MOST PCI/PCIe NICs indeed use "ethX", etc.  But the naming scheme
> really is device driver-specific, and the "default" name used by a
> driver is considered part of the kernel stable ABI, and cannot be
> changed on the kernel side unless it is done opt-in at kernel config
> time (kconfig) or at boot time (kernel command line, device tree,
> etc).

Which is a PITA.  Even though udev does it's best to work around it,
the advice "don't clash with the kernel's naming scheme" is excellent
advice.  It's just a shame the kernel doesn't have a well defined
naming scheme, so it's impossible to follow in the general case.

The funny thing is the despite all the heat generated by this
persistent network interface discussion, it's not a huge problem
because the tools exists to work around it.  You just have to know
where to look.

What I do get regularly bitten by is other devices changing their
names, in particular tty's coming back as different names when someone
reconnects a USB cable.  If there is a general, scriptable way around
that problem that means I don't have to say "reboot the box" I haven't
found it.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Tom H]

On Fri, Jul 14, 2017 at 10:20 AM, Henrique de Moraes Holschuh
 wrote:
> On Fri, 14 Jul 2017, Tom H wrote:


>> The classic naming scheme for network interfaces applied by the kernel
>> is to simply assign names beginning with "eth0", "eth1", ... to all
>> interfaces as they are probed by the drivers. As the driver probing is
>
> Unfortunately, this is incorrect.

It's most likely written by Lennart so you should take it up with him.


> MOST PCI/PCIe NICs indeed use "ethX", etc. But the naming scheme really
> is device driver-specific, and the "default" name used by a driver is
> considered part of the kernel stable ABI, and cannot be changed on the
> kernel side unless it is done opt-in at kernel config time (kconfig) or
> at boot time (kernel command line, device tree, etc).
>
> That said, most consumer devices nowadays are handled by drivers that
> will use either ethX or wlanX by default.
>
>> generally not predictable for modern technology this means that as soon
>> as multiple network interfaces are available the assignment of the names
>> "eth0", "eth1" and so on is generally not fixed anymore and it might
>> very well happen that "eth0" on one boot ends up being "eth1" on the
>> next.
>
> Correct, in the general case.

Re: Naming of network devices - how to improve it in buster

[Russ Allbery]

Vincent Bernat  writes:
>  ❦ 13 juillet 2017 13:55 -0700, Russ Allbery  :

>> Yeah, we were using FAI, but I believe that's the basic mechanism we
>> were using and then found a way to use it to generate the udev rule to
>> do persistent naming.

> This is a perfect use case for the new udev. It would have provided you
> with reproducible names on your fleet of hosts without any tweaking.

Right, I'm completely happy with the current behavior.  I have no
objections to the change.  I just also don't particularly care; I've
stopped using ifupdown and am using *.link units for network
configuration, which makes all of this trivial and uninteresting and means
I don't care in the slightest what names are assigned to interfaces.

-- 
Russ Allbery (r...@debian.org)   

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Fri, 14 Jul 2017, Tom H wrote:
> > I've never seen the kernel vary the order it enumerates a PCI bus.

It doesn't, the last time it changed was on 2.4->2.6.

OTOH, *driver probe* ordering can and does change, especially when
device probes are being done in parallel.  It is best to not get bus
enumeration (and even device endpoint enumeration) confused with device
*registration* by kernel drivers.

> For PCI Express; for all I know, other technologies might enumerate
> differently or change the enumeration method with different driver
> versions.

Most buses are stable as far as enumeration goes: we don't have HBAs and
endpoints being renumbered across boots at all for PCI and PCIe and even
USB.

But bus device enumeration is separate from device register ordering.

> Per driver. There's no guarantee that the kernel will load the drivers
> in the same order at boot. There was even a (specific) note in one of

Indeed.  Unless you add modules for which you care about the load order
to /etc/modules.  Those are staticaly loaded first (obeying dependencies
by depmod, though) even by the initramfs.  It has been supported for a
decade or more.

That *still* won't help for some drivers, where parallel *device* probes
are done AND device answer speed mandates which one will register first.
This does *not* apply to PCI/PCIe NICs handled by the same kernel
driver, but it very likely applies to USB for example.

> The classic naming scheme for network interfaces applied by the kernel
> is to simply assign names beginning with "eth0", "eth1", ... to all
> interfaces as they are probed by the drivers. As the driver probing is

Unfortunately, this is incorrect.

MOST PCI/PCIe NICs indeed use "ethX", etc.  But the naming scheme really
is device driver-specific, and the "default" name used by a driver is
considered part of the kernel stable ABI, and cannot be changed on the
kernel side unless it is done opt-in at kernel config time (kconfig) or
at boot time (kernel command line, device tree, etc).

That said, most consumer devices nowadays are handled by drivers that
will use either ethX or wlanX by default.

> generally not predictable for modern technology this means that as soon
> as multiple network interfaces are available the assignment of the names
> "eth0", "eth1" and so on is generally not fixed anymore and it might
> very well happen that "eth0" on one boot ends up being "eth1" on the
> next.

Correct, in the general case.

-- 
  Henrique Holschuh

Re: Naming of network devices - how to improve it in buster

[Vincent Bernat]

 ❦ 13 juillet 2017 13:55 -0700, Russ Allbery  :

>>> The workaround was a bunch of bullshit in our install process to try to
>>> figure out which NIC got the DHCP response and then pin that one to
>>> eth0 for subsequent boots.  (Which is basically what udev persistent
>>> naming did.)
>
>> At least when you netboot there's a protocol supported by PXELINUX to
>> pass a BOOTIF= option to the kernel with the MAC address of the NIC that
>> performed the PXE boot. And d-i is supposed to then DHCP on that
>> particular interface. But if that all is properly persisted onto the
>> final system without intervention, that I don't know[1].
>
> Yeah, we were using FAI, but I believe that's the basic mechanism we were
> using and then found a way to use it to generate the udev rule to do
> persistent naming.

This is a perfect use case for the new udev. It would have provided you
with reproducible names on your fleet of hosts without any tweaking.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Tom H]

On Thu, Jul 13, 2017 at 6:14 AM, Russell Stuart
 wrote:
> On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote:
>>
>> Stateless "/etc".
>>
>> Systems with multiple NICs where the order in which they're
>> recognized by the kernel can vary.
>
> I asked for a person.

You raised more than one point. I was replying to "I still don't
understand what use case the current scheme is aimed at."

I don't know of a person who types the weird new names. I rename all
my NICs "enX". But I don't think that many people end up with the
"en48e244f61c1b" that you mentioned (it would anyway be
"enx48e244f61c1b" not "en48e244f61c1b"). I'd expect the more common
variants to be "enoX", "ensX", and "enpXsY".


> I guess I really asking for a use case.
> "Stateless /etc" isn't either.

Why isn't "stateless /etc" a use-case?! Red Hat controls udev
development. It or its customers might want to have such systems.


> I've never seen the kernel vary the order it enumerates a PCI bus.

It's happened to me. It's happened to ex-colleagues. When there isn't
a file under "/etc" to map NIC name to NIC MAC address.


> This isn't an accident. Quoting "According to: "PCI Express System
> Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY
> DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743":
>
> The specification states that the enumeration software must
> perform a depth-first search, so before proceeding to discover
> additional functions/ devices on bus 0, it must proceed to search
> bus 1.

For PCI Express; for all I know, other technologies might enumerate
differently or change the enumeration method with different driver
versions.

and

Per driver. There's no guarantee that the kernel will load the drivers
in the same order at boot. There was even a (specific) note in one of
the RHEL 5 release notes about systems with NICs using both e1000 and
e1000e being enumerated in a different order.

>From 
>https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
:

The classic naming scheme for network interfaces applied by the kernel
is to simply assign names beginning with "eth0", "eth1", ... to all
interfaces as they are probed by the drivers. As the driver probing is
generally not predictable for modern technology this means that as soon
as multiple network interfaces are available the assignment of the names
"eth0", "eth1" and so on is generally not fixed anymore and it might
very well happen that "eth0" on one boot ends up being "eth1" on the
next.

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Thu, 2017-07-13 at 09:07 -0700, Russ Allbery wrote:
> Er, I saw this all the time without udev persistent naming.  Every
> time we rebooted one of our servers, the four onboard NICs (of which
> we were only using one -- long story, but basically that's just what
> the systems came with out of the box and my employer at the time
> wasn't a big enough customer to customize the hardware) would get
> randomly different ethN device names assigned to them.  That's *why*
> udev persistent naming was so important when we were using ifupdown
> to manage static network configuration on servers.

Fair enough.  So now I have my example.

Possibly a compromise would be not to assign persistent names if you
have to use the mac address in the name.  I think it's only 73-usb-net-
by-mac.rules that does it this way.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Russ Allbery]

Philipp Kern  writes:
> On 13.07.2017 18:07, Russ Allbery wrote:

>> The workaround was a bunch of bullshit in our install process to try to
>> figure out which NIC got the DHCP response and then pin that one to
>> eth0 for subsequent boots.  (Which is basically what udev persistent
>> naming did.)

> At least when you netboot there's a protocol supported by PXELINUX to
> pass a BOOTIF= option to the kernel with the MAC address of the NIC that
> performed the PXE boot. And d-i is supposed to then DHCP on that
> particular interface. But if that all is properly persisted onto the
> final system without intervention, that I don't know[1].

Yeah, we were using FAI, but I believe that's the basic mechanism we were
using and then found a way to use it to generate the udev rule to do
persistent naming.

-- 
Russ Allbery (r...@debian.org)   

Re: Naming of network devices - how to improve it in buster

[Philipp Kern]

On 13.07.2017 18:07, Russ Allbery wrote:
> The workaround was a bunch of bullshit in our install process to try to
> figure out which NIC got the DHCP response and then pin that one to eth0
> for subsequent boots.  (Which is basically what udev persistent naming
> did.)

At least when you netboot there's a protocol supported by PXELINUX to
pass a BOOTIF= option to the kernel with the MAC address of the NIC that
performed the PXE boot. And d-i is supposed to then DHCP on that
particular interface. But if that all is properly persisted onto the
final system without intervention, that I don't know[1].

Kind regards
Philipp Kern

[1] Although I feel like I should.



signature.asc
Description: OpenPGP digital signature

Re: Naming of network devices - how to improve it in buster

[Alex Muntada]

Nikolaus Rath:

> I wonder if anyone actually uses /dev/disk/by-path?

We used it at work to filter guest LVM VGs out of libvirt hosts:

# grep by-path /etc/lvm/lvm.conf
filter = [ "r|^/dev/disk/by-path/ip-.*-iscsi|" ]

Cheers!
Alex



signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Tollef Fog Heen]

]] Russell Stuart 

> It's not sysadmin's managing fleets of machines.  They need persistent
> names, but you rapidly go insane if the lan NIC isn't named "lan0" or
> something regardless of the machine your platform is running on.  So
> you end up dropping your own customer files in /etc/udev/rules.d
> anyway.  At least that's what I do.

FWIW, I've (almost) never done this.  I generally just use the provided
names and don't really care what they are as long as they don't jump
around.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Naming of network devices - how to improve it in buster

[Tollef Fog Heen]

]] Marc Haber 

> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.

In that particular case, I'll recommend you either leaving out the -i
switch completely or just doing `-i any`.  I find it's rare I care about
what interface traffic happens on.  YMMV, of course.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Naming of network devices - how to improve it in buster

[Josh Triplett]

Adam Borowski wrote:
> Alas, having "bash-completion" installed, while adding some
> context-sensitive completion, also breaks filename completion.

You can always press Alt-/ if you want to use filename completion
unconditionally.

But if you run into a command that accepts filenames but for which
bash-completion doesn't complete filenames, *please* report it as a bug
on the package providing the bash completions for that command.

Re: Naming of network devices - how to improve it in buster

[Marc Haber]

On Wed, 12 Jul 2017 18:47:18 +0200, Michael Biebl 
wrote:
>Am 12.07.2017 um 17:35 schrieb Marc Haber:
>> My finger memory will still type tcpdump -i eth0 before the brain can
>> intervene ten years from now.
>
>thankfully tcpdump (and lots of other tools) have nice shell completion.
>tcpdump -i  works great her.

Indeed, nice. Didn't know that. Now I'd like to have that on all
servers, which - alas - do not all run Debian.

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Naming of network devices - how to improve it in buster

[Russ Allbery]

Russell Stuart  writes:
> On Thu, 2017-07-13 at 11:21 +, Clinton Roy wrote:

>> Unfortunately, others have (well, not the kernel, but PCI):
>> 
>> https://lists.freedesktop.org/archives/systemd-devel/2017-May/038924.
>> html

> If you plug new hardware devices in then of course things are going to
> change.  The claim really is "I don't change the hardware, I don't
> change the kernel version, but the hardware changes names".  It's hard
> to swallow.  I've never seen it.

Er, I saw this all the time without udev persistent naming.  Every time we
rebooted one of our servers, the four onboard NICs (of which we were only
using one -- long story, but basically that's just what the systems came
with out of the box and my employer at the time wasn't a big enough
customer to customize the hardware) would get randomly different ethN
device names assigned to them.  That's *why* udev persistent naming was so
important when we were using ifupdown to manage static network
configuration on servers.

The workaround was a bunch of bullshit in our install process to try to
figure out which NIC got the DHCP response and then pin that one to eth0
for subsequent boots.  (Which is basically what udev persistent naming
did.)

-- 
Russ Allbery (r...@debian.org)   

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Thu, 2017-07-13 at 11:21 +, Clinton Roy wrote:
> Unfortunately, others have (well, not the kernel, but PCI):
> 
> https://lists.freedesktop.org/archives/systemd-devel/2017-May/038924.
> html

If you plug new hardware devices in then of course things are going to
change.  The claim really is "I don't change the hardware, I don't
change the kernel version, but the hardware changes names".  It's hard
to swallow.  I've never seen it.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Adam Borowski]

On Wed, Jul 12, 2017 at 06:47:18PM +0200, Michael Biebl wrote:
> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain can
> > intervene ten years from now.
> 
> thankfully tcpdump (and lots of other tools) have nice shell completion.
> tcpdump -i  works great her.

Alas, having "bash-completion" installed, while adding some
context-sensitive completion, also breaks filename completion.  In the vast
majority of uses, option names consist of a few characters, while filenames
(with paths) are half of a line or longer.  The choice is obvious to me...

Even worse, filename completion is broken only for commands that have
custom handling in bash-completion, making the Tab key unpredictable.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Naming of network devices - how to improve it in buster

[Clinton Roy]

On Thu, 13 Jul 2017 at 20:15 Russell Stuart 
wrote:

>
> I've never seen the kernel vary the order it enumerates a PCI bus.


Unfortunately, others have (well, not the kernel, but PCI):

https://lists.freedesktop.org/archives/systemd-devel/2017-May/038924.html

cheers,


-- 
-- Clinton Roy, Software Engineer with Bloomberg L.P.

Re: Naming of network devices - how to improve it in buster

[Ben Hutchings]

On Thu, 2017-07-13 at 20:14 +1000, Russell Stuart wrote:
> On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote:
> > Stateless "/etc".
> > 
> > Systems with multiple NICs where the order in which they're
> > recognized by the kernel can vary.
> 
> I asked for a person.  I guess I really asking for a use case. 
> "Stateless /etc" isn't either.
> 
> I've never seen the kernel vary the order it enumerates a PCI bus. 
> This isn't an accident.   Quoting "According to: "PCI Express System
> Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY
> DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743":
> 
> The specification states that the enumeration software must
> perform a depth-first search, so before proceeding to discover
> additional functions/ devices on bus 0, it must proceed to search
> bus 1.
[...]

That does not define the order in which *drivers* are loaded and bound
to devices.  Further, driver binding is no longer serialised in Linux.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Ben Hutchings]

On Tue, 2017-07-11 at 17:05 +0200, Samuel Thibault wrote:
> Simon McVittie, on mar. 11 juil. 2017 15:18:26 +0100, wrote:
> > Network devices are (as far as I know) the only class of device managed by
> > udev that is not backed by a device node, which means udev cannot provide
> > multiple equivalent names for the same device,
> 
> Couldn't that be what should be fixed, i.e. a kernel interface to
> define interface aliases?

Oddly enough, each network interface can already have exactly one
'alias', but it's really more of a label since it can't be used in
place of the name.

It might be possible to implement proper aliases, but they would still
need to comply with the existing name limit in order to be usable with
existing programs.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote:
> Stateless "/etc".
> 
> Systems with multiple NICs where the order in which they're
> recognized by the kernel can vary.

I asked for a person.  I guess I really asking for a use case. 
"Stateless /etc" isn't either.

I've never seen the kernel vary the order it enumerates a PCI bus. 
This isn't an accident.   Quoting "According to: "PCI Express System
Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY
DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743":

The specification states that the enumeration software must
perform a depth-first search, so before proceeding to discover
additional functions/ devices on bus 0, it must proceed to search
bus 1.

I can imagine times where stateless etc is important - like embedded
boxes VM's configured by etcd.  But invariably in those environments
all devices are attached to PCI or similar.  Even if they aren't those
types of environments are managed by highly skilled people striving for
mass produced repeatability.  Tailoring systems to cope with /etc in a
ROM is their day job.  They aren't going to use Debian as it is served
up by netinst.

Personally I don't particularly care one way or the other.  But I've
seen a lot of complaints here about how frustrating the new system is
to use in real life, but I don't recall seeing any about how it helped.
 Maybe I missed it.

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Tom H]

On Thu, Jul 13, 2017 at 12:22 AM, Russell Stuart
 wrote:
>
> I still don't understand what use case the current scheme is aimed at.

Stateless "/etc".

Systems with multiple NICs where the order in which they're recognized
by the kernel can vary.

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Wed, Jul 12, 2017 at 07:16:16PM -0300, Henrique de Moraes Holschuh wrote:

> > Indeed, the best solution would be to never rename the interfaces and
> > simply create aliases / symlinks. Then again, I'm no kernel hacker so I
> > have no idea if that would be feasible.
> 
> ip link set dev eth0 alias foo0

This is not doing anything useful. A link "alias" is merely a free-form
string that you can put a more descriptive informative name in, which is
simply completely ignored in the kernel. So after the above command,
something like "ip link set dev foo0 up" just gives the error "Cannot
find device foo0".

> The obvious thing would be to just tell the kernel to change namespaces
> in the first place (kconfig + command line), and have userspace aware of
> the kernel namespace using sysfs.  Just beware the kernel default would
> be "unspecified" (and not "eth*", etc) because this is not central
> policy in the kernel at all).  I have never understood why this wasn't
> done, since it is absolutely trivial to implement, even if it is a lot
> of busywork (you have to patch each !@#$ network driver).  But you could
> clean up a _LOT_ of crap kernel side while at it, AND create both a
> central point for naming this stuff AND better device grouping, so it
> would be worth the trouble.  And it would be opt-in, default N, and
> detectable from userspace, so that it would not regress anything not
> prepared for it.

That sounds interesting!

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Wed, 2017-07-12 at 17:35 +0200, Marc Haber wrote:
> I'd rather have breakage in this case than having to look for the
> interface every fscking time I need to run tcpdump, or having to
> adapt to an entirely new name schema like lanc0 and lanw0 to not
> stomp in the kernel's name space when using my own naming scheme.
> 
> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.

I still don't understand what use case the current scheme is aimed at.

It's not Network Manager users - they don't care about names.  I know
because I used Network Manager on my laptop.

It's not sysadmin's managing fleets of machines.  They need persistent
names, but you rapidly go insane if the lan NIC isn't named "lan0" or
something regardless of the machine your platform is running on.  So
you end up dropping your own customer files in /etc/udev/rules.d
anyway.  At least that's what I do.

It's not cli user who have plugged in a box and want to configure it
with the keyboard.  Anything attached to a PCI bus is usually
"persistent enough" because something hand crafted can also be hand
maintained if it does change.  As Marc says for devices whose names do
change en48e244f61c1b is not a sane solution. Even just having a
template file in /etc/udev/rules.d to jog the memory on how to assign a
persistent name is a better idea.

So who is the person who actually likes typing en48e244f61c1b?

signature.asc
Description: This is a digitally signed message part

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Wed, 12 Jul 2017, Michael Biebl wrote:
> Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny:
> > On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  > > wrote:
> > 
> > Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > > My finger memory will still type tcpdump -i eth0 before the brain can
> > > intervene ten years from now.
> > 
> > thankfully tcpdump (and lots of other tools) have nice shell completion.
> > tcpdump -i  works great her.
> > 
> > 
> > Agreed. However, I'd still rather deal with names like /dev/sda and eth0
> > than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.
> > 
> > It is kind of like using people's first names as opposed to their Social
> > Security Number (in US) or other form of national identification. I know
> > when I can use the name Matt and I know who it refers to, even if
> > another Matt enters the room. I'm comfortable with eth0 being the name,
> > even when another interface appears.
> > 
> > I completely understand, and largely agree with, the need for persistent
> > naming - but I think we are selling ourselves and our users short by not
> > pressing harder for network interface aliases. It seems to be too useful
> > of a solution for this problem.
> 
> Indeed, the best solution would be to never rename the interfaces and
> simply create aliases / symlinks. Then again, I'm no kernel hacker so I
> have no idea if that would be feasible.

ip link set dev eth0 alias foo0

But don't expect everything to work right with this: it is the same
mechanism that was used for adding "extra IP addresses" when using
braindamaged crap from a decade ago (old ifconfig), so I very much bet
there are going to be stuff misbehaving...

The obvious thing would be to just tell the kernel to change namespaces
in the first place (kconfig + command line), and have userspace aware of
the kernel namespace using sysfs.  Just beware the kernel default would
be "unspecified" (and not "eth*", etc) because this is not central
policy in the kernel at all).  I have never understood why this wasn't
done, since it is absolutely trivial to implement, even if it is a lot
of busywork (you have to patch each !@#$ network driver).  But you could
clean up a _LOT_ of crap kernel side while at it, AND create both a
central point for naming this stuff AND better device grouping, so it
would be worth the trouble.  And it would be opt-in, default N, and
detectable from userspace, so that it would not regress anything not
prepared for it.

-- 
  Henrique Holschuh

Re: Naming of network devices - how to improve it in buster

[Michael Biebl]

Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny:
> 
> 
> On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  > wrote:
> 
> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain can
> > intervene ten years from now.
> 
> thankfully tcpdump (and lots of other tools) have nice shell completion.
> tcpdump -i  works great her.
> 
> 
> Agreed. However, I'd still rather deal with names like /dev/sda and eth0
> than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.
> 
> It is kind of like using people's first names as opposed to their Social
> Security Number (in US) or other form of national identification. I know
> when I can use the name Matt and I know who it refers to, even if
> another Matt enters the room. I'm comfortable with eth0 being the name,
> even when another interface appears.
> 
> I completely understand, and largely agree with, the need for persistent
> naming - but I think we are selling ourselves and our users short by not
> pressing harder for network interface aliases. It seems to be too useful
> of a solution for this problem.

Indeed, the best solution would be to never rename the interfaces and
simply create aliases / symlinks. Then again, I'm no kernel hacker so I
have no idea if that would be feasible.
I guess Ben is (one of) the most qualified to answer that.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  wrote:

> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain can
> > intervene ten years from now.
>
> thankfully tcpdump (and lots of other tools) have nice shell completion.
> tcpdump -i  works great her.
>
>
Agreed. However, I'd still rather deal with names like /dev/sda and eth0
than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.

It is kind of like using people's first names as opposed to their Social
Security Number (in US) or other form of national identification. I know
when I can use the name Matt and I know who it refers to, even if another
Matt enters the room. I'm comfortable with eth0 being the name, even when
another interface appears.

I completely understand, and largely agree with, the need for persistent
naming - but I think we are selling ourselves and our users short by not
pressing harder for network interface aliases. It seems to be too useful of
a solution for this problem.

-m

Re: Naming of network devices - how to improve it in buster

[Michael Biebl]

Am 12.07.2017 um 17:35 schrieb Marc Haber:
> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.

thankfully tcpdump (and lots of other tools) have nice shell completion.
tcpdump -i  works great her.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Naming of network devices - how to improve it in buster

[Marc Haber]

On Tue, 11 Jul 2017 15:20:41 +0200, Michael Biebl 
wrote:
>Am 11.07.2017 um 12:14 schrieb Guus Sliepen:
>> Ok, it should be clear now that the new way of naming interfaces is not
>> ideal, but the older ways weren't either. Let's have a look at what we
>> want:
>> 
>> - A simple name for systems with a single Ethernet and/or Wireless
>>   interface (the simple desktop/laptop scenario).
>
>How would you determine that a system will only ever have a single
>interface?

I'd rather have breakage in this case than having to look for the
interface every fscking time I need to run tcpdump, or having to adapt
to an entirely new name schema like lanc0 and lanw0 to not stomp in
the kernel's name space when using my own naming scheme.

My finger memory will still type tcpdump -i eth0 before the brain can
intervene ten years from now.

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Naming of network devices - how to improve it in buster

[Ian Jackson]

Nikolaus Rath writes ("Re: Naming of network devices - how to improve it in 
buster"):
> I wonder if anyone actually uses /dev/disk/by-path?

$ grep path /etc/fstab
/dev/disk/by-path/pci-:3b:00.0-platform-rtsx_pci_sdmmc.0-part1/media/sd 
  autorw,user,noauto 0 0
$

^ from my laptop.

Ian.

Re: Naming of network devices - how to improve it in buster

[Harald Dunkel]

On Tue, 11 Jul 2017 15:20:41 +0200
Michael Biebl  wrote:

> Am 11.07.2017 um 12:14 schrieb Guus Sliepen:
> > Ok, it should be clear now that the new way of naming interfaces is not
> > ideal, but the older ways weren't either. Let's have a look at what we
> > want:
> > 
> > - A simple name for systems with a single Ethernet and/or Wireless
> >   interface (the simple desktop/laptop scenario).  
> 
> How would you determine that a system will only ever have a single
> interface?
> 

The user knows.

I think that's the major problem with these reproducible interface
names: Debian never gave the user a choice between the old and the
new names.


Regard
Harri

Re: Naming of network devices - how to improve it in buster

[Nikolaus Rath]

On Jul 11 2017, Simon McVittie  wrote:
> On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote:
>> I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
>> we need it for network devices?
>
> We do have stable names for disks: look in /dev/disk/by-* and you'll see
> a bewildering variety of ways to refer to the same disk or partition.

I wonder if anyone actually uses /dev/disk/by-path?

> The thing that is different for network devices is that network
> devices are not files (device nodes), so udev cannot create a symlink
> /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever.
> Network devices are (as far as I know) the only class of device managed by
> udev that is not backed by a device node, which means udev cannot provide
> multiple equivalent names for the same device, and is forced to choose
> exactly one of those names, and rename the device if the chosen name
> is not the kernel-generated one. That is why naming network devices is,
> and has always been, more controversial than naming disks: they are the
> one device class in Linux that violates the Unix design rule-of-thumb
> "everything is a file".
>
> If network devices were files, udev wouldn't have a configurable
> NamePolicy to rename them: it would just provide symlinks for all the
> possible naming policies, and let the sysadmin use any, all or none of
> those names when configuring tools like ifupdown. Unfortunately, that
> isn't possible.

Independent of the current discussion: why not? Is there something that
would prevent the kernel from starting to provide network device nodes
in /dev in some future release?

It seems to me that providing a file in /dev and internally mapping this
to the old device name shouldn't be that big a thing...


Curious,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Tue, Jul 11, 2017 at 01:45:25PM +0200, Bjørn Mork wrote:

> The remaining problem is to make ifupdown do device matching on other
> (and hopefully more stable) attributes than the device name.

This is not impossible to do. I actually have some code to make ifupdown
use interface matching, I'm afraid I was too late in the stretch cycle
to have a well-tested implementation. I will try to add this early in
buster so it can be tested properly and any kinks resolved.

It's not completely trivial to implement since there are many places
where interface names are used (auto , iface , inherits
, and on the commmand line), the kernel allows names like
"eth*", et cetera. And being consistent with other network configuration
systems like NetworkManager and systemd would be nice too.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Tue, Jul 11, 2017 at 10:12 AM, Samuel Thibault 
wrote:

> Matt Zagrabelny, on mar. 11 juil. 2017 09:53:58 -0500, wrote:
> > Relatedly, network device name lengths are limited to the length of
> some
> > arbitrarily-sized struct field in the kernel ABI,
> >
> > Feature request to bump the size of of interface names struct? Any
> reason to
> > not do so?
>
> One reason is that it's already compiled in a lot of applications
> through the IFNAMSIZ and IF_NAMESIZE macros (8155 and 939 results in
> codesearch), so a lot of software would suddently break on interfaces
> with long names until recompiled.
>
>
Thanks for the input.

This particular thread isn't the first time I've heard commentary regarding
the interface name size in the kernel data structure.

I'm not sure what a sensible limit is, but 16 (or 15) seems a little on the
small side. Even Cisco has longer names than the Linux limit:

echo -n "TenGigabitEthernet1/0/24" | wc -c
24

-m




> Samuel
>
>

Re: Naming of network devices - how to improve it in buster

[Samuel Thibault]

Matt Zagrabelny, on mar. 11 juil. 2017 09:53:58 -0500, wrote:
> Relatedly, network device name lengths are limited to the length of some
> arbitrarily-sized struct field in the kernel ABI,
> 
> Feature request to bump the size of of interface names struct? Any reason to
> not do so?

One reason is that it's already compiled in a lot of applications
through the IFNAMSIZ and IF_NAMESIZE macros (8155 and 939 results in
codesearch), so a lot of software would suddently break on interfaces
with long names until recompiled.

Samuel

Re: Naming of network devices - how to improve it in buster

[Samuel Thibault]

Simon McVittie, on mar. 11 juil. 2017 15:18:26 +0100, wrote:
> Network devices are (as far as I know) the only class of device managed by
> udev that is not backed by a device node, which means udev cannot provide
> multiple equivalent names for the same device,

Couldn't that be what should be fixed, i.e. a kernel interface to
define interface aliases?

Samuel

Re: Naming of network devices - how to improve it in buster

[Nikolaus Rath]

On Jul 11 2017, Michael Biebl  wrote:
> Am 11.07.2017 um 12:14 schrieb Guus Sliepen:
>> Ok, it should be clear now that the new way of naming interfaces is not
>> ideal, but the older ways weren't either. Let's have a look at what we
>> want:
>> 
>> - A simple name for systems with a single Ethernet and/or Wireless
>>   interface (the simple desktop/laptop scenario).
>
> How would you determine that a system will only ever have a single
> interface?

I don't think it's necessary to do that automatically. On most systems
with multiple interfaces of the same kind, the admin will know about it
and can explicitly enable the extra functionality that is needed to get
stable names in that situation.

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Tue, Jul 11, 2017 at 9:18 AM, Simon McVittie  wrote:

> On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote:
> > I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
> > we need it for network devices?
>
> We do have stable names for disks: look in /dev/disk/by-* and you'll see
> a bewildering variety of ways to refer to the same disk or partition.
>
> The thing that is different for network devices is that network
> devices are not files (device nodes), so udev cannot create a symlink
> /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever.
> Network devices are (as far as I know) the only class of device managed by
> udev that is not backed by a device node, which means udev cannot provide
> multiple equivalent names for the same device, and is forced to choose
> exactly one of those names, and rename the device if the chosen name
> is not the kernel-generated one. That is why naming network devices is,
> and has always been, more controversial than naming disks: they are the
> one device class in Linux that violates the Unix design rule-of-thumb
> "everything is a file".
>

Is there any (technical) reason why there isn't a kernel mechanism for an
"alias" for interfaces that is roughly equivalent to symlinks for files?


> If network devices were files, udev wouldn't have a configurable
> NamePolicy to rename them: it would just provide symlinks for all the
> possible naming policies, and let the sysadmin use any, all or none of
> those names when configuring tools like ifupdown. Unfortunately, that
> isn't possible.
>
> Relatedly, network device name lengths are limited to the length of some
> arbitrarily-sized struct field in the kernel ABI,


Feature request to bump the size of of interface names struct? Any reason
to not do so?

I know that kernel solutions to our problems isn't a quick fix, but it
seems that having interface aliases would allow both camps to be happy.

Sorry if the answers to these questions is obvious.

-m

Re: Naming of network devices - how to improve it in buster

[Simon McVittie]

On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote:
> I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
> we need it for network devices?

We do have stable names for disks: look in /dev/disk/by-* and you'll see
a bewildering variety of ways to refer to the same disk or partition.

The thing that is different for network devices is that network
devices are not files (device nodes), so udev cannot create a symlink
/dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever.
Network devices are (as far as I know) the only class of device managed by
udev that is not backed by a device node, which means udev cannot provide
multiple equivalent names for the same device, and is forced to choose
exactly one of those names, and rename the device if the chosen name
is not the kernel-generated one. That is why naming network devices is,
and has always been, more controversial than naming disks: they are the
one device class in Linux that violates the Unix design rule-of-thumb
"everything is a file".

If network devices were files, udev wouldn't have a configurable
NamePolicy to rename them: it would just provide symlinks for all the
possible naming policies, and let the sysadmin use any, all or none of
those names when configuring tools like ifupdown. Unfortunately, that
isn't possible.

Relatedly, network device name lengths are limited to the length of some
arbitrarily-sized struct field in the kernel ABI, which is why some of
the names udev can generate are so cryptic - they have to pack enough
information to uniquely identify a device into a very small space. Again,
compare with disks, where the names can be as long as you like.

As long as the kernel represents network devices as some unique network
thing that is not a device node in the filesystem, how to name them is
always going to be an ugly compromise, and someone is always going to be
upset by the default.

Happily, there is enough configuration that those with Strong Opinions
can name their network devices in any way of their choice, with one
notable exception: names from the kernel's various namespaces (eth0,
wlan1, wwan2) can only be reliable if no renaming at all is taking
place (which is one of the options available in configuration).

> For static network configurations on systems with multiple interfaces,
> the correct and only logical place for the device association is with
> the rest of the network configuration. If you use NetworkManager, then
> it is up to NetworkManager to match it with a specific network device -
> if required.  The rest of the system does not need to care.

This seems a good plan. NetworkManager and systemd-networkd (what I
personally use on laptops/desktops and servers, respectively) both have
approximately this approach.

> The remaining problem is to make ifupdown do device matching on other
> (and hopefully more stable) attributes than the device name.

... or alternatively, not use ifupdown, which was designed for a
rather different era of networking, in situations where it's unsuitable?

ifupdown served us well for many years as a competitor to Red Hat
sysconfig and SUSE YAST, but those other distributions have moved
on and perhaps so should we. Maybe it's time to admit that using a
Debian-specific network configuration format/infrastructure by default[1]
has become more bug than feature?

S

[1] For desktop systems, ifupdown is already only arguably the default:
if debian-installer is installing NetworkManager, it configures
ifupdown to only bring up lo so that NetworkManager can do the rest;
but our default init system (systemd) would bring up lo anyway,
so ifupdown is redundant. Subsequently replacing pid 1 with sysvinit
is of course supported, but anyone who is contemplating doing so
had better know what they are doing, to an extent where defaults are
not entirely relevant.

Re: Naming of network devices - how to improve it in buster

[Michael Biebl]

Am 11.07.2017 um 12:14 schrieb Guus Sliepen:
> Ok, it should be clear now that the new way of naming interfaces is not
> ideal, but the older ways weren't either. Let's have a look at what we
> want:
> 
> - A simple name for systems with a single Ethernet and/or Wireless
>   interface (the simple desktop/laptop scenario).

How would you determine that a system will only ever have a single
interface?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Naming of network devices - how to improve it in buster

[Harald Dunkel]

On Tue, 11 Jul 2017 12:14:59 +0200
Guus Sliepen  wrote:

> 
> So, what can we do to improve the situation and get the best of both
> worlds? 
> 

systemd.link(5) describes a NamePolicy option for interface names.
I would suggest to introduce a new policy "keep" to stick with 
the native interface names assigned by the kernel ("INTERFACE",
see "udevadm info /sys/class/net/eth0", for example).

Advantages:

- its easy to configure (much better than using kernel command 
  line options
- easy to implement (hopefully)
- you can still have the reproducible interface names, even if you 
  have only one NIC

Please note that systemd.link is read by udev, i.e. it is not bound
to systemd.


Regards
Harri

Re: Naming of network devices - how to improve it in buster

[Bjørn Mork]

Guus Sliepen  writes:

> Ok, it should be clear now that the new way of naming interfaces is not
> ideal, but the older ways weren't either. Let's have a look at what we
> want:
>
> - A simple name for systems with a single Ethernet and/or Wireless
>   interface (the simple desktop/laptop scenario).
> - A consistent naming scheme for interfaces in a system with multiple Ethernet
>   interfaces (the server scenario).
> - Not having interface names change after reboots.

I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
we need it for network devices?

Yes, yes, I know you can screw up your system by configuring a dynamic
device name in /etc/network/interfaces.  But I believe you should be
allowed to.  Just like you can screw up your system by referring to a
dynamic block device name in /etc/fstab.

Leave the kernel network device names alone.  Let them be dynamic.  Just
document that fact.

"stable device name" is not the problem. The problem is associating
configuration with the correct physical device.  Note that this is not
an issue at all until you add some static network configuration. Which
makes it a non-issue for most end user systems, regardless of the number
or type of of network devices.

For static network configurations on systems with multiple interfaces,
the correct and only logical place for the device association is with
the rest of the network configuration. If you use NetworkManager, then
it is up to NetworkManager to match it with a specific network device -
if required.  The rest of the system does not need to care.

The remaining problem is to make ifupdown do device matching on other
(and hopefully more stable) attributes than the device name.



Bjørn

Naming of network devices - how to improve it in buster

[Guus Sliepen]

Ok, it should be clear now that the new way of naming interfaces is not
ideal, but the older ways weren't either. Let's have a look at what we
want:

- A simple name for systems with a single Ethernet and/or Wireless
  interface (the simple desktop/laptop scenario).
- A consistent naming scheme for interfaces in a system with multiple Ethernet
  interfaces (the server scenario).
- Not having interface names change after reboots.

It should work well in the following scenarios:

- Installing on a desktop/laptop.
- Installing on a server.
- Installing in a VM.
- Installing using debootstrap.
- Cloning a system.

The pros/cons with the various solutions:

- State file:
  - PRO: Once an interface has a name, it keeps that name on the same
system.
  - CON: Does not work well when debootstrapping (it can copy the host
config, when the intent is to run the deboostrapped filesystem on a
different machine).
  - CON: Does not work well when cloning a system.

  The issue in both CONs is that eth0 for example is bound to a MAC
  address that is not used in the new system, so the new system gets
  eth1 for its Ethernet interface.

- Stable udev names:
  - PRO: Reliable names when installing on identical machines.
  - PRO: Handles cloning a system well.
  - CON: Can results in overly complex interface names.
  - CON: Does not handle changes in bus topology.

So, what can we do to improve the situation and get the best of both
worlds? 

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature