[sle-beta] Network missing pieces

[Joe Doupnik]

     Forwarding a copy to the beta list:

     Without meaning to start a long discussion, I have the distinct 
feeling here that we have another classical "could versus should" 
situation.
     In my view, the customer/end-user/human experience has high 
precedence about many matters of this kind. Thus classical tools ought 
to remain until there are clearly superior versions together marked need 
for those superior versions. If no such need then the classical ought to 
remain intact because the goal is to provide the end user with easy to 
use and remember controls, rather than play with the toys just because 
one could. There is also the unnecessary complexity part of things where 
replacement commands for standard straight forward operations require 
obtuse replacements and extra bits. Example: to open the house front 
door please hold the key upright in the mail slot while pointing one's 
left hand at the door's top hinge, which demonstrates our new nifty 
electro-optical lock mechanism (void during hurricane season).
     The aspects of need and complexity become evident when dealing with 
more than one particular edition of Linux and with our sundry scripts 
and helpful programs which depend upon such features. Consider these 
aspects under stressful conditions involving many sundry Linux machines 
and there is some kind of trouble which must be fixed immediately by a 
duty manager. Consider what new customers would expect to be available 
[cf. the Windows 10 start menu fiasco].
     lspci. Gosh, I wonder how many people would think of that when 
dealing with a regular Ethernet adapter, even assuming the adapter were 
PCI based. Actually it does not help us, as readers can verify for 
themselves. Obscure ("whimsical") naming does no good either.  ethN (N = 
0, 1..) is at least regular, predictable, some might say sensible and 
human oriented. Contrast that with "ens32" which can be followed next by 
say "ens34" (what happened to 33 or 31? Did I make an error somewhere?) 
which seem to have no obvious relationship to the observable world. The 
adapter name can be rectified manually, say via YaST or much more 
obscure tricks, but then arguably the regular system could/should have 
done that in the first place.
     The freedesktop.org article (aka systemd again) is useful to read, 
so thanks for its reference in this discussion. In a nutshell or two it 
says they don't know what to do about an ideal AI solution (they haven't 
second guessed the kernel first guesser), so instead of solving that at 
the post boot level awkward special user commands are needed to restore 
rationality for even 90+% of situations. Think: a deer in headlights. 
Two quotations from the article:
> Does this have any drawbacks? Yes, it does. Previously it was 
> practically guaranteed that hosts equipped with a single ethernet card 
> only had a single "eth0" interface. With this new scheme in place, an 
> administrator now has to check first what the local interface name is 
> before he can invoke commands on it where previously he had a good 
> chance that "eth0" was the right name.
> That's documented in detail in a comment block the sources of the 
> net_id built-in 
> <https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20>. 
> Please refer to this in case you are wondering how to decode the new 
> interface names.
     Container projects seem to be inventing their own problems, and one 
hopes that over time those awkwardnesses would filter down into 
supporting kernel changes. An analogy is asking how many children's 
swings and houses a normal tree could support without requiring a new 
species.
    Thus far in the discussed material I perceive neither superiority 
nor marked need, but I do see added complexity and obscurity.  I think 
the primary goal of usability by regular people is being lost in 
technical noise. Retaining tried and true tools while improving their 
underpinnings can be a satisfying achievement and be widely accepted.
     Thanks,
     Joe D.

On 05/11/2017 20:47, Richard Brown wrote:
> On 2017-11-05 16:26, Joe Doupnik wrote:
>>     Perhaps this has been discussed previously and I missed it, but I
>> found two major network components are missing: commands to support
>> ifconfig and netstat. I have utilities which depend upon them, plus
>> humans and their habits.
>
> Hi Joe!
>
> Those tools (along with arp and route) have long been deprecated and 
> should be substituted with their modern equivalents from the iproute2 
> package
>
>       * arp -> ip [-r] neigh
>       * ifconfig -> ip a
>       * netstat -> ss [-r]
>       * route -> ip r
>
> If you really, really, really want to continue to use the old 
> unsupported tools I think SLE 15 has the 'net-tools-deprecated' 
> package which will install them, but the package description gives the 
> same recommendation as above.
>
>>     Further, we seem to be repeating the mistake of naming Ethernet
>> interfaces in weird style, a matter which we thrashed out in SLES 12
>> some time ago. That means I expect to see eth0, eth1, rather than
>> whimsical creations.
>
> The new interface naming is not 'whimsical' but solves real problems. 
> I for one quite like the fact that I now have stable device naming 
> regardless of tinkering with VM configurations, adding/removing cards 
> on real hardware, etc etc
>
> A simple 'lspci' is all I need now to predictively create 
> configuration required for a card, whereas with the previous model I 
> could never be 100% certain my scripted 'eth0' configurations would 
> land on the CORRECT card on the system.
>
> It's compatibility with a read-only root filesystem is also a boon for 
> the work we're doing with CaaSP and Kubic. I'm quite sick of the bugs 
> I have in Kubic right now because we haven't yet implemented this 
> there as effectively as you see in the SLE-15 beta.
>
> There's a lot more information about this on the Freedesktop.org site:
>
>
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 
>
>
> Hope this helps,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20171106/673c3c10/attachment.htm>