| View previous topic :: View next topic |
| Author |
Message |
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
 Posted: Mon Apr 15, 2013 9:36 pm Post subject: Re: This is how they should have done it! |
 |
|
| khayyam wrote: | | 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 |
Unworking "binary only" music manager software? Looks like a fine candidate for spring treecleaning.  |
|
| Back to top |
|
 |
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Mon Apr 15, 2013 9:41 pm Post subject: |
|
|
| mv wrote: | | 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. |
I see that the blinding insight I had has struck more than once today. I'm glad to see that I am in the company of John Graham on this one. Let's see: the kernel interface isn't broken, but the systemd/udev situation is so fraught nowadays that Linus is contemplating pulling the udev function back into the kernel. Sure, the kernel isn't broken, but userspace is doing truly crazy things.
Remember that what I talked about tries to achieve maximal compatibility. The default basename for eth%d and wlan%d would continue to be eth%d and wlan%d; it would be a command-line parameter (or two) to go to something other than the default. Indeed, this would work great for what Samuli mentioned in that very forum thread you quoted: "My preference would have been to keep the old rule_generator but modify it to use net* namespace instead of eth* or wlan* or other kernel reserved..." Set the base name to "net" and there you go.
Maybe someone *should* ask Linus.
| mv wrote: | | This is the disadvantage of the unix philosophy "one tool one job" |
Well yes: we can turn that back into an advantage. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Mon Apr 15, 2013 9:48 pm Post subject: |
|
|
| miket wrote: | | Why do you want to impose your draconian solution on everyone--especially one that has to be done RIGHT NOW? |
Sorry, but you are giving me way too much credit. You will have to address the "thank you" -note to upstream udev developers who wrote the feature and enabled it by default as an migration path from the old rule_generator.
Plus you don't have to do anything "RIGHT NOW". Instead, you were provided with an news item explaining the new feature and linking you to relevant pages so you can choose what you do, and when you do it. |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Mon Apr 15, 2013 11:44 pm Post subject: change boot network interface activation order udev200 |
|
|
In a preemptive strike to avoid having moderators once again shunt my question to duplicate thread limbo:
I have thoroughly read these posts many times over the last few weeks:
https://forums.gentoo.org/viewtopic-p-7278678.html
http://www.gentoo.org/doc/en/udev-guide.xml
https://forums.gentoo.org/viewtopic-t-955646.html
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
My original question was
| Quote: | | I have a machine with three nics. The new network interface names, enp1s0, enp4s0, enp5s0, booting now activates these in an order that doesn't work for me -- I need enp1s0 to come up last instead of first. I used to manage this easily with eth* renaming via 70-persistent-net.rules but I am not sure how to do this with the latest udev. I suspect this is simple, but I am just not seeing it or finding posted elsewhere. *sigh -- I guess the myriad udev changes have finally exhausted me* |
This was summarily moved to "duplicate threads" despite this being a completely different question: how to control the order in which interfaces are brought up using the new predictable names not using some udev patch to rename them. If I wanted to do that, I would have kept my hack script that runs at sysint that keeps them as they were -- ironically, the essence of this patch was provided by ssuominen:
| Code: | #!/sbin/runscript
# Run this before 70-persistent-net.rules to allow swapping to eth*
#
# OpenRC, example: rc-update add $script_name sysinit
#
# Then you can use rules like, example:
#
# SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:85", NAME="eth0"
# SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="bc:ae:c5:59:5a:fd", NAME="eth1"
#
# You need to have sys-apps/iproute2 installed.
description="Renames ethX to ethXtmp to avoid udev rename conflicts"
depend() {
before dev
need sysfs
need modules
}
start() {
local i
for i in /sys/class/net/eth* ; do
[ "$i" = "/sys/class/net/eth*" ] && continue
ip link set dev ${i##*/} name ${i##*/}tmp 2>/dev/null
done
}
|
In a highly ironic twist, I simply asked how to change boot order instead of renaming interfaces using udev rule files. After all, I thought that all this udev nonsense was supposed to keep this from being necessary? So now I get enp2s0 derived from PCI bus numbers (as if those were sacrosanct somehow) only to be told to write jacked up rules renaming them "my_first_net_0"? What's next? Pictures of park benches or houses like Windows? How does this promote using predictable network names???
I was thinking the answer would be in something like RC_NEED=... (or some such) put some where that provoked the Gentoo start scripts to call the new names in a specific order.
Now as it happens, ssuominen wrote at the bottom the linked post to use the MAC-based names, which is easy enough to do:
| Quote: | PostPosted: Thu Apr 04, 2013 2:15 pm Post subject: Report this post Reply with quote
| 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
Ideal solution will be the second for me.
Given his hw conf and convenience, one should be able to map ID_NET_NAME_MAC [enx4c240a1935a1] to net0, or even ID_NET_NAME_PATH [enp0s25] if he wants to rely on physical/geographical location of hw connector (laptop?), or again use another identifier from ones provided by udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null.
My question is, how can I write a rule to accomplish the above?
|
For using MAC based interface names, you can look at existing posts with examples like https://forums.gentoo.org/viewtopic-t-955968-highlight-.html (Second reply) |
But of course this doesn't provide a guaranteeing a specific up-script ordering... (which is what I trying to get)[/i]
SOOOO, after re-re-re-re-reading all those posts, all I can conclude is that my udev171 rules that mapped my mac addresses to eth* were really the way to go all along. At least, by sending my last forum post to the junk heap seemed to suggest...
If the answer is truly to map mac addresses to made up names, then it appears at this point that the new udev rules are just one big circular nightmare right back to where we started. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Apr 16, 2013 12:07 am Post subject: |
|
|
| ssuominen wrote: | Sorry, but you are giving me way too much credit. You will have to address the "thank you" -note to upstream udev developers who wrote the feature and enabled it by default as an migration path from the old rule_generator.
|
| Code: | ls /usr/portage -lR | grep "\.patch" | wc -l
14543
|
So we should filebug 14543 bugs to have all devs fix that ? Because it seems they are evils creatures, altering upstream code.
So don't be that shy, you can accept a "thank you" as it seems credits are given to whom it should... |
|
| Back to top |
|
|
kurly
Apprentice
Joined: 02 Apr 2012
Posts: 260
|
| Posted: Tue Apr 16, 2013 1:23 am Post subject: |
|
|
Introducing this as the default was/is a gigantic mistake. I thought the Gentoo developers would insulate us from upstream mistakes, but it seems that we instead accept it as-is. Defending the damage instead of fixing it is almost worse than the initial mistake.
The fact that there are so many duplicate threads should serve as notice that this is a bigger problem than is being admitted, rather than shuffled off to "Duplicate Threads" with no acknowledgement. Ignoring the evidence of the failure does not make it go away. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Tue Apr 16, 2013 1:43 am Post subject: Re: change boot network interface activation order udev200 |
|
|
| dbishop wrote: | | I have a machine with three nics. The new network interface names, enp1s0, enp4s0, enp5s0, booting now activates these in an order that doesn't work for me -- I need enp1s0 to come up last instead of first. I used to manage this easily with eth* renaming via 70-persistent-net.rules but I am not sure how to do this with the latest udev. I suspect this is simple, but I am just not seeing it or finding posted elsewhere. *sigh -- I guess the myriad udev changes have finally exhausted me* |
You need them up in specific order why? In the past people used to do that to keep consistent names which isn't required anymore with the new names if everything goes as it should.
So all you have to do is use enp1s0 instead of enp5s0 last in your usecase?
You could use /etc/conf.d/udev to set rc_coldplug="NO" and load your own interface drivers / modules in order too, but I don't think this is what you want.
Last edited by SamuliSuominen on Tue Apr 16, 2013 4:22 am; edited 2 times in total |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Tue Apr 16, 2013 1:47 am Post subject: |
|
|
| kurly wrote: | Introducing this as the default was/is a gigantic mistake. I thought the Gentoo developers would insulate us from upstream mistakes, but it seems that we instead accept it as-is. Defending the damage instead of fixing it is almost worse than the initial mistake.
The fact that there are so many duplicate threads should serve as notice that this is a bigger problem than is being admitted, rather than shuffled off to "Duplicate Threads" with no acknowledgement. Ignoring the evidence of the failure does not make it go away. |
On the contrary, I'm on the forums to catch bugs that would otherwise go unnoticed and hope to help some users while at it. I've also found forums to be the one big place where people come and
moan when they are incompetent (and shouldn't be at the admin jobs they currently are in). It's often the very same people who ignore all output from Portage and refuse to read any
documentation, and refuse anykind of change because change is bad.
As in, I'm not defending anything, I'm here helping people and unfortunately stumbling on couple of trolls on the way of doing so.
I can simply stop listening this thread and help others on other threads and wait for actual bugs to be filed, where you have to provide enough data for the bug to get processed at all to get past bug wranglers.
In fact, I believe I'll do that now. Thanks, it has been nice wetting out some of these issues with most of you. It's always the couple who drag us rest in the mud. I still don't mind if anyone privately message me about the issue. |
|
| Back to top |
|
|
kurly
Apprentice
Joined: 02 Apr 2012
Posts: 260
|
| Posted: Tue Apr 16, 2013 2:49 am Post subject: |
|
|
I apologize for the tone of my post and did not mean to offend -- not been in the best of moods today.
I stand by my comment that making this feature the default was a mistake (in my opinion, of course). I definitely appreciate that you've been a constant presence in the forums trying to help, but I can't help but wonder if it would've been a better idea to keep this feature as optional for those who do need it as opposed to making it the default. |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Tue Apr 16, 2013 4:11 am Post subject: |
|
|
Regarding my 3-NIC situation, let me be clear. I have been somewhat accepting of the reality of the new interface names because they were supposed to be easier to deal with in the long run -- peculiar and awkward, yes, but predictable and more manageable so sayeth the proponents. So some of my issue is practical, but some is philosophical.
First, the practical matter is that what is now known as "enp1s0" is a mediocre-performance NIC that I used make realizing a VPN easier. The other two cards are the DMZ interface and the LAN interface on a choke firewall box. These two cards are high performance GigE cards. Of course I had to fix all my firewall rules, and a ton of conf files to cope with all the new "predictable" names.
In the bad 'ol wild-west days of eth* and 70-blah.rules, I simply mapped the mac's to eth0, eth1, and eth2 to my liking, no fuss, no muss. enp1s0 was formerly eth2, so I could control when the VPN interface came up. Perhaps by pure serendipity, the VPN -- added after-the-fact to the choke firewall box, it worked without any other major changes. Frankly I didn't give it much thought.
True confession: I had been cheating with udev-197 by using the sysinit script and 70---rules to keep things as eth*. So when I saw the notes for udev200, I decided to just take the plunge and force myself to use the new interface nomenclature with all my boxes (I have an even 10 gentoo machines running, not counting laptops). It all worked fine until the box with three interfaces. Just letting them come up in their "natural order" the firewall rules and VPN break. I haven't looked into why -- I just shut down the enp1s0 interface (doesn't exactly roll off the tongue..) and everything started working. I renamed everything with the cheat script as eth*, like it had been and everything started working again. So the easy solution seemed obvious: Everything works when the physical interface enp1s2/eth2 starts last, nothing works otherwise, so: start it last. From a philosophical point of view, if I can't do this simple thing, then who really cares about persistent names? If I still have to rename them, it makes a mockery of it all.
So I am faced with three choices, as I see it:
1. Spend some amount of time screwing with my iptables rules (not a small table), routing tables, the VPN rules and perhaps the public firewall/forwarder to allow enp1s0 any time it feels like it;
2. Rename the interfaces back to eth0,1,2 and scrap the whole pci-bus-numbered udev nonsense;
3. Figure out how to get the Gentoo network framework to let me specify interface start-up order and thus justify all the pain and suffering.
| Quote: | | You need them up in specific order why? In the past people used to do that to keep consistent names which isn't required anymore with the new names if everything goes as it should. |
Again in some not-so-small irony, Linux "choice" seems to be giving way to Windows-style, "Don't think!!! If it isn't working out of the box it's because you as the user are doing something we in Redmond do not approve of; change your rotten ways."
To answer the question, in my case it used to work and now it doesn't. It has to do with the way the default routes are getting assigned if the more-specific VPN interface is up before the less-specific general choke interface. Since I know that invoking a specific start-up order fixes everything perfectly well, I want to choose this option. But it seems in order to dothat I need to write a lot of networking workarounds now or resort to the udev171 method.
As I have read all these threads several times (and had even masked >udev171 until just recently in silent protest) it is clear to me that something like 70-persistent-net.rules is really the only way. It seems highly ironic that these new names were an answer to the "mayhem" of kernel-based naming, and that the whole new method of using PCI slot numbers is so thin that in my simple little case of wanting to specify a specific if-up order, I have to resort to patching code, sysinit work-around scripts and mac-to-eth* names to make it work.
I suppose being asked incredulously "why?" is just icing on the cake. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Apr 16, 2013 6:17 am Post subject: |
|
|
| dbishop wrote: | First, the practical matter is that what is now known as "enp1s0" is a mediocre-performance NIC that I used make realizing a VPN easier. The other two cards are the DMZ interface and the LAN interface on a choke firewall box. These two cards are high performance GigE cards. Of course I had to fix all my firewall rules, and a ton of conf files to cope with all the new "predictable" names.
..I simply mapped the mac's to eth0, eth1, and eth2 to my liking, no fuss, no muss. enp1s0 was formerly eth2, so I could control when the VPN interface came up.
Everything works when the physical interface enp1s2/eth2 starts last, nothing works otherwise, so: start it last. |
(I assume that last mention is meant to be: enp1s0)
Given that the names are: enp1s0, enp4s0, enp5s0 they're all on the same bus, right? Just wondering if you can't simply swap the cards, so that current enp1s0 is in slot 5, with current 4 in 1 and 5 in 4 or vice-versa as needed. Or are the other two built-in to the mainboard?
| Quote: | | From a philosophical point of view, if I can't do this simple thing, then who really cares about persistent names? If I still have to rename them, it makes a mockery of it all. |
Yup. That's the problem with idiot-box approaches that add more layers instead of clearly analysing the problem and providing a simple, configurable solution (because that's "traditional" = "bad".)
| Quote: | | As I have read all these threads several times (and had even masked >udev171 until just recently in silent protest) it is clear to me that something like 70-persistent-net.rules is really the only way. |
I think if, when the issue first arose, the solution had been simply "if you need renaming, edit this file, and you cannot rename to a kernel name" (you'd think they'd be aware of the race-condition, since these were the people who claim expertise over the whole "dynamic" userspace domain) then people with multi-nic setups that needed a specific setup would have had it from the beginning, with no changes now. And everyone else would never have even had to be involved, nor gone through any pain.
As it is, given the amount of end-user systems setup with multiple ethN, and the attendant legacy-configuration as you've outlined, I think the best solution would be to add a configuration parameter to kernel bootline, with a filename of simple: ifname XX:XX:XX.. MAC address mappings (and ignore lines starting with '#'). The minimal kernel-logic required would be a compile-time option, and would enable 'renaming' or rather 'reservation' within the kernel namespace.
| Quote: | It seems highly ironic that these new names were an answer to the "mayhem" of kernel-based naming, and that the whole new method of using PCI slot numbers is so thin that in my simple little case of wanting to specify a specific if-up order, I have to resort to patching code, sysinit work-around scripts and mac-to-eth* names to make it work.
I suppose being asked incredulously "why?" is just icing on the cake. |
To be a good coder you need to learn humility: by definition you will not be present when the software is run. The only person who truly knows the situation is the end-user. So it makes no sense to second-guess what they might do (that's why Unix is built out of pieces you put together yourself. Everyone loves keeping the pieces when it comes to lego; you're meant to break it. Not sure why that's so bad in software.;) Instead your job is to provide transparent access to all the pieces, and keep a clean conceptual separation between the tools you do provide. Since they only do one thing, and do it well, they are easy to understand, and easy to plug together, as well as being easy to code and efficient.
Younger developers don't get that. They haven't learnt the humility that comes with making the same mistakes over years, until you finally see the light and submit to keeping your code both simple and stupid. (Nor do they work in software houses and corporate IT depts exclusively any more, so they burst onto the stage raw out of university, where they used to get years of experience before anyone took them seriously.) Since then it is easy to write, easy to understand and maintain, easy to port, and much more efficient over the longer-term.
Firstly it's much easier to change the algorithms and data structures, which is where 80% of optimisation gains come from, certainly the ones that most developers are capable of adding, and indeed the optimisations that open up the door to other ones where they're needed, and they're not usually.
N is usually small, the code you obsessed over doesn't get run enough to be a bottleneck; even before you optimise it, 60% of its time is in io, and 15% is spent sleeping, and after all that, it only gets run once a month and takes 45 seconds.
Secondly code that uses basic libraries in a standard portable fashion, tends to run faster over time, as those standard basic libraries are exactly the ones that the vendors spend ages optimising either directly or for. It's what Kernighan calls "programming to the mainstream."
But really, the main point is the ease of maintenance and reworking. The other thing these guys should bear in mind is this:
| Brian Kernighan wrote: | | Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it? |
These things used to be taught by osmosis from reading code, since there was only good C from Unix to learn from. Nowadays there's an awful lot more guff, mostly from the corporate IT sector, and the god-awful traditions they've inculcated in a whole generation via their arm-twisting of academia. Consider this, if you think I'm talking rubbish:
| Kernighan & Plauger wrote: | Good Programming is not learned from generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient and reliable, by the application of common sense and good programming practices.
Careful study and imitation of good programs leads to better writing. |
That's from the cover of "Software Tools" (1976). If you haven't read it, you have a treat in store when you do. (Just don't do regexen the way they do: read Aho & Ullman (1977) or Aho, Sethi & Ullman (1986) for that, to learn the NFA approach.) I recommend "The Awk Programming Language" (Aho, Kernighan & Weinberger 1988) if you're new to coding, and even if you're not, and "The Unix Programming Environment" (Kernighan & Pike, 1984) for anyone wanting to be a programmer. (It's required reading, well more expected as a given, in our team.)
Regards,
steveL.
For others reading: if you think you're above it, and this is all fusty tradition, you're an amateur, afaic, and you should get your head out of your ass. Have a nice day.
_________________
| creaker wrote: | | systemd. It is a really ass pain |
update - "a most excellent portage wrapper"
#friendly-coders -- We're still here for you™ ;) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Apr 16, 2013 10:05 am Post subject: |
|
|
| ssuominen wrote: | | On the contrary, I'm on the forums to catch bugs that would otherwise go unnoticed and hope to help some users while at it. |
ssuominen ... and so are others, at least many, and to varying degrees, and so the following collective strawman serves no purpose other than to tar anyone who may have legitimate criticisms with the same brush as the "moaners", "incompetents", etc.
| ssuominen wrote: | | I've also found forums to be the one big place where people come and moan when they are incompetent (and shouldn't be at the admin jobs they currently are in). It's often the very same people who ignore all output from Portage and refuse to read any documentation, and refuse any kind of change because change is bad. |
There is no such group of "people", you are a creating a typical strawman argument with which you can dismiss any criticism as the work of this non-existent bugaboo. Your statement contains no facts, unless you happen to be privy to information on specific peoples employment status, etc, etc. Its a wide brush, and so the paint is easy to apply, me for instance, I'd have to be some moaning troll to be replying to this at all?
Personally I find your comment (and note, I'm responding to *you* not some trumped up strawman) to be unbelievably arrogant, you want to have it that, any evidence to the contrary, the problem is with others, and that the reason for this is that these people are whiners, incompetents, refuse to read documentation, and hate change. Long live the stereotype!
best ... khay |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Tue Apr 16, 2013 10:23 am Post subject: |
|
|
@Ant P.: Your post of April 15 is still making me laugh a day later! Hilarious, mate. 
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Tue Apr 16, 2013 10:35 am Post subject: |
|
|
| dbishop wrote: | Since I know that invoking a specific start-up order fixes everything perfectly well, I want to choose this option.
I suppose being asked incredulously "why?" is just icing on the cake. |
I don't want to annoy you futher, but it seems you have been working around a problem with the device naming it was never designed for. |
|
| Back to top |
|
|
cwr
Veteran
Joined: 17 Dec 2005
Posts: 1969
|
| Posted: Tue Apr 16, 2013 11:02 am Post subject: |
|
|
| ssuominen wrote: | | dbishop wrote: | Since I know that invoking a specific start-up order fixes everything perfectly well, I want to choose this option.
I suppose being asked incredulously "why?" is just icing on the cake. |
I don't want to annoy you futher, but it seems you have been working around a problem with the device naming it was never designed for. |
Indeed, he is clearly the wrong sort of person using his computer for the wrong sort of things.
I'm glad you made him aware of his wrong attitude - perhaps he will get the message and reform.
What form do you think his reformation should take?
Will |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Tue Apr 16, 2013 11:20 am Post subject: |
|
|
| cwr wrote: | | ssuominen wrote: | | dbishop wrote: | Since I know that invoking a specific start-up order fixes everything perfectly well, I want to choose this option.
I suppose being asked incredulously "why?" is just icing on the cake. |
I don't want to annoy you futher, but it seems you have been working around a problem with the device naming it was never designed for. |
Indeed, he is clearly the wrong sort of person using his computer for the wrong sort of things.
I'm glad you made him aware of his wrong attitude - perhaps he will get the message and reform.
What form do you think his reformation should take?
Will |
Stop the nonsense and get back to the topic.
Take the time to read his post again. He explained himself he is *working around* a problem, possibly with routing, or drivers/kernel by bringing up the interfaces in certain order. I use such quick tricks myself too but I'm aware they are bound to break at some point if not fixed properly.
I'm much more intrested in hearing something useful, like his dmesg output, iptables output, more detailed information about the cards, kernel, drivers, so we can figure the real solution out together and put some distance between the two completely different issues. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Tue Apr 16, 2013 11:38 am Post subject: |
|
|
| kurly wrote: | I apologize for the tone of my post and did not mean to offend -- not been in the best of moods today.
I stand by my comment that making this feature the default was a mistake (in my opinion, of course). I definitely appreciate that you've been a constant presence in the forums trying to help, but I can't help but wonder if it would've been a better idea to keep this feature as optional for those who do need it as opposed to making it the default. |
No problem. And to be fair, the reply certainly wasn't only for you but for the last couple of aggressive posts I'd rather not start listing to avoid escalating things futher. I didn't mean any disrespect, but you have to admit people have gone too far with some of their replies.
I can appericiate your opinion but if nobody has anything tangable that would justify disabling the upstream default, I'm as stuck as I'm now between two entirely different opinions.
The people who wanted it enabled by default, including upstream, have listed number of reasons it should stay like it, where as the other people have only provided the usecase of single NIC systems
(for which the default works fine too, and as such doesn't really qualify). And obviously reasons like google-musicmanager can't count for system involved packages, it sounds more like an poor
excuse -- in my opinion, it's crazy to let some binary-only blob determine how the interfaces should be named. That binary-only blob is in package.mask as of today.
Last edited by SamuliSuominen on Tue Apr 16, 2013 12:32 pm; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Apr 16, 2013 12:15 pm Post subject: |
|
|
| miket wrote: | | The default basename for eth%d and wlan%d would continue to be eth%d and wlan%d; it would be a command-line parameter (or two) to go to something other than the default. |
This might work, although I would not like to see the necessity to pass a command line parameter (which are limited in total length) for some "normal" behaviour. Perhaps a configurable kernel option would be better, at least to define the default if no command line parameter is passed.
| Quote: | | Maybe someone *should* ask Linus. |
You would have to convince Linus, probably several other kernel developers, Sievers and Poettering. Good luck |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Apr 16, 2013 12:38 pm Post subject: |
|
|
| ssuominen wrote: | | The people who wanted it enabled by default, including upstream, have listed number of reasons it should stay like it, where as the other people have only provided the usecase of single NIC systems |
Because you don't want see that most users use a single NIC and abstracting the network name may be 0 effect for a distro that hide everything to his user using some network GUI to handle it and an installer that do the work for him.
But, this is gentoo, not redhat. Lowering its impact won't make it gone away, can't you see what this is doing to many users that USE the distro already and you can't see what this will do to people that haven't install gentoo yet.
Those people try to install the distro, not reading zillions documentations to see why/when/who has done this or that for this or that reason. So the KISS principle must remain apply to the installation.
It's now easy to see the both case when a user with few knowledge will try that :
- Enable : people just couldn't understand what they are doing, reading a doc that aim at eth0 while their interface is not guessable by anyone except them.
100% failure.
- Disable: people use eth0, and some may fail because of the race/multi-nic... Those ones could get help on forum to fix it.
hard to say, but certainly bellow 100% as you can see many of us with poor knowledge had success at installing it with only the handbook.
Upstream is aware of the problem, and enable it because of their installer doing the work. User pickup choice 1 or 2 and keep going, who cares if the choice 1 is eno1 or esnp3...
So this default isn't good for us, upstream clearly state it's a problem
| Quote: | Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.
|
But balance by their usage, they choose to enable it per default. That makes sense.
You just don't that, you pickup the same choice as upstream without balance that choice for gentoo, and stick with upstream for no reason except upstream enable it.
If you have an installer the eth* naming is worth 0 in the balance, but without one (like us), that eth* naming is worth a 100.
So instead of answering us why upstream enable it, answer why you (the udev team, not aiming at you only ssuominen) enable it for gentoo. How did you make the balance to see the balance goes toward enable it ?
Because for me, you just put eth* naming in your balance with the same value as upstream see it: 0 value, making your calculation wrong. |
|
| Back to top |
|
|
py-ro
Veteran
Joined: 24 Sep 2002
Posts: 1734
Location: Velbert
|
| Posted: Tue Apr 16, 2013 1:00 pm Post subject: |
|
|
This would only be true, if the documentation won't be updated to reflect the change (i agree that this is highly needed).
I see the Gentoo Documentation as the same as installers on other distributions and the same rules should apply.
After the documentation is updated, i see now real change for new users.
Bye
Py |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Tue Apr 16, 2013 1:18 pm Post subject: |
|
|
| krinn wrote: | But, this is gentoo, not redhat. Lowering its impact won't make it gone away, can't you see what this is doing to many users that USE the distro already and you can't see what this will do to people that haven't install gentoo yet.
Those people try to install the distro, not reading zillions documentations to see why/when/who has done this or that for this or that reason. So the KISS principle must remain apply to the installation. |
Color as much as Sievers and Poettering want about how it is "correct", this is a SERIOUSLY bad, destabilizing thing they are bringing into Linux. I'd almost go so far as to label it an act of terrorism. Not only do packages and firewall rules and various scripts contain interface names, but the very init system requires them. If there is an insistence on people having to use this stupid, stupid idea of those crazy enpXXsYY names, people are for years going to find themselves stuck with machines which require massive reconfiguration every time they might move a NIC around--or if they do something basic like dd their system image to another machine.
So, we need to stop this idea in its tracks! This is not an issue of figuring out whether people are making the conversion the right way, it is an issue of stopping them from going down that wrong path. The insistence that the names in the enpXXsYY pattern are "predictable" seems like an Orwellian redefinition of the word "predictable".
Names like net0 or lan0 are all right by me; the enp%ds%d names are not. Better still is leaving it possible to keep the names eth0 and wlan0. That's why I proposed fixing it so that the kernel can be set to use a different naming pattern so as to avoid race conditions.
| mv wrote: | | miket wrote: | | The default basename for eth%d and wlan%d would continue to be eth%d and wlan%d; it would be a command-line parameter (or two) to go to something other than the default. |
This might work, although I would not like to see the necessity to pass a command line parameter (which are limited in total length) for some "normal" behaviour. Perhaps a configurable kernel option would be better, at least to define the default if no command line parameter is passed. |
I'd been thinking about the very same thing and had come to that conclusion. It is in line with many of the configurable options already in the kernel. The one advantage to setting that on the command line is that udev could probe that without having to do any particular magic to find out what the kernel's current naming pattern is. (I haven't looked at the actual code in udev: maybe udev doesn't even need the hint.)
I'd recommend that everyone stay away from the enpXXsYY names and either go with names like net0 or wait until everything gets straightened out.
| mv wrote: | | You would have to convince Linus, probably several other kernel developers, Sievers and Poettering. Good luck :) |
Poettering, at least, is not a kernel developer. Thank God. |
|
| Back to top |
|
|
py-ro
Veteran
Joined: 24 Sep 2002
Posts: 1734
Location: Velbert
|
| Posted: Tue Apr 16, 2013 1:33 pm Post subject: |
|
|
I think you misunderstood something, Kernelname will remain ethX and wlanX.
The change is in udev, if you don't want this, don't use ist.
And even on single Nic Systems this Names are better then the scheme till now.
Just one simple Scenario we got everyday here:
System broke down, if you replace a mainboard (or a nic) you must allready alter the persistent-net-rules, to get network working again.
With the new names there is no need too, given you use the same mainboard (or slot).
If you don't like the new names, you got plenty of possibilities to disable them:
The commandline argument.
Replace the rule file or link a file with same name to /dev/null
To close down here, i know no good Firewall software where you can't configure the used interfaces and if you write your own Scripts without using variables for the interface names, well it is your own fault.
Bye
Py |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Tue Apr 16, 2013 1:48 pm Post subject: |
|
|
ssuominen suggested that we get back to the original issue: I am all for that!
Question: How can I change the order in which Gentoo activates interfaces so that, me being the owner of the equipment, can have that equipment suit my purposes?
If it is impossible, please just say so. if it violates some primary directive by the software prophets or there will be a rift in the fabric of the developer universe, then say so. I will shut up and spend the next couple of days writing code so that the ideals envisioned by this nonsense can be fully realized.
<<ssuominen, et al: what follows is a bit of a rant. It is not meant to be personal. I think it's a perspective you should be aware of, but if you can simply answer the question above, that would be very good too.>>
If this is the case, that systems are to become unalterable or fixed-purpose by developers, then that tinker-toy abomination with the big kiddie-style push-button interface called Gnome 3 has a very bright future, right next to Windows 8. Who needs Cairo Dock and themes, anyway??? I'll tell you: -l users do, that's who! *gag*
Alas, I do believe we have surfaces all the issues:
1) Device renaming should never be used, because there is no limit on how much patch-code can be written to make things work without changing them;
2) The new persistent names should always be used as-is in order to fully comply with the "higher purpose at stake" and because "the really smart people say so"
3) "Real experts" should always take the far more complicated and code intensive approaches to all problems and always take the more difficult road to do anything -- the "easy way" is demonstrates a weakness of character;
4) Listing kernel drivers, dmesg outputs, routing tables, dumping iptables rules, the writing all sorts of shell scripts is far superior and better all-around solution than simply changing interface-up order and let the existing code simply behave. I have always been taught that complicated, code intensive and time consuming solutions are best, especially when the result can be used as prima facie evidence that the coders-prophets that dreamed these dreams have been right all along: more complicated is simpler.
5) Boot sequences that cannot be implemented in a fully randomized sequence are implicitly flawed. Bringing up network interfaces according to a proscribed manner will be the beginning of the rot. If we allow such a thing, then we will have to start bringing up the kernel is a specific order. Think of the mayhem that would usher in. After all, that's what the kernel boot sequence randomizer is for. Uniformity is key. No one should ever need to step out of line.
6) We should all be grateful to finally be rid of absurd names like eth0 and wlan0. What a dumb idea they were.
7) Always accept as incontrovertibly true whatever the first link in your Google search espouses. For those lacking faith, double check with whatever Wikipedia says. Both are popularity-derived and must be right according to the tenets of democracy. Mobs rule. (okay this one is off-topic a bit, couldn't resist)
Now, before you get the wrong impression, I am really genuinely indebted to the people who invest their time in making Gentoo and other OSS work. Their dedication is to be applauded and their work is overall exceptional. What I am really railing against is the Microsoftian/Applesque dumbing-down that is happening. We who use these software systems do so because we are all grown up and intelligent and thoughtful and responsible. Were I a blithering idiot that only wanted to type up studies for government grant programs or assault innocent clients with yet-more slide-based presentations (see Tufte) or use spreadsheets to prove Keynes the Moron was right, well, I'd use Microsoft products -- my networking woes would be over simply by choosing between the park bench or the house and seeing if a big fat red "X" showed up indicating that I was in violation of the EULA. Or, aternatively, if all I wanted to do was take a lot pictures of myself and live as the Kardashians do, letting life wash over me, I'd get an Apple iWhatever. See? Choice.
Look, doing something the simple way that works reliably is not a "work-around", at least not in the pejorative sense. It's just a "valid working solution". When I suggested I had been using a work-around, it was tongue-in-cheek, really. Simply said, bringing up interfaces in a specific order causes everything else to be brought up in a specific order too. That is not a work around, unless you are saying that the original coder s blew it. And it had been working reliably my way for years. Ironically I kept it working using code inspired by ssuominen anyway. Hilarious.
@steveL: | Quote: | | Just wondering if you can't simply swap the cards, so that current enp1s0 is in slot 5, with current 4 in 1 and 5 in 4 or vice-versa as needed. |
Excellent question that points out the hubris of developers that think they have encountered every configuration. As it happens this particular box is a 1U server. Two interfaces are indeed built on the main board, and one is a PCIe expansion card. It's a 1U server so the card can only go in one slot because of the right-angle riser card. And you were correct, as evidence of my own fallibuility, I mistypes -- it is enp1s0. Thank you for a thoughtful reply, it was a good read. Seriously.
I myself and primarily a hardware designer. I do linear systems like RF, microwave and optical networking signal processing. I do not have the luxury of making systems more complex than they need to be, nor do I have the luxury of layering on fix after fix trying to metamorphose a bad idea into a good by increasing the complications and blaming customers. And I have to deal with the day in and day out, so it is not as if I am without sympathy when dealing with customers who are snookered by my designs and their flaws or shortcomings to an application. I guess this is the true legacy of Microsoft: Nothing ever needs to work right; keep eliminating choice so that everyone is straight-jacketed into a specific use case. Make sure that variance is either ridiculed as short-cutting, claim the product is being used in a way it's not supposed to, or make it illegal by paying off lawmakers. At least the last part hasn't come to Linux yet.
Maybe it's time to switch to Funtoo. From the distro's wiki: | Quote: | | Funtoo is a true source-based operating system that gives you the freedom to learn, change, and make it better. |
And it's Daniel Robbins. So I don't think they'll be much in the way of "We've thought of everything, if it's not working like you want, change your ways or get lost." |
|
| Back to top |
|
|
py-ro
Veteran
Joined: 24 Sep 2002
Posts: 1734
Location: Velbert
|
| Posted: Tue Apr 16, 2013 2:04 pm Post subject: |
|
|
| dbishop wrote: |
Question: How can I change the order in which Gentoo activates interfaces so that, me being the owner of the equipment, can have that equipment suit my purposes?
|
Sorry, but can't you just define the order/dependencies in /etc/rc.conf? |
|
| Back to top |
|
|
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
| Posted: Tue Apr 16, 2013 2:08 pm Post subject: |
|
|
| py-ro wrote: | | I think you misunderstood something |
Pardon me, but you've not quite caught onto the whole issue.
| py-ro wrote: | Kernelname will remain ethX and wlanX.
The change is in udev, if you don't want this, don't use ist. |
I wish I could just not use udev in its confused this state, but we're stuck with it. It is very hard to get away from if it you run almost any kind of graphical system I'd want to use with the features I'd want to use.
| py-ro wrote: | | And even on single Nic Systems this Names are better then the scheme till now. |
A naming scheme that reflects the use of an interface, such as lan0 or wan0, is quite all right and makes things more clear for things like setting up firewall rules. We didn't need the fancy new version of udev to be able to use this pattern.
This new pattern of enpXXsYY is perverse. It is a VERY BAD IDEA to use in any system where the init system and firewall rules have to have manually entered interface names in them.
| py-ro wrote: | Just one simple Scenario we got everyday here:
System broke down, if you replace a mainboard (or a nic) you must allready alter the persistent-net-rules, to get network working again. |
Yes of course that's the case. With what I recommend, you'd have to change things in only one place. If you're using the enpXXsYY names, you'd still need to make the change in the udev rules and also possibly in all those other places.
Let me point to an analogous situation. If you move an image to another machine, you might need to put it on a different set of mount points. To do that, you edit fstab and you're done. The system will boot up and work--you don't have to go around and change a bunch of pathnames in all kinds of random places.
| py-ro wrote: | | With the new names there is no need too, given you use the same mainboard (or slot). |
But if you change either one in the process, woe to you. I've had to do that a number of times, and each time rejoiced that I was using Linux that made it so easily possible. Let's not take that away!
| py-ro wrote: | If you don't like the new names, you got plenty of possibilities to disable them:
The commandline argument.
Replace the rule file or link a file with same name to /dev/null |
Disabliing the udev naming means that you're stuck with the kernel's enumeration, which in a multi-NIC setup might give you problems.
| py-ro wrote: | | To close down here, i know no good Firewall software where you can't configure the used interfaces and if you write your own Scripts without using variables for the interface names, well it is your own fault. |
I'll agree that firewall scripts should have variable names. Why should you *have* to edit those files every time? Also, there is no good analogous way to state a variable name for stating the interface name in the name of an init script.
| Code: | | /etc/init.d/net.whatDoYouCallMeToday |
|
|
| 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
