Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
predictable network interface names
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Aiken
Apprentice
Apprentice


Joined: 22 Jan 2003
Posts: 221
Location: Toowoomba/Australia

PostPosted: Sat Apr 13, 2013 9:53 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

khayyam wrote:

Hu ... thanks for the clarification, so really all this talk of "persistent" naming is just hogwash, because in 95% of use cases the interface names could remain as they were. To quote ssuominen "[...] eth0 will stay as eth0 and there is no risk of it being random... because there is nothing it would be random with, as being the only interface" ... so, basically, persistent, no risk of being random, etc. With that said the next obvious question then is why, at least for the percentage where this wouldn't be any kind of real issue.


I have been playing with 1 of the machines I look after, eth0 + eth1 + wlan0. With the persistent names disabled and no mac -> name mapping the same card is always eth0, the same card is always 1 and the wifi is always wlan0. If I turn on predictable names

eth0 is enp2s0. On board nic so it should be the same every time.

eth1 becomes enp4s0 or enp4s2. There is no guarantee it will be plugged into the same pci slot. The kernel gives me eth1 every time. Similar can be said about 2 other dual nic machines I look after.

wlan0 gives a choice of wlp0s29f7u1 wlp0s29f7u2 wlp0s29f7u3 wlp0s29f7u4 wlp0s29f7u5 wlp0s29f7u6 wlp0s29f7u7 wlp0s29f7u8 depending on which usb port it is plugged into. Without persistent names the kernel gives me wlan0 every time.

The eth0 only machines are eth0 every time, the eth0 + wlan0 machines are eth0 + wlan0 every time and the same can be said for the 2 eth0 + eth1 + wlan0 machines. Mac address -> name mapping I like the idea of if needed but with the so called predictable names I can immediately think of 7 machines that would go from working every time no matter how they were assembled to needing everything plugged in just right or networking is broken.
_________________
Beware the grue.


Last edited by Aiken on Sat Apr 13, 2013 10:38 pm; edited 1 time in total
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sat Apr 13, 2013 9:58 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

krinn wrote:
khayyam wrote:
With that said the next obvious question then is why, at least for the percentage where this wouldn't be any kind of real issue

already answered : https://forums.gentoo.org/viewtopic-p-7284724.html#7284724

krinn ... I see, wow. Well, I'm not sure what was said in the bug but those "three reasons" seem altogether bogus. As I said previously the cure in this case is worse than the disease.

best ... khay
Back to top
View user's profile Send private message
kurly
Apprentice
Apprentice


Joined: 02 Apr 2012
Posts: 253

PostPosted: Sun Apr 14, 2013 3:39 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

khayyam wrote:
I see, wow. Well, I'm not sure what was said in the bug but those "three reasons" seem altogether bogus. As I said previously the cure in this case is worse than the disease.

I hate to post with nothing to add, but I do want to say: A-freakin'-men. The idea that people are actually going along with this astounds me.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Apr 14, 2013 6:58 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

khayyam wrote:
Hu ... thanks for the clarification, so really all this talk of "persistent" naming is just hogwash, because in 95% of use cases the interface names could remain as they were.

If you are in such a case you are lucky, but in the remaining cases it breaks completely.
And please note that it is not only a question of your hardware. For instance, there are things like ppp over firewire which, if activated, add an additional eth* device: In times before persistent name rules, I had a lot of fun with that, especially since it was inpredictible and hard to find the cause (since 95% of the use cases had not such problems...).

I think, it would be reasonable if gentoo had default rules to rename eth*/wlan* to net%n/wnet%n and if all documentation and provided scripts would refer to net0/wnet0. This would stlil work in 95% of use cases, and the remaining cases could simply add an appropriate custom rule to make that standard scripts work for them. (In contrast, for scripts relying on eth%n/wlan%n it is not possible to add custom rules which work reliable.) An analogue happened already with cdrom symlinks AFAIK (mainly due to upstream like KDE which relied on sane symlink names instead of the kernel-provided names), so it would just be consequent, and this is the only thing which could be used consistently over the whole distirbution. (Yes, the disadvantage is one change for all users, but this change is sane because it is future-safe.)
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sun Apr 14, 2013 9:02 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

mv wrote:
khayyam wrote:
Hu ... thanks for the clarification, so really all this talk of "persistent" naming is just hogwash, because in 95% of use cases the interface names could remain as they were.

If you are in such a case you are lucky, but in the remaining cases it breaks completely.

mv ... I wasn't really speaking from the point of view of my own needs or what-have-you, I accept there is an issue here, and that the cases where this might cause problems should be addressed, but it seems the "fix" went beyond that, because if one searched the forum for cases where this was an issue the numbers of those effected by the "fix" would far outnumber those effected by the issue itself. This is what I ment by the cure is worse than the disease. Personally, I can remember only one instance in which the new schema would have prevented a rename, and so network breaking, but it was partly expected, and easily fixed. I don't imagine the switch to the new schema would cause me personally any headaches, but the question is why cause such disruption for the large majority of cases simply to impliment this, it would have been far simpler to have the old method as the default with the information provided as to how to impliment the new method ... such a senario would have been far more "predictable" and far less chaotic.

There is already the perception (however accurate, or factual) that systemd-udev is unreliable, likely to cause issues, has its own agenda, etc, etc, and so adding further fuel to that flame would seem to me a bad move, particularly when a lighter touch *could* have been employed.

mv wrote:
And please note that it is not only a question of your hardware. For instance, there are things like ppp over firewire which, if activated, add an additional eth* device: In times before persistent name rules, I had a lot of fun with that, especially since it was inpredictible and hard to find the cause (since 95% of the use cases had not such problems...).

I don't doubt the fix was needed, I'm meerly speaking to how the migration was implimented.

mv wrote:
I think, it would be reasonable if gentoo had default rules to rename eth*/wlan* to net%n/wnet%n and if all documentation and provided scripts would refer to net0/wnet0. This would stlil work in 95% of use cases, and the remaining cases could simply add an appropriate custom rule to make that standard scripts work for them.

But we have now migrated to the new schema as the default, perhaps this would have made sense prior to this migration but now it may only add to the confusion.

mv wrote:
(Yes, the disadvantage is one change for all users, but this change is sane because it is future-safe.)

I'm tempted to say "until" :) ... there is another thread where NeddySeagoon is quoted by others repeatedly, saying "it won't change again ... at least, not until udev changes again" and no comment given, I'm not sure if this is a silent protest or if they are simply being ironic, but it does point to a sentiment with regard to how "future-safe" such changes are.

best ... khay
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7101

PostPosted: Sun Apr 14, 2013 9:33 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

mv wrote:
Yes, the disadvantage is one change for all users, but this change is sane because it is future-safe

We don't have the same vision of future, as you aren't a seer, and as i'm not one too,..
For me, it will more looks like : all linux admin are incompetents as they just don't know how to handle their system, it's ok because you will pay support to have your problems fix that is beyond your admin skill.
But why would a company pay you money to be a crappy admin without skills, well, because you are a total wanker but with the "systemd certification".
Wonder who you will pay for the certification and support ?

May i remind you : All this crap is done to fulfill the whims of an optional tool, that now provide a hack to a previous hack and not a fix.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Apr 14, 2013 11:51 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

krinn wrote:
For me, it will more looks like : all linux admin are incompetents as they just don't know how to handle their system

How did anybody say this? What was said is that all udev versions <200 (probably including eudev) had a race condition which nobody realized or cared before. This race condition needs a fix because it makes all systems with more than one eth* unreliable. Since apparently it is hard (perhaps even impossible without serious changes to the kernel) to fix the race condition internally, the only possibility is to avoid the race condition at a first place - which according to KISS principle is probably better than to have some complicated fixes which could than fail for some other reasons.
Yes, the transition is inconvenient, especially for many systems which were not in danger to be hit by the race condition, but it is sane to separate kernel and user namespace instead of risking other complications again: This is what I mean by future-safe.
Quote:
it's ok because you will pay support to have your problems fix that is beyond your admin skill.

Who was talking about paying support? It is a renaming which was announced and which makes some work, but I think every gentoo user should be able to handle it by himself; it is reasonably documented and really no rocket science.
Quote:
All this crap is done to fulfill the whims of an optional tool, that now provide a hack to a previous hack and not a fix.

This optional tool was introduced to avoid race conditions at booting; from the beginning, it did it in the wrong way by not separating the namespaces. This has now been fixed. Yes, you can blame early udev of doing it the wrong way, but now "pushing" the fix on people is correct IMHO.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Apr 14, 2013 11:59 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

khayyam wrote:
But we have now migrated to the new schema as the default, perhaps this would have made sense prior to this migration but now it may only add to the confusion.

As I understood, the renaming to "net0" was recommended as well as keeping the new scheme: It depends on your needs, and gentoo is about choice. I would have preferred if the first alternative was more "pushed", but it was clearly visible in the announcements and I am rather optimistic that gentoo docs will use it (since it will be almost impossible to write readable docs for generic device names). Let's wait how the doc team deals with it...
Back to top
View user's profile Send private message
direwolf
Tux's lil' helper
Tux's lil' helper


Joined: 11 Jun 2003
Posts: 99
Location: Richmond, VA

PostPosted: Sun Apr 14, 2013 4:31 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

mv wrote:
Let's wait how the doc team deals with it...


If I implemented something in my company that broke systems unless the users were proactive making changes before they installed the update, and my documentation of the new implementation was deferred until some time after the implementation, well, I would be summarily fired. And rightly so.

Yea, I know there is a difference between a volunteer organization and paid professionals, but still...
_________________
========================================================
"Somebody has to do something, and it's just incredibly pathetic that it has to be us."
- Jerry Garcia
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Sun Apr 14, 2013 4:58 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

mv wrote:
Let's wait how the doc team deals with it...


With what? I mean, eth0, eth1, wlan0, wlan1, tun0, ppp4, whatever are provided as an example interface names in docs. The final determination of the interface name is not done by the docs,
but by the user using common sense.

We don't have that many documentation developers and since this is all work done by volunteers, I urge the intrested parties in providing patches to the docs. The docs are .xml files
and can be checked out from:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/

Code:

# emerge cvs
# cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co gentoo


And filing the patches and/or reports one bug per one document at https://bugs.gentoo.org/

I'm not sure what needs to be changed other than perhaps highlight the fact that "These names are provided as an example, use your real interface names instead of copy and pasting mindlessly."
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Apr 14, 2013 5:06 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

ssuominen wrote:
I'm not sure what needs to be changed other than perhaps highlight the fact that "These names are provided as an example, use your real interface names instead of copy and pasting mindlessly."

How about taking the names "net0" "wnet0" and suggesting udev rules of e.g. renaming KERNEL=="eth*" to NAME="net%n"? This would work for most users out-of-the-box except for those with really cumbersome setups who then need to either change the rules or interface names. Of course, adding the sentence you suggested wouldn't hurt in any case.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Sun Apr 14, 2013 5:19 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

direwolf wrote:
[If I implemented something in my company that broke systems unless the users were proactive making changes before they installed the update

So this is unrelated, since udev needs to be handled only after installing the update (and before next booting). These things happen not so infrequently in gentoo (e.g. any openrc update without calling etc-update is such an example). Seriously, if you cannot live with this for whatever reason (and/or do not read the news) then a rolling release distribution like gentoo is really nothing for you: You then need an enterprise distribution with long-term support. Of course, this would not safe you from the headaches and presumably the same big manual configuration changes at major updates either.
Quote:
and my documentation of the new implementation was deferred until some time after the implementation, well, I would be summarily fired.

I would fire you if you do not read the documentation. Of course, the news message and other documentation was available (and should have been clearly visible on your machine) with the upgrade - if not, it is a serious bug in portage which should be reported.
Back to top
View user's profile Send private message
direwolf
Tux's lil' helper
Tux's lil' helper


Joined: 11 Jun 2003
Posts: 99
Location: Richmond, VA

PostPosted: Sun Apr 14, 2013 6:26 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

mv wrote:

I would fire you if you do not read the documentation. Of course, the news message and other documentation was available (and should have been clearly visible on your machine) with the upgrade - if not, it is a serious bug in portage which should be reported.


Oh, I read it, and it simply didn't help, as I pointed out in another thread. This did not work at all:
Quote:

If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a symlink to /dev/null, the new names will be disabled and the kernel will do all the interface naming

At least not creating an empty file using touch. Some folks reported it worked symlinking to /dev/null, but I didn't try that.

This was espcially not helpful:
Quote:

You can get attributes of your network interfaces using a command like
the following (replace eth0 with the name of the appropriate interface):

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null


Mainly because it returns code without interpretation, and none of the documentation links really led to an answer without a lot of research, unless you already understand how things are working.

Code:

ID_NET_NAME_MAC=enx000c29d79696
ID_OUI_FROM_DATABASE=VMware, Inc.
ID_NET_NAME_PATH=enp2s0


If I decide to use ID_NET_NAME_MAC (everywhere in all of my links and configuration files) it will not work. When this happened with storage the UUID ended up working fine, but the MAC name doesn't without more configuration - something I didn't find without more research. And if you've picked wrong then the udevdam command doesn't work unless you can dig though the logs to find out what udev renamed eth0 TO, and you don't really need it then.

Anyway, I was responding to
Quote:
Let's wait how the doc team deals with it...


Which was clearly "Now that it's out there and everybody is dealing with it there will be documentation written and updated," which is backwards.
_________________
========================================================
"Somebody has to do something, and it's just incredibly pathetic that it has to be us."
- Jerry Garcia
Back to top
View user's profile Send private message
cwr
Veteran
Veteran


Joined: 17 Dec 2005
Posts: 1969

PostPosted: Sun Apr 14, 2013 6:42 pm    Post subject: Reply with quote

It's unfortunate that the udev fix is a really good idea (apparently) for people with large server
farms, and a real pain for everyone else. By a curious coincidence, RedHat makes a very good
living from supplying software to large server farms ...

eth0 has been a standard port name for what, 25 years. Forcing a name change for the millions
of people who use Linux on laptops or desktops, just to make life slightly easier for some sysadmins,
is a really bad idea. _Adding_ the option to use the new "fixed" names would have been a pretty
good idea.

The result is that when working on someone else's machine I have no idea what the ports are
called, and no way to explain to them which might be what. This isn't a problem for Gentoo
alone - it's going to be a source of considerable aggravation for all Linux users.

Will
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Sun Apr 14, 2013 9:58 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

ssuominen wrote:
The final determination of the interface name is not done by the docs, but by the user using common sense.

ssuominen ... except that its not only docs, eth0 and wlan0 are hardcoded in various patches, configuration files, and rcscript's, and when I say hardcoded, I mean not as 'examples' but unquoted vars, or explicit sed oneliners and '+ eth0'.

hardcoded eth0:
app-emulation/open-vm-tools/files/network
net-misc/cbqinit/files/cbq-1280.My_first_shaper.sample
net-misc/networkmanager/files/networkmanager-0.9.4.0-fix-quote-handling.patch
net-misc/knock/files/knockd.confd
net-misc/knock/files/knockd.confd.2
net-misc/knock/files/knockd.initd.2
net-misc/ipx-utils/files/ipx.confd
net-misc/gvrpcd/files/conf.gvrpcd
net-misc/ip-sentinel/files/ip-sentinel.conf.d
app-misc/g15stats/files/g15stats-1.9.7.confd
app-misc/g15stats/files/g15stats-1.0.confd
app-admin/amazon-ec2-init/files/amazon-ec2.init
app-admin/cancd/files/netconsole-conf.d
net-nds/ypbind/ypbind-1.33.ebuild
net-analyzer/ipband/ipband-0.8.1-r1.ebuild
net-analyzer/barnyard2/files/barnyard2.confd
net-analyzer/p0f/files/p0f.confd
net-analyzer/sancp/files/sancp.confd
net-analyzer/softflowd/files/softflowd.initd
net-analyzer/arpon/files/arpon.confd
net-analyzer/fprobe/files/conf.d-fprobe
net-analyzer/ifstatus/ifstatus-1.1.0.ebuild
net-analyzer/traffic-vis/files/traffic-vis.conf.d
net-analyzer/arpwatch/files/arpwatch.confd
net-analyzer/darkstat/files/darkstat-init.new
net-analyzer/barnyard/barnyard-0.2.0-r3.ebuild
net-analyzer/tcpreplay/tcpreplay-3.4.5_beta2.ebuild
net-analyzer/tcpreplay/tcpreplay-3.4.4-r2.ebuild
net-analyzer/tcpreplay/tcpreplay-3.4.5_beta3.ebuild
net-analyzer/tcpreplay/tcpreplay-3.4.4-r1.ebuild
net-analyzer/tleds/files/tleds.conf.d
net-firewall/ufw/files/ufw-0.31.1-conntrack.patch
net-firewall/ufw/files/ufw-0.33-conntrack.patch
sys-block/vblade/files/conf.d-vblade
net-fs/ncpfs/files/ipx.confd
net-im/reaim/files/reaim
media-plugins/vdr-systeminfo/files/systeminfo.sh
mail-filter/p3scan/p3scan-2.3.2-r2.ebuild
mail-filter/p3scan/p3scan-2.3.2-r1.ebuild
mail-filter/p3scan/p3scan-2.3.1.ebuild
media-video/ushare/files/ushare.conf.d
sys-apps/iproute2/files/iproute2-2.6.29.1-hfsc.patch

hardcoded wlan0:
net-wireless/hostapd/hostapd-1.1.ebuild
net-wireless/hostapd/hostapd-1.0-r4.ebuild
net-wireless/hostapd/files/hostapd-conf.d
net-wireless/hostapd/hostapd-2.0.ebuild
net-wireless/wpa_supplicant/wpa_supplicant-0.7.3-r5.ebuild
net-wireless/wpa_supplicant/wpa_supplicant-1.1.ebuild
net-wireless/wpa_supplicant/files/wpa_supplicant_at.service
net-wireless/wpa_supplicant/wpa_supplicant-2.0.ebuild
net-wireless/ndiswrapper/ndiswrapper-1.58.ebuild
net-wireless/ndiswrapper/ndiswrapper-1.57.ebuild
net-wireless/ndiswrapper/ndiswrapper-1.58_rc1.ebuild
net-wireless/broadcom-sta/broadcom-sta-5.100.82.112-r2.ebuild
net-wireless/ipw3945/ipw3945-1.2.2-r1.ebuild
app-laptop/pbbuttonsd/files/wireless

There are also packages, like x11-misc/i3status and no doubt others, that install their default conf to /etc with eth0 and wlan0 defined as vars.

ssuominen wrote:
We don't have that many documentation developers and since this is all work done by volunteers, I urge the intrested parties in providing patches to the docs.

You, and whoever else decided that it was far better to push the new persistent naming rather than a more gradualist approach, *could* have stuck to the old "broken" eth0/wlan0 and most of this could be taken care of as time, resources, etc, were available. You have adopted the very same mindset as upstream, push the changes and should anyone have any issues then they can "submit patches" (Poeterings favourite slogan), or you can claim that its "broken", and so *really* its someone elses problem.

ssuominen wrote:
I'm not sure what needs to be changed other than perhaps highlight the fact that "These names are provided as an example, use your real interface names instead of copy and pasting mindlessly."

... and here is a perfect example, when did we users become "mindless" copy pasters? ... and what about all the config files, rcscripts, patches, etc, listed above? Perhaps all these should now be installed to /usr/share/doc as "examples" for us to mindlessly copy paste? Or perhaps we're just too stupid to figure out that those files installed in /etc are henceforth just examples?

Really, its not so much the resistance to change that is at issue here, but that these changes are presented as sensible and necessary, when in fact they are not. The migration to persistent naming *could* have been done in a much more gradual manner, giving those who needed such a feature the ability to implement it, and those (the great majority) who didn't the opportunity to defer. During such a transition other issues, such as the above packages, documentation, etc, could have been transitioned and solutions found. In all, a saner, and more manageable, approach.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Mon Apr 15, 2013 6:32 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

direwolf wrote:
nyway, I was responding to
Quote:
Let's wait how the doc team deals with it...

Which was clearly "Now that it's out there and everybody is dealing with it there will be documentation written and updated," which is backwards.

These docs are about new installations and need to be rewritten before new udev settings hit the installation cd. Of course, the sooner the better, but it llies in the nature of things (lack of manpower) that these docs are always behind. You cannot expect that to be updated for all new packages in time.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7113
Location: Austria

PostPosted: Mon Apr 15, 2013 5:24 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

khayyam wrote:
ssuominen ... except that its not only docs, eth0 and wlan0 are hardcoded in various patches, configuration files, and rcscript's, and when I say hardcoded, I mean not as 'examples' but unquoted vars, or explicit sed oneliners and '+ eth0'.

Without having looked at them, one could argue those packages are broken, or at least their configs need editing before usage. However, that holds true for a lot of packages; you look at config files after installation because they are not fit for usage without adaption to your settings. There never was a guarantee either eth0 or wlan0 were present on a system even before the change.

khayyam wrote:
ssuominen wrote:
I'm not sure what needs to be changed other than perhaps highlight the fact that "These names are provided as an example, use your real interface names instead of copy and pasting mindlessly."

... and here is a perfect example, when did we users become "mindless" copy pasters? ... and what about all the config files, rcscripts, patches, etc, listed above? Perhaps all these should now be installed to /usr/share/doc as "examples" for us to mindlessly copy paste? Or perhaps we're just too stupid to figure out that those files installed in /etc are henceforth just examples?

You probably misunderstood that.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 5881

PostPosted: Mon Apr 15, 2013 6:55 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

Aiken wrote:
wlan0 gives a choice of wlp0s29f7u1 wlp0s29f7u2 wlp0s29f7u3 wlp0s29f7u4 wlp0s29f7u5 wlp0s29f7u6 wlp0s29f7u7 wlp0s29f7u8 depending on which usb port it is plugged into. Without persistent names the kernel gives me wlan0 every time.

To avoid this kind of ambiguity and confusion, I place the following algorithm in the public domain and propose it to the systemd project:

  • Enumerate all possible names for a network device and pick the highest-numbered one not currently claimed by any other device. This will be just as stable as the current scheme, if not more.
  • Expand the numbers in the generated name by repeating the character beforehand, resulting in a readable unique text string without complicated numbers, which would confuse our users who can only blindly copy and paste according to the maintainers.
  • Fold to uppercase so as to not clash with future kernel device naming schemes, as the kernel will almost certainly want to adopt systemd's world-changing ideas for itself.
  • Obviously this could potentially result in unwieldy long device names, so the longest repeated substring will be dropped from the result. "S" repeated 29 times in this case.

Under this new scheme, which I expect udev will be switching to the instant everyone has recovered from the current fallout, your network card will now be named "WLFFFFFFFUUUUUUUU"
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Apr 15, 2013 7:27 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

genstorm wrote:
khayyam wrote:
ssuominen ... except that its not only docs, eth0 and wlan0 are hardcoded in various patches, configuration files, and rcscript's, and when I say hardcoded, I mean not as 'examples' but unquoted vars, or explicit sed oneliners and '+ eth0'.

Without having looked at them, one could argue those packages are broken, or at least their configs need editing before usage. However, that holds true for a lot of packages; you look at config files after installation because they are not fit for usage without adaption to your settings. There never was a guarantee either eth0 or wlan0 were present on a system even before the change.

genstorm ... I don't think broken is the correct term here, they had sane defaults that under most circumstances would function, and mostly they worked because in the great majority of cases there was an eth0 or wlan0. There are many other instances in which default parameters are set and which similarly work for the majority of cases. This true for @system and useflags ... none of these defaults are going to meet every possible case, but will in most cases be sufficent. So, its not about "guarentees" or the expectation that no user will ever have to face having to edit some file, but about having things work in most cases without such a requirement. So, yes, in some cases this didn't work, but having defaults which work in the great majority of cases isn't in itself broken. Anyhow, you didn't really comment on my main point which was that the migration *could* have been done in a more gradualist manner, which would have provided time, resources, etc (which was stated in short supply) for the above mentioned "broken" packages, the documentation, etc, to be addressed.

genstorm wrote:
khayyam wrote:
ssuominen wrote:
I'm not sure what needs to be changed other than perhaps highlight the fact that "These names are provided as an example, use your real interface names instead of copy and pasting mindlessly."

... and here is a perfect example, when did we users become "mindless" copy pasters? ... and what about all the config files, rcscripts, patches, etc, listed above? Perhaps all these should now be installed to /usr/share/doc as "examples" for us to mindlessly copy paste? Or perhaps we're just too stupid to figure out that those files installed in /etc are henceforth just examples?

You probably misunderstood that.

No, I don't think I did, you unfortunately cut what was prior, of which this is an "example". The problem is not with how the migration was implimented, all that is necessary to fix things good and proper, the problem is those mindless copy pasters, or those not sending patches to fix up the discrepencies in the documentation. Unfortunately you also cut what came subsequently, in which I was a lot more diplomatic, but ok, all this is just needless whining, that is if your convinced there was no other option and that all of this was entirely unavoidable.

best ... khay
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 412
Location: Gainesville, FL, USA

PostPosted: Mon Apr 15, 2013 7:31 pm    Post subject: This is how they should have done it! Reply with quote

The names eth0, eth1, etc. are in tons of packages and are in line with a longstanding practice.

Names like enp3s0 are INCREDIBLY obnoxious. They're harder, they are *not* predictable (try moving them do a different slot) and they break tons of software and lots of old rules. Making the wholesale changes this madness requires will result in lots of breakage.

When I describe this situation to the sysadmins where I work (which is on Debian Squeeze), they are just horrified at the prospects.

Someone didn't think this through!! If the core of the problem is older-udev interface renaming introduced race conditions, why go with the fix that causes maximal trauma?

It would be far, far better to patch the kernel so that it would use a different name pattern for interfaces, say "ethproto", and set up udev to do the naming to the sane names that don't force everything else to get patched. If you wanted to use the "predictable" naming, there would be nothing stopping you. What you would still be able to do is keep names like eth0 and eth1.

Rather than a hardcoded kernel patch, it would be better to set up that base interface name to be settable on the kernel command line. That way, the kernel could default to "eth" so that systems without udev would still be able to start up.

Let's get back to sanity!
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4214
Location: Dallas area

PostPosted: Mon Apr 15, 2013 8:02 pm    Post subject: Reply with quote

I don't have a problem being considered a mindless copier/paster as I recognize that without all of us zombies :lol:
there would be no need for devs with or without attitudes.

8)
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Mon Apr 15, 2013 8:41 pm    Post subject: Re: This is how they should have done it! Reply with quote

ssuominen wrote:
And name one software where the interface name isn't configurable, name one software that's in fact broken by the change, because I'd really like to know -- nobody has reported any.

In fact they have: bug #455896 ... and a post in the forum with this issue from today.

best ... khay
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 412
Location: Gainesville, FL, USA

PostPosted: Mon Apr 15, 2013 8:45 pm    Post subject: Reply with quote

Mr. ssuominen, I submit that you are the one who is not paying attention. The very most predictable interface name is eth0. While I can certainly see advantage to names like net0, lan0, or wan0, it is eth0 and eth1 that make the most sense for anyone having only one basic wired interface and maybe one wireless one.

My proposal was to have it so that the kernel would generate names using a pattern other than eth%d. This would eliminate the race condition and still allow for udev to assign names like eth0. This eliminates immense amounts of trauma. Think of the people who have to do remote administration. Think about the people who have to tend to many machines. Do you have a fundamental dislike for the name eth0? Why do you want to impose your draconian solution on everyone--especially one that has to be done RIGHT NOW?

Using net.ifnames=0 is a partial solution. It's OK if the kernel's enumeration of devices is the same as what you want, but if you want to force a different ordering, you're out of luck.

Yesterday khayyam listed 56 packages with hardcoded eth0 or wlan0. In addition to that are the many firewall rulesets or miscellaneous scripts that people have written. Just speaking about those firewall rules and scripts, this means finding them all and then making the changes and *testing* them. I've got lots of scripts like that.

So, why not go with a solution that removes the need to move from eth%d and still resolves the race issue?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6293

PostPosted: Mon Apr 15, 2013 9:03 pm    Post subject: Reply with quote

miket wrote:
My proposal was to have it so that the kernel would generate names using a pattern other than eth%d.

This suggestion is not new. I replied in this post why it does not work: Linus will certainly not change a non-broken kernel interface in an incompatible way just because a userspace tool did not handle it properly. In fact, such a change in the kernel would force users to use the kernel with a corresponding udev version - systems with older udev or no udev would break.
This is the disadvantage of the unix philosophy "one tool one job"...
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7113
Location: Austria

PostPosted: Mon Apr 15, 2013 9:20 pm    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

khayyam wrote:
but ok, all this is just needless whining, that is if your convinced there was no other option and that all of this was entirely unavoidable.

Well, I've had my gripes with the new naming, but I found the news item quite informative and simply dealt with it. Everyone else was free to choose not to emerge the udev update just then and wait for best moment, gather more info, whatever.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 3 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum