Re: [DNG] What does Linus do?

[Simon Hobson]

Alessandro Selli  wrote:

>> Do I understand you ccorrectly:  that the udev rules are flexible 
>> enough to do the right thing, but they are too hard to use?
> 
>  Yes.  On some occations I had to find out where in /sys a device had it's
> control and attribute directory (not easy at all to a newbie) and then run a
> command such as:
> 
> # udevadm info --attribute-walk /sys/devices/pci\:00/\:00\:1a.0/usb1/
> 
> to get a long list of attributes to select from when building my own rule
> that isolated a single device.

Unfortunately here we seem to be hitting the complexity vs flexibility 
tradeoff. AIUI pretty well all attempts to hide the complexity from the user 
(or admin) end up making things worse - hence the discussion of getting rid of 
systemd !

> And I remember in a few occasions my old rules
> stopped working and I had to redo them to reflect a change in rules syntax
> that was introduced from a udev's version onwards.

That's not an issue with the rules per se, that's an issue with developers 
moving the goalposts and not caring what they break. Hmm, and here we come back 
to the development style of those in charge of systemd again !

> And I could not have udev run a command at device hot-plug.  Too cumbersome 
> and little intuitive.  And not well documented, at least at the time (a few 
> years ago).

I agree they are not easy (certainly doesn't look it), but then the only 
involvement I've had is letting "the system" create rules for ethn and changing 
the name to something I want.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What does Linus do?

[Alessandro Selli]

On Sun, 27 Aug 2017 at 19:23:11 -0400
Hendrik Boom  wrote:

> On Sun, Aug 27, 2017 at 12:05:56AM +0200, Alessandro Selli wrote:
>> 
>>   This idea does has some merit, but it cannot always prevent the
>> necessity to reconfigure a system's networking due to a hardware change
>> and to a sysadmin's specific needs; sometimes a cars with NIC
>> 0b:45:81:f4:3e:01 is to be en1, sometimes a never-before-seen card needs
>> to be given the same name. How is the system supposed to know?  It
>> cannot, the sysadmin will still need to adjust thing by hand according to
>> what it's needed in the specific circumstances.  I'd like a system that
>> was as simple as possible to configure and maintain that made this
>> renaming as straightforward as possible, not as complicated ad udev rules
>> are.  
>
> Do I understand you ccorrectly:  that the udev rules are flexible 
> enough to do the right thing, but they are too hard to use?

  Yes.  On some occations I had to find out where in /sys a device had it's
control and attribute directory (not easy at all to a newbie) and then run a
command such as:

# udevadm info --attribute-walk /sys/devices/pci\:00/\:00\:1a.0/usb1/

to get a long list of attributes to select from when building my own rule
that isolated a single device. And I remember in a few occasions my old rules
stopped working and I had to redo them to reflect a change in rules syntax
that was introduced from a udev's version onwards.  And I could not have udev
run a command at device hot-plug.  Too cumbersome and little intuitive.  And
not well documented, at least at the time (a few years ago).


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

Re: [DNG] What does Linus do?

[Hendrik Boom]

On Sun, Aug 27, 2017 at 12:05:56AM +0200, Alessandro Selli wrote:
> 
>   This idea does has some merit, but it cannot always prevent the necessity
> to reconfigure a system's networking due to a hardware change and to a
> sysadmin's specific needs; sometimes a cars with NIC 0b:45:81:f4:3e:01 is to
> be en1, sometimes a never-before-seen card needs to be given the same name.
> How is the system supposed to know?  It cannot, the sysadmin will still need
> to adjust thing by hand according to what it's needed in the specific
> circumstances.  I'd like a system that was as simple as possible to configure
> and maintain that made this renaming as straightforward as possible, not as
> complicated ad udev rules are.

Do I understand you ccorrectly:  that the udev rules are flexible 
enough to do the right thing, but they are too hard to use?

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

Re: [DNG] What does Linus do?

[Simon Hobson]

Adam Borowski  wrote:

> It would mean changes to every single program that deals with network
> interfaces.  With renaming, you apply this in a single place.

This.
If an interface name changes, I don't want to have to find and change every 
occurrence - network config, firewall/iptables rules, dhcp server, data 
collection scripts (eg grabbing interface stats), and ... With a quick look, I 
see that some of my Nagios plugins need the interface specifying.
And don't forget that external systems may have visibility/use interface names 
- eg via SNMP.

And as pointed out, this is a very different situation to filesystems/disk 
drives.
With disks, you have a level of abstraction inherent in the filesystems layout. 
Few things work with disk/partition names - so provided mount and fstab between 
them can describe what mounts where, then nothing else in normal use needs to 
know anything about names - they just refer to files. Pretty well everything 
that refers to disk/partition names is something run manually by the admin.


ISTM that there are in fact two distinctly different cases being talked about - 
and those use cases have different needs which I think may be part of the 
problem in trying to solve everything in one way. Or, there seems to be a lot 
of discussion about what size & shape the hammer should be, forgetting that "if 
the only tool you have is a hammer, then every problem looks like a nail".

I'd suggest (no I don't have any references) that the vast majority of systems, 
especially those not managed by a "professional admin", have just one ethernet 
NIC and/or one WiFi interface. For these systems there is no problem just using 
the default kernel option that names them eth0/wlan0.
Furthermore, for these systems, all the "solutions" to the non-existent problem 
are actually creating a problem that didn't exist.

