Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 02/09/2017 à 15:45, Erik Christiansen a écrit :

On 02.09.17 14:49, Didier Kryn wrote:

Le 02/09/2017 à 08:25, Erik Christiansen a écrit :

Looking at "man ifrename", we see:

-u Enable udev output mode. This enables proper integration of ifrename
 in the udev framework, udevd(8) will use ifrename to assign interface
 names present in /etc/iftab. In this mode the output of ifrename can
 be parsed directly by udevd(8) as an IMPORT action. This requires
 udev version 107 or later.

As this appears capable of maintaining static nomenclature for a sane
user interface, in the face of lower level irrationality, there appears
to be no basis for doing other than retaining the higher standard of
udev behaviour.

Not only is it feasible to retain static interface names, using a file
as we theorised on the thread, but that file is /etc/iftab. Simple.


 This is an easier configuration mechanism than editing udev rules.
Nevertheless I bet Udev insists on renaming and will generate an entry in
this file for every newly discovered interface. In Wheezy this could be
disabled by providing a trivial version of
/lib/udev/rules.d/75-persistent-net-generator.rules. I don't see any obvious
method to disable it with newer versions of Udev.

Are you saying that newer versions of udev lack the IMPORT action?
(It's still there on Debian 9.0) The ifrename manpage suggests that it
is a recent improvement. If it is to be removed, then that is yet
another Poetterwank.
No. I don't know the Udev language. I used to trick rules to my 
needs but it was just bricolage. I see that the name of the rules files 
related to network change from version to version and their content 
shrinks. For me this means more and more is done internally, out of 
admin's control. But I might be paranoid; the author deserves that.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Erik Christiansen]

On 02.09.17 14:49, Didier Kryn wrote:
> Le 02/09/2017 à 08:25, Erik Christiansen a écrit :
> > Looking at "man ifrename", we see:
> > 
> > -u Enable udev output mode. This enables proper integration of ifrename
> > in the udev framework, udevd(8) will use ifrename to assign interface
> > names present in /etc/iftab. In this mode the output of ifrename can
> > be parsed directly by udevd(8) as an IMPORT action. This requires
> > udev version 107 or later.
> > 
> > As this appears capable of maintaining static nomenclature for a sane
> > user interface, in the face of lower level irrationality, there appears
> > to be no basis for doing other than retaining the higher standard of
> > udev behaviour.
> > 
> > Not only is it feasible to retain static interface names, using a file
> > as we theorised on the thread, but that file is /etc/iftab. Simple.
> >
> This is an easier configuration mechanism than editing udev rules.
> Nevertheless I bet Udev insists on renaming and will generate an entry in
> this file for every newly discovered interface. In Wheezy this could be
> disabled by providing a trivial version of
> /lib/udev/rules.d/75-persistent-net-generator.rules. I don't see any obvious
> method to disable it with newer versions of Udev.

Are you saying that newer versions of udev lack the IMPORT action?
(It's still there on Debian 9.0) The ifrename manpage suggests that it
is a recent improvement. If it is to be removed, then that is yet
another Poetterwank.

It is a simple matter to use chattr to prevent /etc/iftab being
systemdixed, but it seems not to exist if ifrename has not been
installed and activated, at least in my experience.

> If there is a way to disable automatic new name generation, and since
> Devuan is much about freedom of choice, it would be nice to provide two
> mutually exclusive packages for each of udev, eudev and vdev, one with
> automatic name generation and one without. I insist that there are many
> cases where renaming is pointless and yet a burden when it happens - eg the
> majority of laptops and desktops.

An installer question would perhaps be a light weight interim solution.
But I have nothing against a little extra work to tweak the distro to
suit my needs. A package install and config file population is a cheap
price for a properly working system free of intrusive Poetterwanks.

Erik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 02/09/2017 à 08:25, Erik Christiansen a écrit :

On 21.08.17 01:38, Daniel Reurich wrote:

Hi,

We discussed a few weeks back in a dev meeting whether or not to revert
to jessie like naming scheme for ethernet interfaces by default.

The eudev package (currently found in the experimental repos and at
https://git.devuan.org/devuan-packages/eudev ) utilizes the same logic
like udev does when it comes to interface naming schemes. The patch
appended below would reverse the logic and make it opt-in rather than
opt-out.

This would lead network interface names default to the old "eth0" or
"wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
scheme and not touching anything to get the "eth0" scheme.

To keep these things consistent we should also apply the same patch to
udev as well.

Thoughts??

Looking at "man ifrename", we see:

-u Enable udev output mode. This enables proper integration of ifrename
in the udev framework, udevd(8) will use ifrename to assign interface
names present in /etc/iftab. In this mode the output of ifrename can
be parsed directly by udevd(8) as an IMPORT action. This requires
udev version 107 or later.

As this appears capable of maintaining static nomenclature for a sane
user interface, in the face of lower level irrationality, there appears
to be no basis for doing other than retaining the higher standard of
udev behaviour.

Not only is it feasible to retain static interface names, using a file
as we theorised on the thread, but that file is /etc/iftab. Simple.
This is an easier configuration mechanism than editing udev rules. 
Nevertheless I bet Udev insists on renaming and will generate an entry 
in this file for every newly discovered interface. In Wheezy this could 
be disabled by providing a trivial version of 
/lib/udev/rules.d/75-persistent-net-generator.rules. I don't see any 
obvious method to disable it with newer versions of Udev.


If there is a way to disable automatic new name generation, and 
since Devuan is much about freedom of choice, it would be nice to 
provide two mutually exclusive packages for each of udev, eudev and 
vdev, one with automatic name generation and one without. I insist that 
there are many cases where renaming is pointless and yet a burden when 
it happens - eg the majority of laptops and desktops.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rob van der Putten]

Hi there


On 22/08/17 11:42, Didier Kryn wrote:


Le 22/08/2017 à 09:10, Narcis Garcia a écrit :

persistent-net.rules allows 100% definitive names.



Definitive but with a possible mess. A new eth1 could be created by 
the kernel in the same time eth0 is renamed to eth1 by Udev. The race 
problem pointed by Adam.


AFAIK you can use any name you like in 
/etc/udev/rules.d/70-persistent-net.rules (provided they don't 
conflict). E.G. nic0, nic1, etc. Which would avoid conflicts and provide 
definitive names.



Regards,
Rob


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Erik Christiansen]

On 21.08.17 01:38, Daniel Reurich wrote:
> Hi,
> 
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
> 
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.org/devuan-packages/eudev ) utilizes the same logic
> like udev does when it comes to interface naming schemes. The patch
> appended below would reverse the logic and make it opt-in rather than
> opt-out.
> 
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.
> 
> To keep these things consistent we should also apply the same patch to
> udev as well.
> 
> Thoughts??

Looking at "man ifrename", we see:

-u Enable udev output mode. This enables proper integration of ifrename
   in the udev framework, udevd(8) will use ifrename to assign interface
   names present in /etc/iftab. In this mode the output of ifrename can
   be parsed directly by udevd(8) as an IMPORT action. This requires
   udev version 107 or later.

As this appears capable of maintaining static nomenclature for a sane
user interface, in the face of lower level irrationality, there appears
to be no basis for doing other than retaining the higher standard of
udev behaviour.

Not only is it feasible to retain static interface names, using a file
as we theorised on the thread, but that file is /etc/iftab. Simple.

Erik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 22/08/2017 à 09:10, Narcis Garcia a écrit :

persistent-net.rules allows 100% definitive names.



   Definitive but with a possible mess. A new eth1 could be created by 
the kernel in the same time eth0 is renamed to eth1 by Udev. The race 
problem pointed by Adam.



Didier



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Narcis Garcia]

El 22/08/17 a les 02:48, Alessandro Selli ha escrit:
> On Mon, 21 Aug 2017 at 10:32:43 +0200
> Narcis Garcia  wrote:
> 
> [...]
> 
>> This logic does not guarantee 100% predictable naming (think about
>> removable NICs), but gives enough confort to a sysadmin deals any with
>> situation.
> 
>   If it's not 100% predictable and configurable by the sysadmin then it does
> *not* provide "enough confort", as in an Enterprise environment this means
> 100% certainty that the system comes up with each networking card having
> a definite, assigned name and that everything that depends on networking is
> always going to work fine short of a hardware failure.
>   Randomness is very unwelcome in critical systems and in data centers, where
> even a tiny percentage of random malfunction has to be multiplied by the
> numer of racks and devices that are present to be deemed acceptable.
> 
> 
> Alessandro

Please, differenciate between predictable name and definitive name.
persistent-net.rules allows 100% definitive names.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Sun, 20 Aug 2017 at 22:24:58 -0400
Steve Litt  wrote:

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot.

  What about the numerous cases when you cannot chose what ethernet cards are
going to be fitted inside a computer?  Maybe a specific model was chosen to
comply with warranty terms, or because a specific piece of hardware is
certified in a given scenario, or because what you have is a PCIe card with
multiple NICs built-in, or because the interfaces are embedded in the
motherboard, or because it's not you how buys the hardware...?


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Mon, 21 Aug 2017 at 12:56:24 +0200
Didier Kryn  wrote:

>  In any case the admin must either hack /etc/network/interfaces or 
> the udev rules. But I think this little inconveniency is better than the 
> meaningless device names promoted by Systemd people.

  And the other network cards can stay assured they are not going to be
renamed because of this.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Mon, 21 Aug 2017 at 10:32:43 +0200
Narcis Garcia  wrote:

[...]

> This logic does not guarantee 100% predictable naming (think about
> removable NICs), but gives enough confort to a sysadmin deals any with
> situation.

  If it's not 100% predictable and configurable by the sysadmin then it does
*not* provide "enough confort", as in an Enterprise environment this means
100% certainty that the system comes up with each networking card having
a definite, assigned name and that everything that depends on networking is
always going to work fine short of a hardware failure.
  Randomness is very unwelcome in critical systems and in data centers, where
even a tiny percentage of random malfunction has to be multiplied by the
numer of racks and devices that are present to be deemed acceptable.


Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Mon, 21 Aug 2017 at 09:22:22 +0100
Simon Hobson  wrote:

[...]

> I suppose that one REALLY good way to fix the problem (at least in the
> server & desktop areas) is actually to undo a lot of "progress" and make
> all driver and service initiation strictly linear. Ie, do away with all
> this parallelism and make all drivers be loaded strictly in sequence, one
> after the other, in a defined order. I strongly suspect that it wouldn't
> hugely impact boot times either. Put another way, part of the "problem"
> being "solved" is actually a side effect of "improvements" made elsewhere.

  I see some potential problems with serialization as a panacea for
interface naming.

1) How is a driver supposed to know what "queue number" it has at boot time?
   "The kernel assigns it, maybe dinamically", all right,  how could the
   sysadmin then set his own ethernet-card-driver load order? (Suppose a
   network booted system must configure it's eth0 via DHCP and then load the
   NFS root filesystem out of eth1?)
2) You've got to set timeouts on ethernet drivers loading and initialization
   to avoid network card B sitting indefinitely because network card A got
   stuck; this could increase boot time considerably, expecially if
   networking is required to boot the OS.  And what eth number is B going to
   get if A got stuck?  The same as if A did not get stuck?  Or maybe it's
   going to get A's?
3) If a network card driver fails to load, how are the other ethernet
   interfaces names affected?  Are the following ones named just like it
   loaded fine or does the naming procedure skip the failed interface?
4) What about a hardware card swap, substitution or removal, how can one know
   what effect this will have on the module load sequence and interface
   naming?
5) Network initialization and configuration can in some cases take a long
   time (DHCP, RPC/NFS, Kerberos/NIS/LDAP/SMB and iSCSI are not
   lightning-fast and might be required by other start-up steps, WiFi makes
   things a lot worse of course), so serialization of multiple networking
   interfaces can have a huge impact on start-up time indeed, depending on
   the specific setup.

  In short, networking device naming does not have to depend on load time and
sequence, and it should not.  It must be predictable and configurable, but it
ought to be independend from driver load time and order.  The card's MAC
address should be all that matters and dynamical interface naming should
apply only to unknown hardware that just popped up now or on this boot (and
of course it should assign only names that are not already reserved to
configured network cards, that they are present or not).


Alessandro

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Hendrik Boom]

On Sun, Aug 20, 2017 at 09:30:00PM -0700, Rick Moen wrote:
> Let me try to draw a distinction with some nuance, here:  To the best of
> my knowledge -- and my knowledge might be incomplete or unaware of some
> new developments -- 'spontaneous' network device renaming, just like
> spontaneous mass storage device renaming, happens _only_ following
> admin-initiated hardware reshuffles.

The only time I had a problem with this it was upon an Debian upgrade 
from one release to another.  The easy way to fix the problem was to 
swap the cables at the back of the box.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[info at smallinnovations dot nl]

On 21-08-17 06:30, Rick Moen wrote:

Quoting Steve Litt (sl...@troubleshooters.com):


As a wee lad, my mentors told me never to put two of the same model
NICs in a computer, because which one became eth0 and which became eth1
would be indeterminate from boot to boot.

It's funny you'll say that, and not just because we're both old enough
that advice we got as 'wee lads' would probably have to involve
sliderules.  I'll get back to that, later.


That's horrible, and that *is* solved by the systemd naming scheme.

I find myself in the position of being a little unconvinced about the
extent and seriousness of the problem, even though I don't have
exhaustive data, only a few decades of *ix experience to draw on.
Let me try to draw a distinction with some nuance, here:  To the best of
my knowledge -- and my knowledge might be incomplete or unaware of some
new developments -- 'spontaneous' network device renaming, just like
spontaneous mass storage device renaming, happens _only_ following
admin-initiated hardware reshuffles.

---snip

I do remember this switching of network cards happened spurious on 
SME-Server 8 (a RHEL based SMB distribution for e-mail, fileserver and 
firewall with a webinterface). With other distro's like Suse, Debian, 
Ubuntu and Mandrake i never have seen this happen.


Grtz.

Nick
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Ron]

On Mon, 21 Aug 2017 07:26:04 -0700
Rick Moen  wrote:

> > On Sun, 20 Aug 2017 21:30:00 -0700 Rick Moen 
> > wrote:
> > 
> > > However_, even given that, in my experience any reshuffle USB would
> > > add to the _existing_ devices' node assignments would occur only at
> > > reboot time _if_ you left the USB device plugged in. 
> > 
> > Personal experience: I run an IPCop box as a firewall for my LAN,
> > using three USBtoRJ45 interfaces in an attempt to reduce the
> > motherboard damage from thunderstorms (I live in Darkest Paraguay).
> > 
> > The local electricity system is not all that reliable, and even with a
> > UPS the box gets rebooted several times a week.
> > 
> > In around ten years of use I have never had the problem of USB/NIC
> > assignment changing at reboot, except when I had to replace a
> > burnt-out USBtoRJ45  ;-3(
> 
> Interesting and thank you.  At first, I thought you were going to post
> Yet Another USB Flakiness Story, but it turns out that your NICs have
> _not_ self-reassigned.  Good to know.
> 
> FWIW, when I wrote the above, I actually had in mind mass storage, e.g., 
> a system has /dev/sda on one HBA and /dev/sdb on another, mounts a USB
> mass storage device as /dev/sdc, and then reboots with the USB mass
> storage device plugged in and now finds that the USB device is /dev/sdb
> in-between the two persistent devices with the result that /etc/fstab is
> wrong.  (Probably, the admin curses a blue streak and switches to UUID
> referencing or disk labels.)
> 
> One thing that people definitely _do_ bitch about is USB casual storage
> being (say) /dev/sdc upon one insertion and then later /dev/sdd at the
> next insertin (without a reboot between).  From my perspective, I never
> saw this as a problem.  You just observe the inserted device's node by
> looking at dmesg | tail, su to root, mount device, done.  But the
> new-user people don't like that, and want the process to be automagic.
> Greg Kroah-Hartman justified the whole udev thing to me, claiming it
> needed to be on all Linux systems, on grounds that he wanted his
> daughter to be able to use USB devices without needing to be root.  I
> replied that happily he could do anything for his daughter he wished on
> his _own_ systems, but that his daughter wouldn't be plugging USB
> devices into my servers, so I wasn't especially interested in helping
> her there.

I forgot to precise that the three USBtoRJ45 are the same model, TrendNet 
TU2-ET100.
 
Cheers,
 
Ron.
-- 
Like some infernal monster, still venomous in death, 
 a war can go on killing people for a long time after it’s all over.
 -- Nevil 
Shute Norway

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rick Moen]

Quoting Renaud OLGIATI (ren...@olgiati-in-paraguay.org):

> On Sun, 20 Aug 2017 21:30:00 -0700 Rick Moen 
> wrote:
> 
> > However_, even given that, in my experience any reshuffle USB would
> > add to the _existing_ devices' node assignments would occur only at
> > reboot time _if_ you left the USB device plugged in. 
> 
> Personal experience: I run an IPCop box as a firewall for my LAN,
> using three USBtoRJ45 interfaces in an attempt to reduce the
> motherboard damage from thunderstorms (I live in Darkest Paraguay).
> 
> The local electricity system is not all that reliable, and even with a
> UPS the box gets rebooted several times a week.
> 
> In around ten years of use I have never had the problem of USB/NIC
> assignment changing at reboot, except when I had to replace a
> burnt-out USBtoRJ45  ;-3(

Interesting and thank you.  At first, I thought you were going to post
Yet Another USB Flakiness Story, but it turns out that your NICs have
_not_ self-reassigned.  Good to know.

FWIW, when I wrote the above, I actually had in mind mass storage, e.g., 
a system has /dev/sda on one HBA and /dev/sdb on another, mounts a USB
mass storage device as /dev/sdc, and then reboots with the USB mass
storage device plugged in and now finds that the USB device is /dev/sdb
in-between the two persistent devices with the result that /etc/fstab is
wrong.  (Probably, the admin curses a blue streak and switches to UUID
referencing or disk labels.)

One thing that people definitely _do_ bitch about is USB casual storage
being (say) /dev/sdc upon one insertion and then later /dev/sdd at the
next insertin (without a reboot between).  From my perspective, I never
saw this as a problem.  You just observe the inserted device's node by
looking at dmesg | tail, su to root, mount device, done.  But the
new-user people don't like that, and want the process to be automagic.
Greg Kroah-Hartman justified the whole udev thing to me, claiming it
needed to be on all Linux systems, on grounds that he wanted his
daughter to be able to use USB devices without needing to be root.  I
replied that happily he could do anything for his daughter he wished on
his _own_ systems, but that his daughter wouldn't be plugging USB
devices into my servers, so I wasn't especially interested in helping
her there.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 21/08/2017 à 12:56, Didier Kryn a écrit :

Le 20/08/2017 à 18:57, Renaud (Ron) OLGIATI a écrit :

On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny  wrote:


As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?
Could, but whenever you have to change a NIC after a thunderstorm you 
are buggered...

  Cheers,
  Ron.
That's exactly the most frequent case. There's also the following 
case: you break your computer but not the disk. Instead of making a 
new install on another computer, you just exchange the disks. Your 
network was configured for eth0 but there's no more eth0, udev has 
renamed it eth1, because eth0 is the NIC of the broken computer.


In any case the admin must either hack /etc/network/interfaces or 
the udev rules. But I think this little inconveniency is better than 
the meaningless device names promoted by Systemd people.


Remains the problem of the namespace. Why not use nic0, nic1, etc 
as a namespace for ethernet?


Didier


Sorry, thunderbird messed with citation. The paragraph after the 
signature of Ron is from me.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 20/08/2017 à 18:57, Renaud (Ron) OLGIATI a écrit :

On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny  wrote:


As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?

Could, but whenever you have to change a NIC after a thunderstorm you are 
buggered...
  
Cheers,
  
Ron.
That's exactly the most frequent case. There's also the following 
case: you break your computer but not the disk. Instead of making a 
new install on another computer, you just exchange the disks. Your 
network was configured for eth0 but there's no more eth0, udev has 
renamed it eth1, because eth0 is the NIC of the broken computer.


In any case the admin must either hack /etc/network/interfaces or 
the udev rules. But I think this little inconveniency is better than the 
meaningless device names promoted by Systemd people.


Remains the problem of the namespace. Why not use nic0, nic1, etc 
as a namespace for ethernet?


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Ron]

On Sun, 20 Aug 2017 21:30:00 -0700
Rick Moen  wrote:

> However_, even given that, in my experience any reshuffle
> USB would add to the _existing_ devices' node assignments would occur
> only at reboot time _if_ you left the USB device plugged in. 

Personal experience: I run an IPCop box as a firewall for my LAN, using three 
USBtoRJ45 interfaces in an attempt to reduce the motherboard damage from 
thunderstorms (I live in Darkest Paraguay).

The local electricity system is not all that reliable, and even with a UPS the 
box gets rebooted several times a week.

In around ten years of use I have never had the problem of USB/NIC assignment 
changing at reboot, except when I had to replace a burnt-out USBtoRJ45  ;-3(
 
Cheers,
 
Ron.
-- 
 To succeed, planning alone is insufficient.
 One must improvise as well.
-- Salvor Hardin

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rick Moen]

Quoting marc (marc...@welz.org.za):

> Like Rick I haven't encountered a spontaneous device name 
> re-order in the wild.

Just to be skeptical for a moment of my own wording, I probably 
_slightly_ overstated (at least by implication) what I've observed over
the decades, here:

   I understood that, if you had a motherboard with dual e1000 NICs and
   suddenly added (or removed) a third ethernet port on a PCI-E card,
   whether it was also an e1000 NIC or not, you might expect to get a
   ^^^
  device assignment reshuffle.

On reflection, I'm not sure I've ever seen, say, a server with a pair of
e1000 NICs on the motherboard supplemented by an ethernet card with a
Tigon tg3 chipset.  In my own systems, and the ones I've used at work, 
we've always stuck with a single NIC chipset by preference, just on
instinct.  If you needed a third NIC on a dual-e1000 host, you plugged
in an e1000 card.  

But honestly, I think this whole situation almost never arises in my own
experience.  In business, if you have a situation where dual-NIC
motherboards don't suffice, you typically need a dedicated router, not a
regular Linux host.

I stand by my observation that a machine with multiple copies of the
same NIC, especially (as we find for the last decade or so) they're
integrated into the motherboard, you do _not_ see spontaneous
device-assignment reshuffles.  If it happens, I've never seen it,
anyway.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Simon Hobson]

Edward Bartolo  wrote:

> Therefore, if I were in a position to take decisions I would
> not expect a computer to know what I need. However, a computer should
> have no difficulty processing data. A decent OS should save a map of
> how hardware is connected, somewhat like a hardware tree with all
> points fully defined. That way, if on a future boot, nodeX is not
> found or is replaced with some other hardware, nodeZ, that we assume
> existed before, will continue to be assigned with the same device
> name.

Dunno, there's lots of "what if ?" opportunities there.

What if ... a NIC is seen to appear in a different position in the bus/device 
tree ?
Should it be assumed to be the same device (eg USB NIC plugged into different 
port) and given the same name ? Should it be given a different name as a 
different device ?

What if that device moves (and you think the answer above should be, "it's 
obviously the same device - give it the same name") and a different (new) 
device appears in the old location ? Has the user just upgraded their primary 
NIC (eg got a gigabit dongle instead of a 100M dongle) and wants to use the old 
slower one as a secondary NIC - or have they moved an existing device 
(expecting it to keep the same settings) in order to install* an additional 
device for something new ?

Absent the mind reading module which we haven't invented yet - there is no way 
of knowing and so whichever way we decide to code it will be wrong for some 
instances.

However, for a lot of cases - the existing udev persistent rules method "does 
just what people want".

* Sometimes, I've had to move a USB device in order to be able to install 
another device - some devices are oversize and block adjacent ports so physical 
location matters.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Narcis Garcia]

El 20/08/17 a les 21:53, fsmithred ha escrit:
> On 08/20/2017 10:27 AM, Adam Borowski wrote:
>>
>> * systemd-udev's promise of providing _stable_ names didn't deliver.  They
>>   still change on major kernel upgrades, and sometimes on every boot. 
>>   And their chosen naming is utterly insane (wlxf81a671bcfae, WTF?).
>>   Only systemd proponents still say it's a good idea.
>>
> 
> They change? I thought they were based on which hardware slot they were
> in. I've been ranting about how you have to open the box and look inside
> to predict the names. Have I been wrong all this time?
> 
> Yeah, the name on a usb dongle is insane. I didn't stick with it long
> enough to figure out if that number comes from somewhere or is random.
> 
> fsmithred
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

I suggest:
ethX/wlanX naming BUT:
Based on last MAC byte;
- When MAC ends with :00 -> eth0
- When MAC ends with :01 -> eth1
- When MAC ends with :0A -> eth10
- When MAC ends with :10 -> eth16
* When 2 NICs have same MAC byte (01) -> eth1 & eth1a & ... eth1b
* Anyway, maintain full support of
/etc/udev/rules.d/70-persistent-net.rules

This logic does not guarantee 100% predictable naming (think about
removable NICs), but gives enough confort to a sysadmin deals any with
situation.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Simon Hobson]

Steve Litt  wrote:

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot. That's horrible, and that *is*
> solved by the systemd naming scheme.

Except when it isn't !
In fact, two card of the same type (or rather, using the same driver), is not a 
problem - they use the same driver, and enumeration of devices follows (or is 
supposed) to follow a set order.
When they use different drivers, then there is parallelism in initialisation 
which means it's not determinate which driver gets loaded first and hence which 
device is eth0 and which is eth1.



Adam Borowski  wrote:

>> Why not use a similar mechanism for interface names?  remember which 
>> names were recently used and use them again?
>> 
>> This sounds a lot like the fstab-like proposal, except it 
>> autoconfigures.
> 
> You mean, /etc/udev/rules.d/70-persistent-net.rules which has been removed
> in favour of completely-un-"predictable" names, right?
> 
> It has a very user unfriendly syntax, but it did just what you suggest.

Exactly, THAT problem was solved (in the server and probably desktop spaces) 
many many years ago. SOLVED, nothing to see here, move along please.
It has it's issues, but these are mostly down to hardware being changed and 
installations being cloned - ie situation that involve administrator 
involvement and so an opportunity to fix it at the same time.

I accept that there ARE issues in some cases - especially things like laptops 
with plug in (USB) NICs - but fixing that doesn't need to break everyone else. 
Put another way, yes I can see that there is a problem to be solved, but no, I 
don't think that imposing massive problems on the majority of users is the 
right way to do it.



Rick Moen  wrote:

> I find myself in the position of being a little unconvinced about the
> extent and seriousness of the problem, even though I don't have
> exhaustive data, only a few decades of *ix experience to draw on.
> Let me try to draw a distinction with some nuance, here:  To the best of
> my knowledge -- and my knowledge might be incomplete or unaware of some
> new developments -- 'spontaneous' network device renaming, just like
> spontaneous mass storage device renaming, happens _only_ following
> admin-initiated hardware reshuffles.

Not so.
I recall working on a system a while ago with two different SCSI interfaces - 
basically trying to make a working and usable system from scavenged parts, 
pretty well everything I did in the last 12 years (linux wise) has been using 
"hand me down" hardware that the Windoze server guys had discarded. This was 
around the time that similar discussions were being had about "what's wrong 
with sda, sdb, etc ?". Due to the parallel driver loading issue, it was random 
which interface got it's devices installed first, and so I did have devices 
that would be in random order at boot time - ie some boots would result in my 
"first" drive being sda, other boots it would be sdb.
This was easily fixed (for me) using filesystem labels instead of device names 
- others just accepted the opaque filesystem IDs with those very long and hard 
to type strings (great fun when trying to boot manually in Grub !)

I don't recall exactly that problem with network interfaces, as by the time I 
was working with systems susceptible to it, udev had already fixed it. What I 
do recall was the pain of a two-NIC system where the "active" NIC (only one 
cable plugged in) would be different when booted from an installer disk or live 
distro than when booted from the installed OS.
But that isn't the same thing really

I suppose that one REALLY good way to fix the problem (at least in the server & 
desktop areas) is actually to undo a lot of "progress" and make all driver and 
service initiation strictly linear. Ie, do away with all this parallelism and 
make all drivers be loaded strictly in sequence, one after the other, in a 
defined order. I strongly suspect that it wouldn't hugely impact boot times 
either.
Put another way, part of the "problem" being "solved" is actually a side effect 
of "improvements" made elsewhere.

marc  wrote:

> However, some time ago the authors of the reverse engineered
> nvidia ethernet driver (was it forcedeth?) noticed they had
> decoded the mac address incorrectly and fixed it in a point
> release. For me that meant a headless machine many thousands
> of kilometers away became unreachable as what was eth0 at the
> last reboot now was stuck at eth1_renamed or ens9faefas#*$? or
> whatever it was.
> 
> Point is: In many cases eth0 means "the only network device
> on the system, the one we use to go online" and tieing it
> to a piece of hardware can be problematic too, as on occasion
> it gets replaced - or as per anecdode above, changes
> spontaneously, even though its 

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[marc]

So another vote for keeping the eth0/wlan0 scheme and
not renaming devices in userspace.

Like Rick I haven't encountered a spontaneous device name 
re-order in the wild.

However, some time ago the authors of the reverse engineered
nvidia ethernet driver (was it forcedeth?) noticed they had
decoded the mac address incorrectly and fixed it in a point
release. For me that meant a headless machine many thousands
of kilometers away became unreachable as what was eth0 at the
last reboot now was stuck at eth1_renamed or ens9faefas#*$? or
whatever it was.

Point is: In many cases eth0 means "the only network device
on the system, the one we use to go online" and tieing it
to a piece of hardware can be problematic too, as on occasion
it gets replaced - or as per anecdode above, changes
spontaneously, even though its function does not.

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rick Moen]

Quoting Steve Litt (sl...@troubleshooters.com):

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot.

It's funny you'll say that, and not just because we're both old enough
that advice we got as 'wee lads' would probably have to involve
sliderules.  I'll get back to that, later.

> That's horrible, and that *is* solved by the systemd naming scheme.

I find myself in the position of being a little unconvinced about the
extent and seriousness of the problem, even though I don't have
exhaustive data, only a few decades of *ix experience to draw on.
Let me try to draw a distinction with some nuance, here:  To the best of
my knowledge -- and my knowledge might be incomplete or unaware of some
new developments -- 'spontaneous' network device renaming, just like
spontaneous mass storage device renaming, happens _only_ following
admin-initiated hardware reshuffles.

If you read the Freedesktop.org/systemd article on 'Predictable Network
Interface Names'
(https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/),
you will get the impression that, without systemd's scheme, Linux
systems are threatened by network interfaces suddenly coming up with
new device node assignments in a totally unpredictable fashion,
necessitating systemd/udev's baroque workaround to save us from chaos.
And this brings to mind two immediate reservations I have:  (1) 
If this were common, I'd expect to have encountered it fairly
frequently, and I've not encountered it at all (except for reshuffles
upon adding or removing relevant hardware).  (2) The
Freedesktop.org/systemd kiddies have a long track record of overselling
the alleged problems their baroquely overengineered software supposedly
fixes.

I've worked with very large numbers of Linux servers over three decades.
Most of those have each sported multiple ethernet NICs of the same
manufacturer, model, and driver.  e1000, tg3, e100, 3c905, 3c509, ne2000
{shudder}, etc.  In all of those many hundreds of machines each with
multiples of the same NIC/driver, over a long time, I cannot recall even
a single case when, upon reboot, eth0 and eth1 suddenly swapped.  

Which is why I find your mentors' advice odd.

I understood that, if you had a motherboard with dual e1000 NICs and
suddenly added (or removed) a third ethernet port on a PCI-E card,
whether it was also an e1000 NIC or not, you might expect to get a
device assignment reshuffle.  Therefore, if you were changing such
hardware, you simply accepted that a one-time need to re-edit
/etc/network/interfaces before redeployment was an implied part of the
task.  In exactly the same way, if you decided to throw in (or remove) a
PCI-E (PCI-X, PCI, ISA, whatever) SATA/PATA/SCSI card into a system, or
remove one, you would simply accept that a one-time need to re-edit
/etc/fstab before redeployment was an implied part of the task.

It's always been at least _possible_ that major kernel version jumps,
such as 2.4.x to 2.6.x, might cause a one-time device reshuffle, and
I've always been on-guard for it if conducting such an upgrade.  I've
not yet seen that happen (though it might).  But, again, this is just a
predictable part of the major-disro-upgrade task, and not an
unpredictable catastrophe requiring layers of protective software to
avert.

When USB came along and people started using it (overusing it) as if it
were reliable infrastructure, those of us who were paying attention saw
immediately that it would add more of that kind of chaos, and indeed
worsten it.  _However_, even given that, in my experience any reshuffle
USB would add to the _existing_ devices' node assignments would occur
only at reboot time _if_ you left the USB device plugged in.  The
obvious takeaway lesson was Don't Do That, Then (to quote the old tech.
support joke's punchline).  Unplug the friggin' USB external hard or
SSE or the USB network device before reboot, and the preexisting devices
would come up exactly as planned and not render your
/etc/network/interfaces and /etc/fstab contents inaccurate.

I find it very telling that, when horror stories pop up about allegedly
spontaneous Linux device node reshuffles, USB seems to be a recurring
element:  It suggests to me that the main problem isn't Linux device
assignment instability at all; it's inattentive reliance on a
known-problematic technology (USB) to do what it's not good for
(long-term main infrastructure) instead of what it is good for 
(causal and light-duty device use).

When I was designing my next-generation server to use a tiny, fanless
Celeron box (CompuLab IntensePC) with only external RAID1-mirror
storage, I went out of my way to ensure that the pair of external SSDs
would be connected via eSATA rather than following the path of least
resistance and using USB.  Why?  Because I don't trust USB for
persistent infrastructure.  Nor, IMO, should 

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Erik Christiansen]

On 20.08.17 16:09, Gregory Nowak wrote:
> On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> > This would lead network interface names default to the old "eth0" or
> > "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> > having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> > scheme and not touching anything to get the "eth0" scheme.
> > 
> > To keep these things consistent we should also apply the same patch to
> > udev as well.
> > 
> > Thoughts??
> 
> I'll add my vote in for the old scheme as the default, even though it
> isn't perfect as was pointed out.

ISTM that any temporary identifier an interface might have had during
boot is of less than zero significance. (What has not been seen by the
user didn't really exist.)

Predictable traditional interface names are a requirement for easy static
routing with "route add ..." commands. Screw with that, and it's time to
move on to FreeBSD.

In my 30 years of software development, I found it useful to
differentiate between _what_ and _how_. In this case, the deliverable is
unchanged userland behaviour, so decades of learning need not be
discarded for spurious reasons - that's _what_ is useful. Whether or not
some mickey mouse interim identifier is used during boot is merely an
ephemeral artifact of _how_ the deliverable is reached.

The _how_ may change without reference to the users, but _what_ must
remain unchanged. (Admittedly, I was paid for my efforts, so
responsibility to users was never in doubt. But what's the point of
Systemdixing Devuan? We'll just move on to FreeBSD if Devuan is polluted
by this unhelpful Systemdix crap.)

Erik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Steve Litt]

On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny  wrote:

> On Sun, 20 Aug 2017 17:18:13 +0200
> Adam Borowski  wrote:

> > You can't safely rename to eth0/wlan0.  At bootup, when an interface
> > is being cold/hot-plugged, an *udev script is run.  When that script
> > decides that the interface that it's been called for should be
> > "eth1", it is possible (during boot-up, likely) that another
> > interface pops up, and the kernel gives it the next name in
> > sequence, ie, "eth1".  And the result is not pretty.  
> 
> OK, when you put it like that, I can understand using a different name
> space, but remember you are also dealing with human beings so whatever
> name is used, it must be meaningful and the systemd ones aren't.

As a wee lad, my mentors told me never to put two of the same model
NICs in a computer, because which one became eth0 and which became eth1
would be indeterminate from boot to boot. That's horrible, and that *is*
solved by the systemd naming scheme.

On the other hand, nobody likes wlo1P2X4SYSTEMDSUX02 as a device name.
And also, if it's plugged into a USB and you plug it into a different
USB port, its name changes and all scripts break. Have you ever tried
to explain to a 90 year old man that he must ALWAYS plug the dongle
into THIS USB port exclusively, when the guy's vision is so bad he
can't even see the hole? It's difficult: I had to do it.

Maybe a year ago I submitted a very rough shellscript to grab your wifi
device name and return it. Somebody else on the list improved it. It
would be very very easy to keep the Freedesktop.Org names, but run a
script which populates the following environment vars:

#FOR SINGLE WIFI AND ETH DEVICES
$eth0=enop1
$wlan0=wl52po45tldnr

The preceding covers the vast majority of setups. For those with
multiple network interfaces, the scheme gets just a little more
complicated...


#FOR MULTIPLES OF EITHER
$eth0of2=enop1
$eth1of2=enPdqr0xoPOETTERPUFF

$wlan0of2=wl52po45tldnr
$wlan1of2=wlpt01

Just export those env vars into all process trees requiring networks
interface names, and you've got it made. I see this as the best of both
worlds, and it requires no changes to udev or eudev or the kernel or
anything.

SteveT

Steve Litt 
July 2017 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Gregory Nowak]

On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.
> 
> To keep these things consistent we should also apply the same patch to
> udev as well.
> 
> Thoughts??

I'll add my vote in for the old scheme as the default, even though it
isn't perfect as was pointed out.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Sun, 20 Aug 2017 at 17:24:30 +0200
viverna  wrote:

> il devuanizzato Daniel Reurich  il 20/08/17 alle
> ore 15:38 ha scritto:
> > This would lead network interface names default to the old "eth0" or
> > "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> > having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> > scheme and not touching anything to get the "eth0" scheme.  
> +1 for "eth0"/"wlan0" scheme.

  Me too.  When I need to have a name stick, I resort to the more complicated
but reliable (so far...) udev/rules method, like:

# USB device 0x:0x (ath9k_htc)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="usb",
ATTR{address}=="60:02:b4:5c:34:91", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan2"
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Simon Hobson]

Adam Borowski  wrote:

> There was a lengthy thread on debian-devel recently.  While it did include
> the usual shout-fest, there's also a good amount of actually relevant info,
> thus I'd recommend reading it.
> 
> It starts at:
> https://lists.debian.org/debian-devel/2017/07/msg00126.html

It is indeed an interesting read, but the main thing I took away from, it was 
the systemd attitude that "there's a small problem in a small number of 
situations - therefore the majority must suffer".
I don't see, given the number of ways problems can crop up, any way in which 
the problem can be solved completely. BUt "the old way" worked for most people 
most of the time - or at least that's the way I view it, though I admit I only 
see my own small view of operations which is ...

I mostly manage headless servers with static configs. The FIRST networking 
thing I do to a new (or cloned) machine is to set the interface names using 
udev rules - and as one person pointed out, that's easy to do by changing only 
the ifname in the persistent rules file. Where it's (say) a Xen host, I'll 
typically name my interfaces pethxxx where xxx is a meaningful label such as 
"lan", "ext", "bak", etc - and then I'll name my bridges ethxxx in the same 
way. For devices that aren't virtual hosts (ie no bridges) then I'll just name 
the real nic as ethxxx. That way, my if names actually make sense later - 
especially where they are used many many times in firewall rules etc.

I've seen the problem where you clone a machine and the interfaces come up on 
new numbers - but that's easily fixed. If you know the MAC in advance (if not, 
why not ?) then you can edit the rules file in advance anyway. In any case, how 
many people actually clone machines without doing things like setting hostname, 
clearing/resetting host keys for SSH, etc ? So surely setting your interface(s) 
is "just one of those tasks" in a sometimes long list.

My vote is for the "old" udev way of doing it - at least on "servers".
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[fsmithred]

On 08/20/2017 10:27 AM, Adam Borowski wrote:
> 
> * systemd-udev's promise of providing _stable_ names didn't deliver.  They
>   still change on major kernel upgrades, and sometimes on every boot. 
>   And their chosen naming is utterly insane (wlxf81a671bcfae, WTF?).
>   Only systemd proponents still say it's a good idea.
> 

They change? I thought they were based on which hardware slot they were
in. I've been ranting about how you have to open the box and look inside
to predict the names. Have I been wrong all this time?

Yeah, the name on a usb dongle is insane. I didn't stick with it long
enough to figure out if that number comes from somewhere or is random.

fsmithred

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Vernon Geiszler]

> Date: Sun, 20 Aug 2017 17:24:30 +0200
> From: viverna 

>
> il devuanizzato Daniel Reurich  il 20/08/17 alle ore 
> 15:38 ha scritto:
>> This would lead network interface names default to the old "eth0" or
>> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
>> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
>> scheme and not touching anything to get the "eth0" scheme.
> +1 for "eth0"/"wlan0" scheme.
>

+1
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[tirveni yadav]

On Sun, Aug 20, 2017 at 7:08 PM, Daniel Reurich  wrote:
> Hi,
>
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
>
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.org/devuan-packages/eudev ) utilizes the same logic
> like udev does when it comes to interface naming schemes. The patch
> appended below would reverse the logic and make it opt-in rather than
> opt-out.
>
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.


+1  for eth0/wlan0 as default.
Older scheme helps in consistency.


-- 
Regards,

Tirveni Yadav

www.bael.io

What is this Universe ? From what it arises ? Into what does it go?
In freedom it arises, In freedom it rests and into freedom it melts away.
Upanishads.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Narcis Garcia]

El 20/08/17 a les 16:48, Lars Noodén ha escrit:
> On 08/20/2017 04:38 PM, Daniel Reurich wrote:
>> We discussed a few weeks back in a dev meeting whether or not to revert
>> to jessie like naming scheme for ethernet interfaces by default.
> 
> My only interest would be consistency: that the same physical device
> always gets the same name, even if some of them come and go.  Other than
> that, I'm rather indifferent as to what they are called.
> 
> On routers and servers that I have run with Debian or Devuan, the setup
> rarely changes.  So there I feel it is not as much of an issue, as long
> as the names end up consistent across reboots, updates, and eventual
> upgrades.
> 
> However, on notebooks that I have run with Debian or Devuan, a single
> machine can rotate through three or more Ethernet devices each with
> different characteristics, any or all of which can sometimes be
> connected concurrently.
> 
> /Lars
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

Note the importance of matintaining consistency between initrd and GNU
environment.
In Debian 9: What in initrd is called "ens3" in user environment is seen
as "ens3" (OK)
In Devuan 1: What in initrd is called "eth0" in user environment is seen
as "eth0" (OK)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Ron]

On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny  wrote:

> As far as I am aware, each network device should have a different MAC,
> couldn't this be used to identify which device is which ?

Could, but whenever you have to change a NIC after a thunderstorm you are 
buggered...
 
Cheers,
 
Ron.
-- 
   All that is necessary for the forces of evil to triumph
is for enough good men to do nothing.
   -- Edmund Burke

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Aldemir Akpinar]

On Sun, 20 Aug 2017 at 16:38, Daniel Reurich 
wrote:

> Hi,
>
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
>
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.org/devuan-packages/eudev ) utilizes the same logic
> like udev does when it comes to interface naming schemes. The patch
> appended below would reverse the logic and make it opt-in rather than
> opt-out.
>
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.
>
> To keep these things consistent we should also apply the same patch to
> udev as well.
>
> Thoughts??
>
> 


+1 for eth0/wlan0, newly introduced naming scheme is horrible.

> --
Sent from Gmail Mobile
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rowland Penny]

On Sun, 20 Aug 2017 17:18:13 +0200
Adam Borowski  wrote:

> On Sun, Aug 20, 2017 at 03:45:08PM +0100, Rowland Penny wrote:
> > On Sun, 20 Aug 2017 16:27:26 +0200
> > Adam Borowski  wrote:
> [my snip:]
> > > * any renames to "eth0"/"wlan0" are a losing idea, as a new
> > > interface can appear at any moment, clashing with what you just
> > > tried to rename to. Several approaches to avoid this race have
> > > been tried, none worked reliably.  Thus, any sane renaming should
> > > use a new namespace.  Of what was proposed, it looks like people
> > > liked "en0"/"wl0" the most (yeah, it's purely an aesthethic
> > > thing).  My idea "e0"/"w0" is too short to imply out of context
> > > you're talking about interface names, etc.
> 
> > What is the difference between eth0/wlan0 and en0/wl0 or even
> > e0/w0 ? They are just variations on a theme.
> 
> You can't safely rename to eth0/wlan0.  At bootup, when an interface
> is being cold/hot-plugged, an *udev script is run.  When that script
> decides that the interface that it's been called for should be
> "eth1", it is possible (during boot-up, likely) that another
> interface pops up, and the kernel gives it the next name in sequence,
> ie, "eth1".  And the result is not pretty.

OK, when you put it like that, I can understand using a different name
space, but remember you are also dealing with human beings so whatever
name is used, it must be meaningful and the systemd ones aren't.

> 
> It's a natural thing to favour "eth*", ie, like things used to be in
> the past.  Too bad, this fails due to the above race.  In theory, the
> obvious thing would be "if rename fails, try again" -- but none of
> implementations so far hasn't done this right.  Using your own
> namespace avoids this problem entirely.
> 
> > The systemd way of doing things is, in my opinion, stupid and
> > doesn't actually help.
> 
> It's main downside is that you never know what interfaces a new
> machine has. Without systemd-udev, you can 100% predict that a
> machine with only one wired interface will have eth0.  With systemd
> "predictable" names, you never know.  Even worse, that name is not
> predictable over major kernel upgrades, a slight change of qemu's
> command line, etc.

So much for one of systemd's selling points then.

> 
> > If you have more than one ethernet (or wireless) device, then yes,
> > they need to be consistently named, but as most people will not be
> > adding (or removing) devices often, could they be issued with a
> > name based on their MAC and store this somewhere and then use this
> > to rename the network devices once they are all up ?
> 
> But how can you know they're all up?  Even if you disregard hotplug
> (ie, attaching a new (typically USB) network card at runtime), some
> hardware takes a surprisingly long time to get ready.  Waiting for
> userspace to upload required firmware (which needs the filesystem to
> be up) means the hardware's initialization only _starts_ at the time
> you'd expect it to be all done.

There has to be a way of finding network devices attached to a computer
at boot and ensuring they are initialised, otherwise nothing is ever
going to work.

> 
> Even an answer "I expect as many interfaces as there were last boot"
> won't work if the admin has just installed a shiny new network card.
> And this happens even on regular desktops -- my on-board PHY decided
> to become a nyetwork card a few months ago.

I am not saying that you can expect the same number of network devices
as last time the computer booted, but in the majority of cases where
there are more than one network device, they will always be there. 

As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?

Rowland


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[viverna]

il devuanizzato Daniel Reurich  il 20/08/17 alle ore 
15:38 ha scritto:
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.
+1 for "eth0"/"wlan0" scheme.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Adam Borowski]

On Sun, Aug 20, 2017 at 03:45:08PM +0100, Rowland Penny wrote:
> On Sun, 20 Aug 2017 16:27:26 +0200
> Adam Borowski  wrote:
[my snip:]
> > * any renames to "eth0"/"wlan0" are a losing idea, as a new interface
> > can appear at any moment, clashing with what you just tried to rename
> > to. Several approaches to avoid this race have been tried, none worked
> >   reliably.  Thus, any sane renaming should use a new namespace.  Of
> > what was proposed, it looks like people liked "en0"/"wl0" the most
> > (yeah, it's purely an aesthethic thing).  My idea "e0"/"w0" is too
> > short to imply out of context you're talking about interface names,
> > etc.

> What is the difference between eth0/wlan0 and en0/wl0 or even e0/w0 ?
> They are just variations on a theme.

You can't safely rename to eth0/wlan0.  At bootup, when an interface is
being cold/hot-plugged, an *udev script is run.  When that script decides
that the interface that it's been called for should be "eth1", it is
possible (during boot-up, likely) that another interface pops up, and the
kernel gives it the next name in sequence, ie, "eth1".  And the result is
not pretty.

It's a natural thing to favour "eth*", ie, like things used to be in the
past.  Too bad, this fails due to the above race.  In theory, the obvious
thing would be "if rename fails, try again" -- but none of implementations
so far hasn't done this right.  Using your own namespace avoids this problem
entirely.

> The systemd way of doing things is, in my opinion, stupid and doesn't
> actually help.

It's main downside is that you never know what interfaces a new machine has. 
Without systemd-udev, you can 100% predict that a machine with only one
wired interface will have eth0.  With systemd "predictable" names, you never
know.  Even worse, that name is not predictable over major kernel upgrades,
a slight change of qemu's command line, etc.

> If you have more than one ethernet (or wireless) device, then yes,
> they need to be consistently named, but as most people will not be
> adding (or removing) devices often, could they be issued with a
> name based on their MAC and store this somewhere and then use this
> to rename the network devices once they are all up ?

But how can you know they're all up?  Even if you disregard hotplug (ie,
attaching a new (typically USB) network card at runtime), some hardware
takes a surprisingly long time to get ready.  Waiting for userspace to
upload required firmware (which needs the filesystem to be up) means the
hardware's initialization only _starts_ at the time you'd expect it to
be all done.

Even an answer "I expect as many interfaces as there were last boot" won't
work if the admin has just installed a shiny new network card.  And this
happens even on regular desktops -- my on-board PHY decided to become a
nyetwork card a few months ago.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rowland Penny]

On Sun, 20 Aug 2017 16:27:26 +0200
Adam Borowski  wrote:

> On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> > We discussed a few weeks back in a dev meeting whether or not to
> > revert to jessie like naming scheme for ethernet interfaces by
> > default.
> > 
> > The eudev package (currently found in the experimental repos and at
> > https://git.devuan.org/devuan-packages/eudev ) utilizes the same
> > logic like udev does when it comes to interface naming schemes. The
> > patch appended below would reverse the logic and make it opt-in
> > rather than opt-out.
> > 
> > This would lead network interface names default to the old "eth0" or
> > "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It
> > implies having "net.ifnames=1" in the kernel cmdline to get the
> > "enp0s3"-like scheme and not touching anything to get the "eth0"
> > scheme.
> > 
> > To keep these things consistent we should also apply the same patch
> > to udev as well.
> > 
> > Thoughts??
> 
> There was a lengthy thread on debian-devel recently.  While it did
> include the usual shout-fest, there's also a good amount of actually
> relevant info, thus I'd recommend reading it.
> 
> It starts at:
> https://lists.debian.org/debian-devel/2017/07/msg00126.html
> 
> TL;DR:
> 
> * interface names changing randomly at boot are nasty for machines
> with multiple non-bonded interfaces.  As drivers are loaded by the
> kernel in parallel, they're inherently racey, thus kernel ordering
> may change.
> 
> * any renames to "eth0"/"wlan0" are a losing idea, as a new interface
> can appear at any moment, clashing with what you just tried to rename
> to. Several approaches to avoid this race have been tried, none worked
>   reliably.  Thus, any sane renaming should use a new namespace.  Of
> what was proposed, it looks like people liked "en0"/"wl0" the most
> (yeah, it's purely an aesthethic thing).  My idea "e0"/"w0" is too
> short to imply out of context you're talking about interface names,
> etc.
> 
> * systemd-udev's promise of providing _stable_ names didn't deliver.
> They still change on major kernel upgrades, and sometimes on every
> boot. And their chosen naming is utterly insane (wlxf81a671bcfae,
> WTF?). Only systemd proponents still say it's a good idea.
> 
> * there's an old alternate solution, package "ifrename" plus a
> generator, but that's quite meh
> 
> * Guus Sliepen designed and coded a new mechanism and syntax, it's
> available in ifupdown in unstable/buster:
> .--==[ /etc/network/interfaces ]
> rename mac/00:e0:4c:11:7f:4e/=wl0
> allow-hotplug wl0
> iface wl0 inet static
> `
>   Would also need a generator.
> 
> 
> Thus, I think the best long-term solution would be writing a
> generation, using either *udev or ifupdown, that learns new
> interfaces as they come, and names them using a single namespace
> that's not "eth0"/"wlan0". In particular, a machine with only a
> single interface (ie, 99% of them) would predictably have en0 and
> possibly wl0.
> 
> But sticking with just kernel names would still be much better than
> the enp0s3 idea.  It'd be _predictable_ in that 99% case; machines
> with multiple interfaces tend to be either routers (which come
> preconfigured) or servers (which have an admin who's supposed to have
> a clue).
> 
> 
> Meow!

What is the difference between eth0/wlan0 and en0/wl0 or even e0/w0 ?
They are just variations on a theme.

The systemd way of doing things is, in my opinion, stupid and doesn't
actually help.

If you have more than one ethernet (or wireless) device, then yes,
they need to be consistently named, but as most people will not be
adding (or removing) devices often, could they be issued with a
name based on their MAC and store this somewhere and then use this
to rename the network devices once they are all up ?

Until then +1 to using eth0/wlan0

Rowland   
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Adam Borowski]

On Mon, Aug 21, 2017 at 01:38:00AM +1200, Daniel Reurich wrote:
> We discussed a few weeks back in a dev meeting whether or not to revert
> to jessie like naming scheme for ethernet interfaces by default.
> 
> The eudev package (currently found in the experimental repos and at
> https://git.devuan.org/devuan-packages/eudev ) utilizes the same logic
> like udev does when it comes to interface naming schemes. The patch
> appended below would reverse the logic and make it opt-in rather than
> opt-out.
> 
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.
> 
> To keep these things consistent we should also apply the same patch to
> udev as well.
> 
> Thoughts??

There was a lengthy thread on debian-devel recently.  While it did include
the usual shout-fest, there's also a good amount of actually relevant info,
thus I'd recommend reading it.

It starts at:
https://lists.debian.org/debian-devel/2017/07/msg00126.html

TL;DR:

* interface names changing randomly at boot are nasty for machines with
  multiple non-bonded interfaces.  As drivers are loaded by the kernel in
  parallel, they're inherently racey, thus kernel ordering may change.

* any renames to "eth0"/"wlan0" are a losing idea, as a new interface can
  appear at any moment, clashing with what you just tried to rename to.
  Several approaches to avoid this race have been tried, none worked
  reliably.  Thus, any sane renaming should use a new namespace.  Of what
  was proposed, it looks like people liked "en0"/"wl0" the most (yeah, it's
  purely an aesthethic thing).  My idea "e0"/"w0" is too short to imply
  out of context you're talking about interface names, etc.

* systemd-udev's promise of providing _stable_ names didn't deliver.  They
  still change on major kernel upgrades, and sometimes on every boot. 
  And their chosen naming is utterly insane (wlxf81a671bcfae, WTF?).
  Only systemd proponents still say it's a good idea.

* there's an old alternate solution, package "ifrename" plus a generator,
  but that's quite meh

* Guus Sliepen designed and coded a new mechanism and syntax, it's available
  in ifupdown in unstable/buster:
.--==[ /etc/network/interfaces ]
rename mac/00:e0:4c:11:7f:4e/=wl0
allow-hotplug wl0
iface wl0 inet static
`
  Would also need a generator.


Thus, I think the best long-term solution would be writing a generation,
using either *udev or ifupdown, that learns new interfaces as they come,
and names them using a single namespace that's not "eth0"/"wlan0".
In particular, a machine with only a single interface (ie, 99% of them)
would predictably have en0 and possibly wl0.

But sticking with just kernel names would still be much better than the
enp0s3 idea.  It'd be _predictable_ in that 99% case; machines with multiple
interfaces tend to be either routers (which come preconfigured) or servers
(which have an admin who's supposed to have a clue).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Erik Christiansen]

On 21.08.17 01:38, Daniel Reurich wrote:
> This would lead network interface names default to the old "eth0" or
> "wlan0" scheme, rather than the new(?) "enp0s3"-like scheme. It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.

Wonderful. +10

(Given the relative ease of user selection, it's not absolutely essential
to refrain from causing needless user dislocation by default, but it is
the path of least harm, I submit. )

Erik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Ron]

On Mon, 21 Aug 2017 01:38:00 +1200
Daniel Reurich  wrote:

>  It implies
> having "net.ifnames=1" in the kernel cmdline to get the "enp0s3"-like
> scheme and not touching anything to get the "eth0" scheme.

+1
 
Cheers,
 
Ron.
-- 
  Those of you who think you know everything
are very annoying those of us who do.

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng