Interface start-up ordering sequence, multiple passes?

[Pekka Savola]

Hi,

When designing an IPv6 extension to initscripts, we came across this one 
particularly knotty problem.

There seem to be no way to select the order in which the interfaces would 
be brought up by e.g. "network start", except by naming hacks.  (There are 
also this, nowadays smaller, problem of on-demand dial-up interfaces..)

There seems to be no facility to run a script "in the second pass" i.e., 
after all the interfaces have been brought up.

Both of these facilities would seem to be useful, espcially being able to 
say "run these commands after interface X has been brought up".

Have I missed something, or is this impossible at the moment (without
gluing more stuff in init.d/network)?  Would such mechanisms be useful in
other contexts as well?

(This could be achieved, it seems, at least by using an '/sbin/ifup xxx
2ndpass' argument, and only specified commands would be run when doing the
second pass.)

Thoughts, ideas, comments?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

[Jim Wildman]

Why not add it to ifup-local?  It is not created by default, but it is
called from ifup-post.

On Thu, 11 Sep 2003, Pekka Savola wrote:

>  Hi,
>  
>  When designing an IPv6 extension to initscripts, we came across this one 
>  particularly knotty problem.
>  
>  There seem to be no way to select the order in which the interfaces would 
>  be brought up by e.g. "network start", except by naming hacks.  (There are 
>  also this, nowadays smaller, problem of on-demand dial-up interfaces..)
>  
>  There seems to be no facility to run a script "in the second pass" i.e., 
>  after all the interfaces have been brought up.
>  
>  Both of these facilities would seem to be useful, espcially being able to 
>  say "run these commands after interface X has been brought up".
>  
>  Have I missed something, or is this impossible at the moment (without
>  gluing more stuff in init.d/network)?  Would such mechanisms be useful in
>  other contexts as well?
>  
>  (This could be achieved, it seems, at least by using an '/sbin/ifup xxx
>  2ndpass' argument, and only specified commands would be run when doing the
>  second pass.)
>  
>  Thoughts, ideas, comments?
>  
>   
------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE                                jim(a)rossberry.com
http://www.rossberry.com

[Bill Nottingham]

Pekka Savola (pekkas(a)netcore.fi) said: 
>  When designing an IPv6 extension to initscripts, we came across this
> one 
>  particularly knotty problem.
>  
>  There seem to be no way to select the order in which the interfaces would 
>  be brought up by e.g. "network start", except by naming hacks.  (There are 
>  also this, nowadays smaller, problem of on-demand dial-up interfaces..) 
Correct, the only constraints made on ordering are by device type.
Otherwise it ends up being alphabetical.

>  There seems to be no facility to run a script "in the second
> pass" i.e., 
>  after all the interfaces have been brought up.
>  
>  Both of these facilities would seem to be useful, espcially being able to 
>  say "run these commands after interface X has been brought up". 
There's /sbin/ifup-local.

Bill

[Pekka Savola]

On Thu, 11 Sep 2003, Bill Nottingham wrote:
>  Pekka Savola (pekkas(a)netcore.fi) said: 
>  > There seems to be no facility to run a script "in the second pass" i.e., 
>  > after all the interfaces have been brought up.
>  > 
>  > Both of these facilities would seem to be useful, espcially being able to 
>  > say "run these commands after interface X has been brought up".
>  
>  There's /sbin/ifup-local. 
Yep, but that's slightly different, AFAICS.  It's run after everything
else has been done on that specific interface, but still sequentially.

Let's take an example, eth0 and eth1.

Eth0 is initialized first.  There is something there that should be run 
only after both eth1 and eth0 have been initialized.  You can't do that, 
even with ifup-local because ifup-local is run in the context of eth0, not 
eth1.

What you _could_, in theory, do is make ifup-local check that if the 
device is _eth1_, then do some operations on eth0.  But that's IMHO just 
way too kludgy approach, which assumes too much knowledge of the system in 
question.. and you want to be generic.

What _might_ work is is having some system in init.d/network, so that 
first 'ifup $device boot' would be run for all the devices, and soon one 
would run 'ifup $device 2ndphase' for all the devices (the most of which 
don't do anything).

An IPv6-specific way would be to add the stuff in the 'init.ipv6-global
start post' phase (but that has problems of it's own, because it's run in
the general context, not in the context of an interface), I guess, or more
generally, add it to the init.d/network.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

[Pekka Pietikäinen]

On Fri, Sep 12, 2003 at 12:08:25AM +0300, Pekka Savola wrote:
>  What you _could_, in theory, do is make ifup-local check that if the
>
>  device is _eth1_, then do some operations on eth0.  But that's IMHO just 
>  way too kludgy approach, which assumes too much knowledge of the system in 
>  question.. and you want to be generic.
>  
>  What _might_ work is is having some system in init.d/network, so that 
>  first 'ifup $device boot' would be run for all the devices, and soon one 
>  would run 'ifup $device 2ndphase' for all the devices (the most of which 
>  don't do anything). 
A related issue that might be possible to solve
simultaneously is 
having support for ifuping devices in the background. This is useful
if it's not certain how long it'll take or if it's possible to get the
interface up at all (my PPPoE :-) ). I ended up doing
a /sbin/ifup ppp0 &  in rc.local, which is a bit hacky but works well
enough.

Of course, some services need to run after ppp0 is up (ntpdate), which
causes some extra complications... I think there was some fancy framework
for simultaneous startup of different services in rawhide at some point, but
I could never figure out how to make it do anything useful :-) 

-- 
Pekka Pietikainen

[Paul Jakma]

On Thu, 11 Sep 2003, Pekka Savola wrote:

>  Hi,
>  
>  When designing an IPv6 extension to initscripts, we came across
>  this one particularly knotty problem.
>  
>  There seem to be no way to select the order in which the interfaces
>  would be brought up by e.g. "network start", except by naming
>  hacks.  (There are also this, nowadays smaller, problem of
>  on-demand dial-up interfaces..) 
it also applies to things like CIPE, the cipcb interface has to be 
brought up /after/ the relevant real interface (which might be ethX, 
pppX, etc..).

>  Have I missed something, or is this impossible at the moment
>  (without gluing more stuff in init.d/network)?  Would such
>  mechanisms be useful in other contexts as well? 
yes, definitely.

either a file to specify interface order, or else something like a 
generic DEPENDSON parameter to specify dependencies. File to define 
interface order is probably by far easiest to implement,

>  (This could be achieved, it seems, at least by using an
> '/sbin/ifup
>  xxx 2ndpass' argument, and only specified commands would be run
>  when doing the second pass.)
>  
>  Thoughts, ideas, comments? 
i'd go with a file a la:

cipcb9
cipcb?
eth2
eth1
eth?

and have the network scripts look for init scripts in the specified 
order in that file.

regards,
-- 
Paul Jakma	paul(a)clubi.ie	paul(a)jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam(a)dishone.st
Fortune:
The cost of living hasn't affected its popularity.

[Bill Nottingham]

Paul Jakma (paul(a)dishone.st) said: 
>  > There seem to be no way to select the order in which the
> interfaces
>  > would be brought up by e.g. "network start", except by naming
>  > hacks.  (There are also this, nowadays smaller, problem of
>  > on-demand dial-up interfaces..)
>  
>  it also applies to things like CIPE, the cipcb interface has to be 
>  brought up /after/ the relevant real interface (which might be ethX, 
>  pppX, etc..). 
cipe is already done after normal interfaces.

Bill

[Paul Jakma]

On Tue, 16 Sep 2003, Bill Nottingham wrote:

>  cipe is already done after normal interfaces. 
ah excellent! hadnt noticed that change.

cipe interface ordering was something that annoyed me greatly with 
7.3 (had to call all the scripts vcipcb? - but shutdown didnt work 
100% correctly, iirc).

good to hear that has changed!

>  Bill 
regards,
-- 
Paul Jakma	paul(a)clubi.ie	paul(a)jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam(a)dishone.st
Fortune:
Waste not, get your budget cut next year.

[Pekka Savola]

On Tue, 16 Sep 2003, Paul Jakma wrote:
>  > Have I missed something, or is this impossible at the moment
>  > (without gluing more stuff in init.d/network)?  Would such
>  > mechanisms be useful in other contexts as well?
>  
>  yes, definitely.
>  
>  either a file to specify interface order, or else something like a 
>  generic DEPENDSON parameter to specify dependencies. File to define 
>  interface order is probably by far easiest to implement, 
This is a good idea, but with more consideration, it may not be entirely 
trivial in the case that DEPENDSON would have to list more than one 
interface, or something generic like, "the interface the default route 
points to".

The more I think of this, the more interesting this 
DEPENDSON="<one-interface>"|"default" sounds; the latter would
be a 
general term to look up a default route (or something like that).
 
>  > (This could be achieved, it seems, at least by using an
> '/sbin/ifup
>  > xxx 2ndpass' argument, and only specified commands would be run
>  > when doing the second pass.)
>  > 
>  > Thoughts, ideas, comments?
>  
>  i'd go with a file a la:
>  
>  cipcb9
>  cipcb?
>  eth2
>  eth1
>  eth?
>  
>  and have the network scripts look for init scripts in the specified 
>  order in that file. 
The ordering may not always be so trivial, like "VPN interfaces" and 
"regular interfaces".  Eth0 could be upstream while eth1 would be intranet 
interface (and one could require the other), for example.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

[Paul Jakma]

On Tue, 16 Sep 2003, Pekka Savola wrote:

>  On Tue, 16 Sep 2003, Paul Jakma wrote: 
>  > generic DEPENDSON parameter to specify dependencies. File to
> define 
>  > interface order is probably by far easiest to implement,
>  
>  This is a good idea, but with more consideration, it may not be
>  entirely trivial in the case that DEPENDSON would have to list more
>  than one interface, or something generic like, "the interface the
>  default route points to". 
yeah, thats what i reckon - trying to solve it by listing 
dependencies could become quite involved i think.

>  The more I think of this, the more interesting this
>  DEPENDSON="<one-interface>"|"default" sounds; the latter would
> be a
>  general term to look up a default route (or something like that). 
hmm.. but it might not be dependent on the default route - it might 
be dependent on a specific route. (ie default goes via the ISP. But 
your 'VPN' or other interface depends on the route for your vpn peer 
to have been installed by ospfd or somesuch). very tricky really - i 
dont think going by dependent interfaces is viable - never mind 
routes.

>  The ordering may not always be so trivial, like "VPN
> interfaces"
>  and "regular interfaces".  Eth0 could be upstream while eth1 would
>  be intranet interface (and one could require the other), for
>  example. 
well, you could just list them explicitely one after the other i 
guess.

regards,
-- 
Paul Jakma	paul(a)clubi.ie	paul(a)jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam(a)dishone.st
Fortune:
The first time, it's a KLUDGE!
The second, a trick.
Later, it's a well-established technique!
		-- Mike Broido, Intermetrics

[Pekka Savola]

On Wed, 17 Sep 2003, Paul Jakma wrote:
>  > The more I think of this, the more interesting this
>  > DEPENDSON="<one-interface>"|"default" sounds; the latter
> would be a
>  > general term to look up a default route (or something like that).
>  
>  hmm.. but it might not be dependent on the default route - it might 
>  be dependent on a specific route. (ie default goes via the ISP. But 
>  your 'VPN' or other interface depends on the route for your vpn peer 
>  to have been installed by ospfd or somesuch). very tricky really - i 
>  dont think going by dependent interfaces is viable - never mind 
>  routes. 
In case you'd be interested of VPN or the like, you could just put a 
depends-on to the VPN interface (that should be pretty static, in most 
cases, I think).

The default route is a bit more special, as it's typically done using 
different interfaces, sometimes ethX, ipppX, pppX, what have you..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings