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
snake111
Tux's lil' helper
Tux's lil' helper


Joined: 18 Dec 2004
Posts: 113

PostPosted: Thu Apr 04, 2013 10:41 pm    Post subject: Reply with quote

Thank you, I got it sorted as desired! :D

FYI:

Code:

# cp /lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/
# nano /etc/udev/rules.d/80-net-name-slot.rules


80-net-name-slot.rules

Code:

ACTION=="remove", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="net_name_slot_end"

NAME=="", ENV{ID_NET_NAME_ONBOARD}=="eno1", NAME="net0"
NAME=="", ENV{ID_NET_NAME_PATH}=="wlp3s0", NAME="net1"

NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"

LABEL="net_name_slot_end"


I added the first two lines starting with NAME=="". I chose to map my old eth0 using ID_NET_NAME_ONBOARD identifier and call new interface net0.
Since I don't have the same identifier in my old wlan0 I chose instead ID_NET_NAME_PATH and mapped it to net1.

Since I'm on a laptop, if wifi card is replaced, the rules for net1 still apply since the new one will have the same physical/geographical location of hw connector, hence the same value for ID_NET_NAME_PATH. :D
Back to top
View user's profile Send private message
Aiken
Tux's lil' helper
Tux's lil' helper


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

PostPosted: Thu Apr 04, 2013 10:46 pm    Post subject: Reply with quote

snake111 wrote:
Given that is good to use the new names, the whole point in my opinion is down to:

1- Stick with auto-chosen names: enp0s25 and wlp3s0 in my case
2- Map auto-chosen names to be user friendly like net0 and net1


With point 1 I gather the name is dependant on the slot the network card is in so if a machine has to be stripped down for any reason and the network card is put in a different slot the predictable name is now different. Makes the interface name not so predictable.

If I had to change I would go point 2. At least with point 2 of mapping a mac to a name I can see the name staying the same unlike point 1.

I have 2 headless servers with 2 nic each still running with their original 70-persistent-net.rules and never seen a rename. Have another machine with the new names disabled and no mac -> name mapping and eth0 & eth1 always come up as expected. With a computer with 1 nic or 1 nic + 1 wifi which covers most of the computers I look after I don't see the point in this change at all. They are all staying eth0 or eth0 + wlan0. With the dual nic machines I have not had the problems described in the document trying to rationalize this change.

Which leaves me with if eth0 or eth0 + wlan0 works as expected now why change anything?
_________________
Beware the grue.
Back to top
View user's profile Send private message
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Sun Apr 07, 2013 9:13 am    Post subject: Reply with quote

I like the whole idea of persistant names a lot. The only time a (path based) if name should ever change, is if you move it in your system. That is something you control and know when it happens, so you'll deal with it. Changing if names when adding hardware etc is highly annoying so I get the change. Btw, this sorta is a lot more annoying with USB networking hardware, which some of us are doomed to have to use (hp microservers are awesome but have a very limited pci slots).

That said I like where you are going with this:
snake111 wrote:
Thank you, I got it sorted as desired! :D

FYI:

Code:

# cp /lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/
# nano /etc/udev/rules.d/80-net-name-slot.rules


80-net-name-slot.rules

Code:

ACTION=="remove", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="net_name_slot_end"

NAME=="", ENV{ID_NET_NAME_ONBOARD}=="eno1", NAME="net0"
NAME=="", ENV{ID_NET_NAME_PATH}=="wlp3s0", NAME="net1"

NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"

LABEL="net_name_slot_end"



But this _replaces_ the 80-net rule. I mean, when there's an update in /lib it won't get used, if something decides to copy the rule from /lib to /etc its screwed. Having this file renamed to 81 (not 90, as 90 is some rules based on networking, so imo bad) instantly makes it no longer functioning. I guess it is because NAME=="" is now false? isn't the name now eno1?

I tried my udev mojo, but know too little of it. What I would assume, is have /lib/80-net in place and executed as normal (and thus /etc/80-net deleted). Then have an 81-net rule, that should only have:
Code:

ACTION=="remove", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"

Skip if the nic is removed or its not in the net section, keep that.
Code:

NAME=="wlp3s0", NAME="net1"

Rename to something sensible; done.
Of course this doesn't work any my udev mojo is weak. Why not?
And why oh why can't we just have an alias (symlink even). I'm fine with having wlp3s0 on my system, but from scripts, config etc i just want to name it net1. Net1 simply always points to the right adapter. Nobody thought of this? Really?

anyway, anybody who can help me with my weak udev mojo, and put down the most simple rule that will work? (Not based on mac, mac's can be wrong/changed etc due to modem demands for example, or cheap chinese hardware etc).
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 3907

PostPosted: Sun Apr 07, 2013 9:49 am    Post subject: Reply with quote

oliv3r wrote:
I'm fine with having wlp3s0 on my system, but from scripts, config etc i just want to name it net1. Net1 simply always points to the right adapter. Nobody thought of this? Really?


I did, and i have filebug for that.
As only users using udev that have multi network cards may enjoy the new scheme, well easy, with only 1 network card, kernel could never mess up your eth* names, i suggest disabling new naming scheme per default for udev.
This way, any gentoo users will still get old style naming eth* easier the networking handling as this would make a common networking scheme for mostly all gentoo users, because users without udev, or with udev but only 1 network card will keep using eth* naming convention.
Easy to help users in forum, easy to use generic scripts that aim at a known eth* name instead of a specific unknown es*, ensp*... or the like name given by this new naming scheme.

And because i think i put a foot into some kinda of internal war, my query was dismiss and my bug restrict so only devs could read it (lol free speech at its highest level)

Here's the 3 reasons gave to reject that :
-It's a feature enabled by default at upstream level and there is no reason to
disable it at Gentoo level.
-Leaving users with possible random kernel assigned names by default would be
same as introducing a regression.
-Plus udev is the default dev-manager used in Gentoo, so it's really irrelevant
if others don't support it
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3783

PostPosted: Sun Apr 07, 2013 12:24 pm    Post subject: Reply with quote

oliv3r wrote:
Having this file renamed to 81 (not 90, as 90 is some rules based on networking, so imo bad) instantly makes it no longer functioning.

I guess this is so because some /lib/udev/rules.d/??-* file already assigns a value to NAME where ?? comes alphabetically before 81 (I would guess ?? is 80 but I am using eudev, so I cannot check easily). So your file should be alphabetically before that ?? number. I would guess having your file renamed to 79 or earlier would work.
Back to top
View user's profile Send private message
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Sun Apr 07, 2013 1:44 pm    Post subject: Reply with quote

First of all, I ment that an alias should be possible.

Even for single Ethernet systems this is a good change. Firstly, it keeps things consistent. Secondly what happens if you plug in an USB wifi adaptor. And you reboot and keep it connected. And there you go, its messed up. Or we get Ethernet adaptors for the HDMI port (1.4 overs Ethernet). All of a sudden, a whole lot of systems have extra Ethernet ports. So this is good.


Back on topic, I noticed that with this new ruleset, eth0 gets directly renamed to net0, without the new persistent name in between. That is fine, but now i'm worried about file constancy in /etc. Imo /lib/udev/rules.d/80-net* should have an include section that lets you define your own devices. 'hackjob' alias :)

So how would I best do this?

@mv oh yeah, I know how to get a 'copied and modified' file to work properly. Now that you mention it though, yes 79-my-list.

Here's the above snipped with some comments.

Code:

ACTION=="remove", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"
# skip if remove, not net or empty name. makes sense; though net_name_slot_end may be removed to my_net_name_slot_end?

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="net_name_slot_end"
# would these two be needed? It should be save to remove? On second thought, it only checks if there even are valid interfaces(names) so no interface, we can skip this too.

NAME=="", ENV{ID_NET_NAME_ONBOARD}=="eno1", NAME="net0"
NAME=="", ENV{ID_NET_NAME_PATH}=="wlp3s0", NAME="net1"
# Leave this, this is the good stuff.

NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
#so only remove this. 80-net* takes care of this

LABEL="net_name_slot_end"
# leave the label, it's needed.


As to why use 79, we want it to be processed JUST before 80-net. so 79 is good. 70 is to 'far away' in my opinion. Better would have been 80.0 and 80.1 ;)

Only problem having 2 near identical files is the overhead coming from parsing it twice.
Any thoughts?
Back to top
View user's profile Send private message
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Mon Apr 08, 2013 4:33 pm    Post subject: Reply with quote

First a minor correction to my net.ifnames comment. That check is there not to see if there's ifnames defined, but whether we use the new scheme or not. So good to keep.

So this seems to only work half of the time, and have serious doubt the 80-net thing works at all properly. But it maybe the whole 79 thing what I've build.

I now have 5 renames in my file, (I have a quad intel nic +onboard nic).

It managed to rename 2 of the 5 interfaces, but re-renamed it later again even. So while this works for 2 interfaces and maybe 3, for 4 or 5 it fails. Racing condition? I can't check udevadm monitor, since this all happens at boot. And even bringing down the interfaces doesn't help, since udev simply doesn't touch the interfaces anymore (or does exactly the same thing? doubtful).

So where can we discuss this properly? Because it doesn't seem to really work all that well. If the 'answer' is to use 80-net-names instead, how will we maintain its concistancy? E.g. adapt to changes in udevd (god knows what can happen there) or being overwritten? We can't use 81-my-net as you can't seem to rename an already renamed device. I still feel 79 is a good index to use, or have an 'include' section midway 80-net-name.

Any thoughts (don't be shy).
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3783

PostPosted: Tue Apr 09, 2013 7:50 am    Post subject: Reply with quote

I would not rely on several renamings - this certainly needs to similar race conditions as the original method.
Why don't you just rename the interfaces similarly as the previous rules just using possibly different tests?
E.g. is it not possible to write some rather early rule (e.g. 40-*) with
Quote:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEMS=="pci", KERNEL=="eth*", NAME="net0", OPTIONS="last_rule"
where (if you have more than one pci ethernet card) you might also enter other information encoded into the new default name which you find out with
Code:
udevadm info --path=/sys/class/net/net0 --query=all --attribute-walk
(once again, I am an eudev user and did not try - syntax might have diverged already).
Back to top
View user's profile Send private message
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Tue Apr 09, 2013 9:22 am    Post subject: Reply with quote

mv wrote:
I would not rely on several renamings - this certainly needs to similar race conditions as the original method.
Why don't you just rename the interfaces similarly as the previous rules just using possibly different tests?
E.g. is it not possible to write some rather early rule (e.g. 40-*) with
Quote:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", SUBSYSTEMS=="pci", KERNEL=="eth*", NAME="net0", OPTIONS="last_rule"
where (if you have more than one pci ethernet card) you might also enter other information encoded into the new default name which you find out with
Code:
udevadm info --path=/sys/class/net/net0 --query=all --attribute-walk
(once again, I am an eudev user and did not try - syntax might have diverged already).


Doubt that rule works, I have a quad port intel card, which only diverse in 'function'. Anyway, i'm not 'double renaming' anymore. I have the ruleset up 79-my.rules thus should be executed before 80-net-names.rules. Netname rules pickup whatever I didn't explicitly set.
Back to top
View user's profile Send private message
Fran
Guru
Guru


Joined: 29 Feb 2004
Posts: 518
Location: Coruña (Spain)

PostPosted: Tue Apr 09, 2013 10:42 am    Post subject: Reply with quote

I'm trying eudev beta3 which implements predictable net names. I changed conf.d/net with :%s/eth0/enp1s0/, modified my iptables script, removed net.eth0, linked the new net.enp1s0, added it to the default runlevel... and everything seems to work ok, but booting gets stuck for 1 minute in "bringing up interface enp1s0". After booting all things network-related work, but that 1 minute wait is ANNOYING. Does this happens to anyone with udev-200 os is it eudev specific?

(edit) Oops, I see in dmesg something that didn't appear before:

[ 7.797329] USB Video Class driver (1.1.1)
[ 70.925472] r8169 0000:01:00.0 enp1s0: unable to load firmware patch rtl_nic/rtl8168e-2.fw (-2)
[ 70.937962] r8169 0000:01:00.0 enp1s0: link down
[ 70.937965] r8169 0000:01:00.0 enp1s0: link down
[ 71.211958] NET: Registered protocol family 10
[ 71.212393] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
[ 73.005708] r8169 0000:01:00.0 enp1s0: link up
[ 73.005720] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready
[ 77.480837] tun: Universal TUN/TAP device driver, 1.6

There is the 1 minute wait. Do latest udevs change something related to firmware loading?

(edit 2) https://forums.gentoo.org/viewtopic-t-899002-start-0.html. Emerging linux-firmware solved it.
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3705

PostPosted: Tue Apr 09, 2013 11:50 am    Post subject: Reply with quote

Quote:
There is the 1 minute wait. Do latest udevs change something related to firmware loading?


would be interested in this too as im having the same issue with my wifi card on my laptop.
As far as i know kernel firmware loading is suggested if you are running kernel >3.8 but at least here i have 1 min wait with current 3.9-rc5( or rc6) and it doesnt matter if i enable/disable the firmware-loader USE, results are always the same.

Quote:
Emerging linux-firmware solved it.


do you mean that installing the hole firmware package instead of the specific one for your hardware fixed it for you ? That sounds weird.

TIA
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2000
Location: Finland

PostPosted: Tue Apr 09, 2013 12:07 pm    Post subject: Reply with quote

Fran wrote:
There is the 1 minute wait. Do latest udevs change something related to firmware loading?

(edit 2) https://forums.gentoo.org/viewtopic-t-899002-start-0.html. Emerging linux-firmware solved it.


Yes, firmware loading should be done by the kernel now starting with Linux 3.8 and higher.

If kernel is configured correctly to load the required firmware(s), then USE="firmware-loader" can be disabled in sys-fs/udev.

Misconfiguration would cause delays.
Back to top
View user's profile Send private message
Fran
Guru
Guru


Joined: 29 Feb 2004
Posts: 518
Location: Coruña (Spain)

PostPosted: Tue Apr 09, 2013 12:41 pm    Post subject: Reply with quote

ssuominen: eudev beta3 doesn't have a firmware-loader use flag, so I assume the devs want >xxx-sources-3.8 (either that or it's a bug in the eudev ebuild). (edit) Or maybe I misunderstood you. Installing linux-firmware is unnecessary starting from kernel 3.8? Or is it the opposite? Because I certainly didn't need it with older udevs / eudev beta2 and I need it now with eudev beta3.

gringo: no need to install all the firmwares; linux-firmware has a savedconfig use. Just put in /etc/portage/savedconfig/sys-kernel/linux-firmware-<version> the blobs you need. In my case I put
Code:
iwlwifi-1000-5.ucode
radeon/R600_rlc.bin
rtl_nic/rtl8168d-2.fw
rtl_nic/rtl8168e-2.fw

(I use the binary packages this machine generates in 4 other computers, hence the two different rtl blobs).

And yes, I removed iwl1000-ucode and radeon-ucode. I prefer the linux-firmware+savedconfig route. I didn't have any rtl-firmware package installed before. I didn't seem to need it. With eudev beta3 I do need it.
Back to top
View user's profile Send private message
Fran
Guru
Guru


Joined: 29 Feb 2004
Posts: 518
Location: Coruña (Spain)

PostPosted: Wed Apr 10, 2013 7:43 am    Post subject: Reply with quote

A word of caution: google-musicmanager will stop working with this. I thought the login was failing due to typos in the password, until I searched on google and found out that the program needs ethX or wlanX named interfaces (seriously, what the fuck where you thinking, google programmers).

You get a warning when you install google-musicmanager (found out later), but not if you already had it installed.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2000
Location: Finland

PostPosted: Wed Apr 10, 2013 8:12 am    Post subject: Reply with quote

Fran wrote:
ssuominen: eudev beta3 doesn't have a firmware-loader use flag, so I assume the devs want >xxx-sources-3.8 (either that or it's a bug in the eudev ebuild). (edit) Or maybe I misunderstood you. Installing linux-firmware is unnecessary starting from kernel 3.8? Or is it the opposite? Because I certainly didn't need it with older udevs / eudev beta2 and I need it now with eudev beta3.


eudev is just poorly packaged and doesn't provide the required USE flag to use the new kernel firmware loader instead of the old userspace firmware loader.
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2204
Location: UK

PostPosted: Wed Apr 10, 2013 12:01 pm    Post subject: Reply with quote

The irony is that both the kernel firmware loader and eudev itself were created because udev broke it first...
Back to top
View user's profile Send private message
expressionlibre
n00b
n00b


Joined: 30 May 2008
Posts: 12
Location: France

PostPosted: Fri Apr 12, 2013 5:38 pm    Post subject: Fail2ban doesn't like new predictable names Reply with quote

Hi,
I really wanted to try using new "predictable names".
First I had to change : /etc/conf.d/net + symlinc in /etc/init.d + firewall rules... I thought it was enough. Helas :
Fail2Ban did not work any more.

In some Fil2ban files you have code like this :
Code:
myip = `ip -4 addr show dev eth0 | grep inet | head -1 | sed -r 's/.*inet ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*/\1/'`


Well I could also change this of course... But No... :evil:
I really don't want to scan every soft that may also contain references to "eth" devices and modify the code.

So I finally had to give ancient name back to my "ensXpY" with that easy udev rule :
(Hope it will last a few emerges :) )

Code:
cat /etc/udev/rules.d/70-my-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="my:mac:ad:dr:es:ss", NAME="eth0"

_________________
63N700 15 7H3 8357
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3783

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

expressionlibre wrote:
I really don't want to scan every soft that may also contain references to "eth" devices and modify the code.

It is better to fix things than to leave them in a half-working state: "grep" exists and is working well :wink:
Quote:
So I finally had to give ancient name back to my "ensXpY" with that easy udev rule :
(Hope it will last a few emerges :) )

Maybe a few emerges, but less likely a few boots: If your kernel ever provides some eth1 (either because of a hardware- or a software-option), the above rule will work at most by accident.

To say it clearly: I was always wondering how udev could be able to rename these devices - I thought it must be an extremely tricky code doing all sorts of locks/mutex-stuff/whatever to avoid race conditions - until I learnt that udev just relied on race conditions working by accident; if I knew that earlier I would have protested earlier. This time Lennert was completely right: He fixed something which was severely broken by concept. It might perhaps have been possible to fix the race condition problem - I am not enough a kernel hacker to know all interfaces which might allow this, so I do not know whether this might have been really possible - but failing that the chosen solution is rather sane:

It was a bad idea from the very beginning of udev to take the "logical" names and the "kernel" names from the same namespace. Of course, the motivation was to preserve existing programs which rely on kernel names, but the cleaner way is certainly to change all these programs. The earlier you start to fix this the better...
Back to top
View user's profile Send private message
khayyam
Veteran
Veteran


Joined: 07 Jun 2012
Posts: 1538

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

expressionlibre wrote:
In some Fil2ban files you have code like this :
Code:
myip = `ip -4 addr show dev eth0 | grep inet | head -1 | sed -r 's/.*inet ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}).*/\1/'`

expressionlibre ... I can't say I'm impressed with this "fix", to me the cure is worse than the disease. That aside, the above isn't really a problem, its dead easy to replace one known string with another:

Code:
# sed -i.bak 's/eth0/ensXpY/g' input

expressionlibre wrote:
I really don't want to scan every soft that may also contain references to "eth" devices and modify the code.

Its actually not a huge task, somthing like grep, sys-apps/ack, or ag (sys-apps/the_silver_searcher), can find each instance of 'eth0' and sed, or perl, can be used to replace ...

Code:
# sed -i.bak 's/eth0/ensXpY/g' $(ag -l eth0 /etc)

... actually the above myhost variable would be best replaced in its entireity :)

Code:
myip = "$(ip -4 a s dev ensXpY | awk 'END{sub(/\/.*/,"");print $2}')"

expressionlibre wrote:
So I finally had to give ancient name back to my "ensXpY" with that easy udev rule :
Code:
cat /etc/udev/rules.d/70-my-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="my:mac:ad:dr:es:ss", NAME="eth0"

My understanding is that the old naming convention can't be kept, but then I've been keeping well clear of reading the various news items, wiki and forum posts, etc, on the subject. AFAIK, that is now "broken" and you have to get with the new naming regime, or rename to something like "wan0".

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


Joined: 02 May 2003
Posts: 3907

PostPosted: Sat Apr 13, 2013 10:47 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

mv wrote:
This time Lennert was completely right: He fixed something which was severely broken by concept.

1/ this thing X sucks
2/ I will replace it with Y, no i don't need to think how i will do, i will just do my way. Breaking everything is not a problem. Looking at why X was made is not an issue, because X was made like that because of X devs are stupids, not because of an issue they met.
3/ Tada everything is now broke but Y kick X'ass bad.
4/ Oh shit, Y doesn't work but it's because X was lame.
5/ Redo Y and rebreak everyone system to fix Y (not because Y sucks and was badly made ! It's still X that sucks)
6/ Re-re-redo Y, yeah using the same concept : don't think about it, just do it. But this time, people may see you have done Y like a shit, and the it's X's fault may not work, better rename Y to Z.
7/ pre-rename phase : "Ah yes, i'm going to make Z, Z will be what Y was made for, Y was half-way to Z, a temp solve to X hell. Z will fix the broken concept of ... X (yeah again).

So it's that ? udev is at step 5 ? or we're at 7 already and i miss the "udev was a temporary solution, and systemd is the final fix" announce ?
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3783

PostPosted: Sat Apr 13, 2013 11:23 am    Post subject: Re: Fail2ban doesn't like new predictable names Reply with quote

krinn wrote:
1/ this thing X sucks
2/ I will replace it with Y, no i don't need to think how i will do, i will just do my way. Breaking everything is not a problem. Looking at why X was made is not an issue, because X was made like that because of X devs are stupids, not because of an issue they met.
3/ Tada everything is now broke but Y kick X'ass bad.
4/ Oh shit, Y doesn't work but it's because X was lame.
5/ Redo Y and rebreak everyone system to fix Y (not because Y sucks and was badly made ! It's still X that sucks)
6/ Re-re-redo Y, yeah using the same concept : don't think about it, just do it. But this time, people may see you have done Y like a shit, and the it's X's fault may not work, better rename Y to Z.
7/ pre-rename phase : "Ah yes, i'm going to make Z, Z will be what Y was made for, Y was half-way to Z, a temp solve to X hell. Z will fix the broken concept of ... X (yeah again).

So it's that ? udev is at step 5 ? or we're at 7 already and i miss the "udev was a temporary solution, and systemd is the final fix" announce ?

:lol:

I think we are at 5, although it is not Lennart who did 2-3 but the original udev maintainers. This is the reason why he can admit that Y sucks as well. Steps 6 and 7 comes probably only for people running the systemd operating system.
Back to top
View user's profile Send private message
wolfieh
n00b
n00b


Joined: 17 Nov 2009
Posts: 52

PostPosted: Sat Apr 13, 2013 5:47 pm    Post subject: Reply with quote

This has a bad side effect on usb network hardware: the device name will be different depending on what usb port you plugged it in.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8592

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

khayyam wrote:
My understanding is that the old naming convention can't be kept, but then I've been keeping well clear of reading the various news items, wiki and forum posts, etc, on the subject.
No. You can instruct udev not to manipulate interface names at all, in which case names are exactly what they would be if you never ran udev. They will be assigned by the kernel in an order determined by the kernel, which may or may not be the same across boots, depending on your hardware and the kernel drivers. Some systems have perfectly stable names from one boot to the next even with multiple NICs installed. Some do not. If you have only one NIC and you will never add more, you have a very good chance that the udev-free naming scheme will work well for you.
Back to top
View user's profile Send private message
khayyam
Veteran
Veteran


Joined: 07 Jun 2012
Posts: 1538

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

Hu wrote:
khayyam wrote:
My understanding is that the old naming convention can't be kept, but then I've been keeping well clear of reading the various news items, wiki and forum posts, etc, on the subject.

No. You can instruct udev not to manipulate interface names at all, in which case names are exactly what they would be if you never ran udev.

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.

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


Joined: 02 May 2003
Posts: 3907

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

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
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 2 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