| View previous topic :: View next topic |
| Author |
Message |
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
 Posted: Mon Apr 15, 2013 5:41 pm Post subject: change boot network interface activation order udev200 |
 |
|
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*
TIA |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Apr 16, 2013 11:13 am Post subject: |
|
|
dbishop ...
I have no way to test any of this but does the following provide something close to what your looking for:
/etc/rc.conf
| Code: | | rc_net_enp1s0_after="net_enp5s0" |
I'm assuming the current ordering is: enp1s0, enp4s0, enp5s0.
HTH & best ... khay |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Apr 17, 2013 9:44 am Post subject: |
|
|
bump ... as given the amount of discussion in the persistent naming thread it'd be good to know if this can be worked arround ... and also, I know sometimes that mail notification fails so you may not have been notififed of a reply.
best ... khay |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 17, 2013 10:50 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. |
It would be nice if you would explain why you need this since I really cannot imagine a reason for it.
The order of activation is probably undefined in openrc unless you define a dependency between the services. The "after" which khayyam suggested might work, but I am not sure that this will work for net services, since their "true" activation is postponed. However, if one of the services "needs" the other, it should work. Note, however, that this means that if enp5s0 is stopped then also enp1s0 is stopped - which seems to be logical since, if I understand you correctly, enp1s0 cannot be used properly without enp5s0 being active (whatever is the reason for this is...) |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Thu Apr 18, 2013 1:13 am Post subject: |
|
|
The OP may have a configuration mistake that is masked if the NICs come up in a particular order. For example, if two NICs both set a default route, and his preferred start order makes the viable route the prevailing default route, he would perceive the other order to be broken.
OP: please post the output of cat -n /etc/conf.d/net and any information you have about why you believe that order is necessary for proper operation. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu Apr 18, 2013 11:00 am Post subject: |
|
|
I don't know why he wants things ordered a certain way, and it makes no difference at least to me.
Either it can be done or it can't be.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Sun Apr 21, 2013 3:59 pm Post subject: |
|
|
I haven't tried | Code: | | rc_net_enp1s0_after="net_enp5s0" |
yet, but I will.
One question: Where did you find the details to write this in the first place? I have looked all over for something like this and came up empty.
I missed this entire thread because it appeared in two places after a moderator killed it first time through thinking I was asking about the loss of eth-whatever -- which I am not.
Since it seems necessary to remark on "why" I need to do this, I will:
First, this is a highly unusual application -- it involves a server that gets moved around to more networks than a travelling salesman's laptop. This particular machine has three interfaces that may or may not be used, never mind which cables get plugged in where -- each time it boots up it may very well be in a different network environment. Sometimes it needs to act as an NTP and DHCP server (among other things), sometimes not. Sometimes it needs to forward packets, sometimes not. And this is only some of the issues, but however this machine self-configures, it's all dependent on what comes up first.
Controlling the order in which interfaces come up is useful in allowing much finer control and in a much more orderly way. Many here, if not all, will simply be accustomed to plugging in physical cabling and then writing routing rules and such to deal with the environment. Some will have written complicated iptables rules to act as a DMZ/Choke firewall pair with port redirection and whatnot. Some may have even written custom routing tables rules. Yet others may have gone undertaken setting their rc.conf to remove strict networking rules.
Regarding
| Quote: | | The OP may have a configuration mistake that is masked if the NICs come up in a particular order. |
Just because you do not understand why I am doing something does not make my approach wrong. And besides, ordering things to work based on defaults rather than writing around them so defaults are irrelevant is not necessary "masking a problem". If you think that it is, go to all your conf files and uncomment all the defaults and set every option explicitly. And then make sure that every service you start can be started independently of every other,, so we can finally get rid of nuisances like "depend(){}" in runscripts.
In my case, there are probably many ways to do what I need to do. I have long since written several scripts and set service config's to do what I need done, and they all work -- at least until I got snookered by names that are supposed to have the exact opposite effect. If I could control the up-order, as I could before, all would be well. It would be amazingly ironic if I had to use udev rules to call these interfaces by other names to make it work. By the way, it is not lost on me that the new "predictable" names include automatically defined variants, such as those that include mac addresses as a way to stop defining names in udev rules that mapped interfaces to mac addresses.
With previous incarnations of udev, it was possible to simply name interfaces whatever I wanted to make things work. I suppose I could still do that too, but it seemed that this offended the orthodoxy of the new predictable naming scheme. So I was looking for the way to do this. It seems highly ironic that "unpredictable naming" allows me much finer control over networking than the "predictable naming idea". It seems that, as with everything relating to Red Hat fascism choice is giving way to uniformity and everyone who does something different must be an idiot.
Sincerely, thanks for all the help. BTW I have been using Gentoo for 10+years (after years with Slackware and Mandrake). Enlightenment is great, especially e17, and I like it all the more now since I do not depend on KDE or Gnome, both of which seem to be under some nefarious and subversive influences -- the latter more than the former though. I do not ask many questions or post very often because I usually figure out what I need to do without bothering others, often by reading existing posts and putting two-and-two together. I usually assist by adding to wiki pages when appropriate, though I do so under a different alias.
That's some insight on "why". Thank you all again. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sun Apr 21, 2013 4:32 pm Post subject: |
|
|
| dbishop wrote: | | One question: Where did you find the details to write this in the first place? I have looked all over for something like this and came up empty. |
dbishop ... in the very same file in which the variable is set, /etc/rc.conf. The logic (before, after, depend, etc) is also covered in handbook under initscripts.
best ... khay |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Sun Apr 21, 2013 5:00 pm Post subject: |
|
|
| dbishop wrote: | Regarding
| Quote: | | The OP may have a configuration mistake that is masked if the NICs come up in a particular order. |
Just because you do not understand why I am doing something does not make my approach wrong. And besides, ordering things to work based on defaults rather than writing around them so defaults are irrelevant is not necessary "masking a problem". If you think that it is, go to all your conf files and uncomment all the defaults and set every option explicitly. And then make sure that every service you start can be started independently of every other,, so we can finally get rid of nuisances like "depend(){}" in runscripts. |
Did you have an exceptionally bad day before you read my post? I offered one possible explanation for why you might need this and I specifically asked you to provide information that may help us understand your real problem. Ordering the NICs should have happened automatically if you had proper dependencies set up elsewhere on the specific services that require the NICs to be in a specific order. The lack of such dependencies may be a mistake. If you prefer to attack me, go ahead. None of us are under any obligation to help you. |
|
| Back to top |
|
|
dbishop
Tux's lil' helper
Joined: 08 Dec 2007
Posts: 107
|
| Posted: Sun Apr 21, 2013 10:40 pm Post subject: |
|
|
khay: Thank you for the help. I will read those. I had asked elsewhere about using rc.conf but was discouraged from doing so. I was also toying with the idea of using preup() in conf.d/net -- have used these hooks before to do some advanced routing some machines that had to route specific traffic to specific service providers based on UID. But I wasn't too sure that would work here too well.
Now on to the hornet's nest I inadvertently stirred up.
| Hu wrote: | | Did you have an exceptionally bad day before you read my post? I offered one possible explanation for why you might need this and I specifically asked you to provide information that may help us understand your real problem. Ordering the NICs should have happened automatically if you had proper dependencies set up elsewhere on the specific services that require the NICs to be in a specific order. The lack of such dependencies may be a mistake. If you prefer to attack me, go ahead. None of us are under any obligation to help you. |
Actually, I didn't attack anyone. Hu -- I regret that you feel that it I attacked you. I felt that there was an underlying assumption that I was doing something wrong, and I was addressing it. And besides, if controlling up-order to leverage default behaviours makes something work without writing lots of custom configs, then why isn't that a valid solution (philosophically speaking)?
At any rate, I am always grateful for help, and I gave my sincere thanks for all the replies. Twice.
Once again, thank you all for help. I know no one is obligated. |
|
| 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
|
|
Networking & Security
