| View previous topic :: View next topic |
| Author |
Message |
snake111
Tux's lil' helper
Joined: 18 Dec 2004
Posts: 117
|
 Posted: Thu Apr 04, 2013 10:41 pm Post subject: |
 |
|
Thank you, I got it sorted as desired! 
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. |
|
| Back to top |
|
 |
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
| Posted: Thu Apr 04, 2013 10:46 pm Post subject: |
|
|
| 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 |
|
|
oliv3r
n00b
Joined: 06 Jan 2013
Posts: 16
|
| Posted: Sun Apr 07, 2013 9:13 am Post subject: |
|
|
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!
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 |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Apr 07, 2013 9:49 am Post subject: |
|
|
| 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Apr 07, 2013 12:24 pm Post subject: |
|
|
| 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 |
|
|
oliv3r
n00b
Joined: 06 Jan 2013
Posts: 16
|
| Posted: Sun Apr 07, 2013 1:44 pm Post subject: |
|
|
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 |
|
|
oliv3r
n00b
Joined: 06 Jan 2013
Posts: 16
|
| Posted: Mon Apr 08, 2013 4:33 pm Post subject: |
|
|
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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Apr 09, 2013 7:50 am Post subject: |
|
|
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 |
|
|
oliv3r
n00b
Joined: 06 Jan 2013
Posts: 16
|
| Posted: Tue Apr 09, 2013 9:22 am Post subject: |
|
|
| 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 |
|
|
Fran
Guru
Joined: 29 Feb 2004
Posts: 530
Location: Coruña (Spain)
|
| Posted: Tue Apr 09, 2013 10:42 am Post subject: |
|
|
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 |
|
|
gringo
Advocate
Joined: 27 Apr 2003
Posts: 3793
|
| Posted: Tue Apr 09, 2013 11:50 am Post subject: |
|
|
| 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 |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Tue Apr 09, 2013 12:07 pm Post subject: |
|
|
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 |
|
|
Fran
Guru
Joined: 29 Feb 2004
Posts: 530
Location: Coruña (Spain)
|
| Posted: Tue Apr 09, 2013 12:41 pm Post subject: |
|
|
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 |
|
|
Fran
Guru
Joined: 29 Feb 2004
Posts: 530
Location: Coruña (Spain)
|
| Posted: Wed Apr 10, 2013 7:43 am Post subject: |
|
|
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 |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Wed Apr 10, 2013 8:12 am Post subject: |
|
|
| 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 |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Apr 10, 2013 12:01 pm Post subject: |
|
|
| The irony is that both the kernel firmware loader and eudev itself were created because udev broke it first... |
|
| Back to top |
|
|
expressionlibre
n00b
Joined: 30 May 2008
Posts: 12
Location: France
|
| Posted: Fri Apr 12, 2013 5:38 pm Post subject: Fail2ban doesn't like new predictable names |
|
|
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... 
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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 13, 2013 9:10 am Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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
| 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 |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Apr 13, 2013 9:48 am Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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 |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Apr 13, 2013 10:47 am Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 13, 2013 11:23 am Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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 ? |
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 |
|
|
wolfieh
n00b
Joined: 17 Nov 2009
Posts: 54
|
| Posted: Sat Apr 13, 2013 5:47 pm Post subject: |
|
|
| 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 |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21593
|
| Posted: Sat Apr 13, 2013 7:18 pm Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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 |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Apr 13, 2013 8:35 pm Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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 |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Apr 13, 2013 8:48 pm Post subject: Re: Fail2ban doesn't like new predictable names |
|
|
| 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 |
|
|
|
|
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
|
|
Portage & Programming