Then I'd suggest that the majority of systems with multiple NICs are managed by 
someone "with a clue" - and for these the problem was solved years ago with 
techniques to rename interfaces (my preference being to use meaning names like 
ethlan, ethext, etc which don't clash with the defaults).


So that doesn't leave many systems with a problem to solve !

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

Re: [DNG] What does Linus do?

[Narcis Garcia]

El 26/08/17 a les 19:57, Didier Kryn ha escrit:
> Le 26/08/2017 à 19:02, Alessandro Selli a écrit :

> With my proposed solution, the admin has the choice to refer to nics
> by their interface name, as given by the kernel, which is fine when
> there is only one, or by their MAC address, if there are several. If you
> use MAC you get the same result as with current Devuan's udev renaming
> scheme -without the race - and if you use eth0 then you get the same
> result as if you disabled renaming. And you can mix things if you like
> in /etc/interfaces, eg use wlan0 for wifi and MAC for the Ethernets; it
> isn't a decisipon of the distro; it is up to the admin. Just like for
> partitions. Simplicity and choice, that's Unix, isn't it :-)
> 

This is exactly what the 'mactoname' service allows.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What does Linus do?

[Alessandro Selli]

On Sat, 26 Aug 2017 at 13:11:36 -0400
Hendrik Boom  wrote:

> On Sat, Aug 26, 2017 at 07:02:41PM +0200, Alessandro Selli wrote:
>> On Sat, 26 Aug 2017 at 17:19:48 +0200
>> Didier Kryn  wrote:
>>   
>>>  AFAIR I fully agreed on that and then it jumped into my face that 
>>> the renaming wasn't necessary at all, because it is sufficient to know 
>>> the MAC address and ignore completely the interface name. It is just 
>>> enough for this to work that the tools manipulating the network 
>>> interfaces can be given the MAC address instead of the interface name. 
>>> This opens an alternative to renaming: guaranteed stable interface 
>>> reference, no race condition and no need for a new name space.  
>>
>>   This is not a good solution when you want networking to work just the
>> same even when you replace or shuffle your networking hardware around,
>> expecially with USB devices.  
>
> It seems we are approaching the paradox of the well-darned sock.
> At what point are we to consider an interface to have changed?

  Right, both the admin and the system will easily agree on the fact that an
interface is new.  But what about it's name to be assigned?  Is it new
because it's replacing a previouly used interface, or is it new because it's
going to be used for something unrelated to the other interfaces that the
system has seen before?  how is the OS supposed to know?  It cannot, so any
NIC renaming gimmick will have to provide for a way the sysadmin to impose
their own naming scheme.  My vote will go to the system that:

1) uses the shortest and easiest to identify and remember names (en0 and wf1
are good choises, enp0s23 so so, etf45a09dc634 is awful)
2) is as easy as apple pie to reconfigure to fit any specific environment
(which is a thing udev got wrong).


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

Re: [DNG] What does Linus do?

[Alessandro Selli]

On Sat, 26 Aug 2017 at 19:57:34 +0200
Didier Kryn  wrote:

> Le 26/08/2017 à 19:02, Alessandro Selli a écrit :
>> On Sat, 26 Aug 2017 at 17:19:48 +0200
>> Didier Kryn  wrote:
>>
>>>   AFAIR I fully agreed on that and then it jumped into my face that
>>> the renaming wasn't necessary at all, because it is sufficient to know
>>> the MAC address and ignore completely the interface name. It is just
>>> enough for this to work that the tools manipulating the network
>>> interfaces can be given the MAC address instead of the interface name.
>>> This opens an alternative to renaming: guaranteed stable interface
>>> reference, no race condition and no need for a new name space.  
>>This is not a good solution when you want networking to work just the
>> same even when you replace or shuffle your networking hardware around,
>> expecially with USB devices.  
>
>  Please could you explain why with more details?

  Suppose you have a laptop you use both at work and home.  You configured
the built-in WiFi in a way that is best suited to connect to your home
network, and you configured a USB-WiFi adaptor with different firewall
policies for when you use it from work (maybe you use it to connect home via
a VPN that can only go trough a specific Access Point).  Of course you don't
like sudo-ing your config files every time you change of USB-WiFi adaptor,
you'd like your iptables -o wlan1 ... rules to always apply to the USB-WiFi
adaptor even when you change it or use a colleague's one test a new one.

  But wlan* names are assigned by the kernel and sometimes strange things do
happen, like that while kernel 4.8 used to load the iwlwifi module (builtin
WiFi) before the r8169 one if you booted the PC with the USB-WiFi adaptor
inserted, kernel 4.12 does the opposite.
  This did not happen to me with WiFi gear, but I know a guy who run into
this issue with webcams, because his laptop's internal one was connected to
the motherboard via a USB port.  If he booted with a second webcam plugged
in, that webcam would be /dev/video0 and his scripts would use the wrong one.

  If you're playing with Software Defined Networking, and maybe assembled a
PC with a number of multi-ethernet PCIe cards, then such issues do pop up
from time to time and can be a serious nuisance if that PC replaced your
employer's old Cisco switch and an upgrade and reboot made the LAN
inaccessible while you're on vacation ;-)

  I don't now if NIC suffer from the same issue hard disks suffer from, that
is ageing that causes activation/initialisation time to grow with time.  A
problem with HDs is not just that from a kernel version to a following one
modules might load in a different sequence, but that disks take longer to
spin-up and to report themselves on-line as they age.  As HDs do not age the
same way, it can happen that in an array disk2 reports itself online before
disk1 and is thus assigned sda by the kernel.  However after a few years it
goes on-line after disk1, and is thus assigned name sdb.  I don't know if
NICs can suffer from the same issue, though I expect devices that have mo
mechanical parts to age much more gracefully.  But then, electronics too grow
old and see their parameters change somewhat, even though so far I only
experienced MII ethernet transceivers to just stop working.

>>>   Since this last method is exactly what is done to refer to disk
>>> partitions in both the mount utility and the fstab, the same could be
>>> done with the MAC address of the network interfaces.  
>>This is easily done on filesystems, because you can assign arbitrary
>> UUIDs and LABELs on a filesystem at mkfs time or later with tune2fs and
>> other tools. But you cannot as easily change MAC address on an ethernet
>> or WiFi device, sometimes you cannot do it at all (AFAIK in some cases
>> you should reflash an internal flash memory).  
>
>  You assign UUIDs because partitions dont come with hardwired UUIDs, 
> obviously.

  This makes them very useful because they both allow one to always identify
the right filesystem no matter how the kernel today is calling the device it
lives on, and they can be arbitrarilly assigned by the superuser.

> The usefull property of UUIDs is in their name ("unique"), 
> not at all the fact that you (randomly) assign them. The same applies to 
> MAC addresses, they are (quasi) unique.

  MAC lacks the arbitrary assignement property.  Some (many?) NICs do allow
their MAC to be changed by software (driver or specially built application),
because the MAC is recorded on an on-bloard flash.  But it's permanent
modification is not as easy as changing a filesystem's UUID/LABEL, as this
operation need specific kernel support (that I think is often missing).

>>> Which raises
>>> another question: why are we using the hotplugger to mess with interface
>>> names instead of implementing the MAC handle in the ip utility and the
>>> interfaces file.  
>>Because in most cases 

Re: [DNG] What does Linus do?

[Martin Steigerwald]

I am grateful for this thread being on topic again.

Adam Borowski - 26.08.17, 20:54:
> On Sat, Aug 26, 2017 at 05:19:48PM +0200, Didier Kryn wrote:
> > AFAIR I fully agreed on that and then it jumped into my face that the
> > renaming wasn't necessary at all, because it is sufficient to know the MAC
> > address and ignore completely the interface name. It is just enough for
> > this to work that the tools manipulating the network interfaces can be
> > given the MAC address instead of the interface name. This opens an
> > alternative to renaming: guaranteed stable interface reference, no race
> > condition and no need for a new name space.
> 
> It would mean changes to every single program that deals with network
> interfaces.  With renaming, you apply this in a single place.
> 
> Also, compare "wlxf81a671bcfae" with "mac=f8:1a:67:1b:cf:ae" (hint: sed
> 's/mac=/wlx/;s/://g').  I don't see any advantages for the latter, and
> nobody in this thread had any kind words for the former.

I am fine with a simple renaming with a simple numbered namespace as you 
proposed. en0, en1, wl1 and so on would be fine for me. But I disable the 
systemd naming scheme wherever I can cause en16millionsomething and 
wlxf81a671bcfae is crap for me.

I also prefer LABELs oder UUIDs in filesystems anytime. I am a human being and 
I prefer speaking names over cryptic stuff. During AmigaOS times I learned one 
thing: It is important the operating system adapts to the user… not the other 
way around (of course in AmigaOS you could name almost anything as you wish, 
it started out with partitions, but with Roadshow TCP/IP stack also network 
interfaces have names that can be changed).

Heck, I type lwn.net instead of 45.33.94.129 and thats for a reason.

Thats most of the issue I have with Systemd upstream developer behavior: They 
*force* their view of the world to the user and the user has to adapt. It is 
this arrogance that feels completely out of place to me. Thats the completely 
wrong way to approach developing computer operating systems that are to be 
used by human beings. The computers are there to serve us… not the other way 
around. I am happy to have learned this during my Amiga times… the operating 
system was so simple that I could tell what every file in it was for. (At one 
time there may be computers that are advanced enough to carry consciousness or 
even start to "feel"… and then its important to respect that… and probably 
give those computers similar rights, but we are not even close to this time I 
think.)

So… my plea is: Dear developersm, stop throwing complex and irritating stuff 
onto the user just cause you think its better!

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

Re: [DNG] What does Linus do?

[Adam Borowski]

On Sat, Aug 26, 2017 at 05:19:48PM +0200, Didier Kryn wrote:
> AFAIR I fully agreed on that and then it jumped into my face that the
> renaming wasn't necessary at all, because it is sufficient to know the MAC
> address and ignore completely the interface name. It is just enough for this
> to work that the tools manipulating the network interfaces can be given the
> MAC address instead of the interface name. This opens an alternative to
> renaming: guaranteed stable interface reference, no race condition and no
> need for a new name space.

It would mean changes to every single program that deals with network
interfaces.  With renaming, you apply this in a single place.

Also, compare "wlxf81a671bcfae" with "mac=f8:1a:67:1b:cf:ae" (hint: sed
's/mac=/wlx/;s/://g').  I don't see any advantages for the latter, and
nobody in this thread had any kind words for the former.


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] What does Linus do?

[Didier Kryn]

Le 26/08/2017 à 19:02, Alessandro Selli a écrit :

On Sat, 26 Aug 2017 at 17:19:48 +0200
Didier Kryn  wrote:


  AFAIR I fully agreed on that and then it jumped into my face that
the renaming wasn't necessary at all, because it is sufficient to know
the MAC address and ignore completely the interface name. It is just
enough for this to work that the tools manipulating the network
interfaces can be given the MAC address instead of the interface name.
This opens an alternative to renaming: guaranteed stable interface
reference, no race condition and no need for a new name space.

   This is not a good solution when you want networking to work just the same
even when you replace or shuffle your networking hardware around, expecially
with USB devices.


Please could you explain why with more details?




  Since this last method is exactly what is done to refer to disk
partitions in both the mount utility and the fstab, the same could be
done with the MAC address of the network interfaces.

   This is easily done on filesystems, because you can assign arbitrary UUIDs
and LABELs on a filesystem at mkfs time or later with tune2fs and other tools.
But you cannot as easily change MAC address on an ethernet or WiFi device,
sometimes you cannot do it at all (AFAIK in some cases you should reflash an
internal flash memory).


You assign UUIDs because partitions dont come with hardwired UUIDs, 
obviously. The usefull property of UUIDs is in their name ("unique"), 
not at all the fact that you (randomly) assign them. The same applies to 
MAC addresses, they are (quasi) unique.





Which raises
another question: why are we using the hotplugger to mess with interface
names instead of implementing the MAC handle in the ip utility and the
interfaces file.

   Because in most cases networking on eth0 must work no matter what it's MAC
address is today/was yesterday.
The problem is how to configure eth0. If you have only one nic, 
then it's clear; otherwise you don't want to mess.


With my proposed solution, the admin has the choice to refer to 
nics by their interface name, as given by the kernel, which is fine when 
there is only one, or by their MAC address, if there are several. If you 
use MAC you get the same result as with current Devuan's udev renaming 
scheme -without the race - and if you use eth0 then you get the same 
result as if you disabled renaming. And you can mix things if you like 
in /etc/interfaces, eg use wlan0 for wifi and MAC for the Ethernets; it 
isn't a decisipon of the distro; it is up to the admin. Just like for 
partitions. Simplicity and choice, that's Unix, isn't it :-)





And why are the potterguys now promoting their
complicated name space, if not to make the system always more complicated

   I do agree their solution is far from elegant.


to solve a problem they have invented themselves?

   I do not agree: in many cases when a machine has several NICs there are
real issues with the kernel's naming scheme.


Seems (to me) you didn't get my point. Sorry I failed to explain or 
I failed to understand your objections :-)


Didier


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

Re: [DNG] What does Linus do?

[Hendrik Boom]

On Sat, Aug 26, 2017 at 07:02:41PM +0200, Alessandro Selli wrote:
> On Sat, 26 Aug 2017 at 17:19:48 +0200
> Didier Kryn  wrote:
> 
> >  AFAIR I fully agreed on that and then it jumped into my face that 
> > the renaming wasn't necessary at all, because it is sufficient to know 
> > the MAC address and ignore completely the interface name. It is just 
> > enough for this to work that the tools manipulating the network 
> > interfaces can be given the MAC address instead of the interface name. 
> > This opens an alternative to renaming: guaranteed stable interface 
> > reference, no race condition and no need for a new name space.
> 
>   This is not a good solution when you want networking to work just the same
> even when you replace or shuffle your networking hardware around, expecially
> with USB devices.

It seems we are approaching the paradox of the well-darned sock.
At what point are we to consider an interface to have changed?

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

Re: [DNG] What does Linus do?

[Alessandro Selli]

On Sat, 26 Aug 2017 at 17:19:48 +0200
Didier Kryn  wrote:

>  AFAIR I fully agreed on that and then it jumped into my face that 
> the renaming wasn't necessary at all, because it is sufficient to know 
> the MAC address and ignore completely the interface name. It is just 
> enough for this to work that the tools manipulating the network 
> interfaces can be given the MAC address instead of the interface name. 
> This opens an alternative to renaming: guaranteed stable interface 
> reference, no race condition and no need for a new name space.

  This is not a good solution when you want networking to work just the same
even when you replace or shuffle your networking hardware around, expecially
with USB devices.

>  Since this last method is exactly what is done to refer to disk 
> partitions in both the mount utility and the fstab, the same could be 
> done with the MAC address of the network interfaces.

  This is easily done on filesystems, because you can assign arbitrary UUIDs
and LABELs on a filesystem at mkfs time or later with tune2fs and other tools.
But you cannot as easily change MAC address on an ethernet or WiFi device,
sometimes you cannot do it at all (AFAIK in some cases you should reflash an
internal flash memory).

> Which raises 
> another question: why are we using the hotplugger to mess with interface 
> names instead of implementing the MAC handle in the ip utility and the 
> interfaces file.

  Because in most cases networking on eth0 must work no matter what it's MAC
address is today/was yesterday.

> And why are the potterguys now promoting their 
> complicated name space, if not to make the system always more complicated

  I do agree their solution is far from elegant.

> to solve a problem they have invented themselves?

  I do not agree: in many cases when a machine has several NICs there are
real issues with the kernel's naming scheme.


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

Re: [DNG] What does Linus do?

[Didier Kryn]

Le 26/08/2017 à 16:35, Alessandro Selli a écrit :

On Sat, 26 Aug 2017 at 15:04:51 +0200
Didier Kryn  wrote:


Le 26/08/2017 à 14:14, Alessandro Selli a écrit :

   My main subject was questionning the necessity of renaming network
interfaces (with my answer to the question). Since nobody argumented
that renaming was necessary, it is clear for me that renaming is a
feature invented to give more importance to Udev and isn't necessary at
all.

Actually Adam Borowski did.  Did you miss this message of his posted on
the 20th?
https://lists.dyne.org/lurker/message/20170820.142726.04720725.en.html

  Adam proposed that the renaming happens in a different namespace so
as to not clash with kernel naming new interfaces asynchronously. At
this stage of the thread, the necessity of interface renaming was not
yet questioned; at least this mail of Adam was not an opinion on wether
renaming was necessary/useful or not.

  Yes, this necessity was argued in the linked email.  I quote:

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

   That is, Adam acknowledges there exists an issue with the kernel's
assignment of ethernet device names on "machines with multiple non-bonded
interfaces."  And he did not argue against the necessity of interface
renaming  in userland, in fact he proposed his own naming scheme:

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

AFAIR I fully agreed on that and then it jumped into my face that 
the renaming wasn't necessary at all, because it is sufficient to know 
the MAC address and ignore completely the interface name. It is just 
enough for this to work that the tools manipulating the network 
interfaces can be given the MAC address instead of the interface name. 
This opens an alternative to renaming: guaranteed stable interface 
reference, no race condition and no need for a new name space.


Since this last method is exactly what is done to refer to disk 
partitions in both the mount utility and the fstab, the same could be 
done with the MAC address of the network interfaces. Which raises 
another question: why are we using the hotplugger to mess with interface 
names instead of implementing the MAC handle in the ip utility and the 
interfaces file. And why are the potterguys now promoting their 
complicated name space, if not to make the system always more 
complicated to solve a problem they have invented themselves?


Didier

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

Re: [DNG] What does Linus do?

[Alessandro Selli]

On Sat, 26 Aug 2017 at 15:04:51 +0200
Didier Kryn  wrote:

> Le 26/08/2017 à 14:14, Alessandro Selli a écrit :
>>>   My main subject was questionning the necessity of renaming network
>>> interfaces (with my answer to the question). Since nobody argumented
>>> that renaming was necessary, it is clear for me that renaming is a
>>> feature invented to give more importance to Udev and isn't necessary at
>>> all.  
>>Actually Adam Borowski did.  Did you miss this message of his posted on
>> the 20th?
>> https://lists.dyne.org/lurker/message/20170820.142726.04720725.en.html  
>
>  Adam proposed that the renaming happens in a different namespace so 
> as to not clash with kernel naming new interfaces asynchronously. At 
> this stage of the thread, the necessity of interface renaming was not 
> yet questioned; at least this mail of Adam was not an opinion on wether 
> renaming was necessary/useful or not.

 Yes, this necessity was argued in the linked email.  I quote:

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

  That is, Adam acknowledges there exists an issue with the kernel's
assignment of ethernet device names on "machines with multiple non-bonded
interfaces."  And he did not argue against the necessity of interface
renaming  in userland, in fact he proposed his own naming scheme:

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


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

Re: [DNG] What does Linus do?

[Didier Kryn]

Le 26/08/2017 à 14:14, Alessandro Selli a écrit :

  My main subject was questionning the necessity of renaming network
interfaces (with my answer to the question). Since nobody argumented
that renaming was necessary, it is clear for me that renaming is a
feature invented to give more importance to Udev and isn't necessary at all.

   Actually Adam Borowski did.  Did you miss this message of his posted on
the 20th?
https://lists.dyne.org/lurker/message/20170820.142726.04720725.en.html


Adam proposed that the renaming happens in a different namespace so 
as to not clash with kernel naming new interfaces asynchronously. At 
this stage of the thread, the necessity of interface renaming was not 
yet questioned; at least this mail of Adam was not an opinion on wether 
renaming was necessary/useful or not.


I suggested that renaming was not a necessity and the same method 
could be used to refer to network interfaces as was used to refer to 
partitions, since the problem of device name inpredictibility is exactly 
the same.


Didier


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

Re: [DNG] What does Linus do?

[Alessandro Selli]

On Thu, 24 Aug 2017 at 15:13:40 +0200
Didier Kryn  wrote:

[...]

>  My main subject was questionning the necessity of renaming network 
> interfaces (with my answer to the question). Since nobody argumented 
> that renaming was necessary, it is clear for me that renaming is a 
> feature invented to give more importance to Udev and isn't necessary at all.

  Actually Adam Borowski did.  Did you miss this message of his posted on
the 20th?
https://lists.dyne.org/lurker/message/20170820.142726.04720725.en.html

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

Re: [DNG] What does Linus do?

[Didier Kryn]

Le 24/08/2017 à 01:01, John Franklin a écrit :

On Aug 22, 2017, at 2:26 PM, Dave 
Turner  wrote:

There's a lot of heavy discussion going on in

'Proposed change to ascii' and 'an alternative to renaming'

But what does Linus do? How does he think this should play out?

I am a big fan of 'going with the flow' apart from when it is a really bad idea 
such as systemd.

Agreed.  Those two discussions have long since outlived their usefulness and 
the petty bickering is going to scare away people.


The second thread was a fork (by me) of a previous thread on the 
best way to perform network interface renaming. Unfortunately it 
contained two subjects.


My main subject was questionning the necessity of renaming network 
interfaces (with my answer to the question). Since nobody argumented 
that renaming was necessary, it is clear for me that renaming is a 
feature invented to give more importance to Udev and isn't necessary at all.


The OT subjet was about Mdev (a KISS hotplugger) and wether it was 
sufficient. Several technical advices have been provided on the subject, 
plus too many digressions. Maybe all usable technical advices have been 
collected and I will have to compile them and compare them with 
available online documents. I must thank the people who gave technical 
insights on the matter.


For your thread, I have the personnal impression that the fashion, 
a decade ago, was to delegate to userspace as much as possible of the OS 
tasks. Unfortunately all the work of developping the userspace servers 
has been taken over by RedHat in a bad way and, because of that, Linus 
is now taking it back into the kernel, because he doesn't want to 
participate in userspace. Of course he will never tell it that way.


Didier


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

Re: [DNG] What does Linus do?

[John Franklin]

> On Aug 22, 2017, at 2:26 PM, Dave Turner 
>  wrote:
> 
> There's a lot of heavy discussion going on in
> 
> 'Proposed change to ascii' and 'an alternative to renaming'
> 
> But what does Linus do? How does he think this should play out?
> 
> I am a big fan of 'going with the flow' apart from when it is a really bad 
> idea such as systemd.

Agreed.  Those two discussions have long since outlived their usefulness and 
the petty bickering is going to scare away people.

As it is currently, I have a hard time recommending Devuan.  I’m no fan of 
systemd, but Devuan Jessie is essentially Debian Jessie, and the Ascii 
repository is a mess with several uninstallable packages (e.g., 
network-manager, slim), which means something or someone broke Debian Testing 
rules 4 and/or 5. [1]  I know this isn’t Debian, but as a fork, I expect the 
same rules to apply.

The release engineering site release.devuan.org is in DNS, but points to the 
main devuan.org site.  Clearly, there is some CI infrastructure that is 
missing, and until it is put in place, Devuan’s technical debt will continue to 
increase.

jf
[1] From https://www.debian.org/devel/testing
-- 
John Franklin
frank...@tux.org



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