On Sunday 09 February 2003 10:15 am, Chad Carr wrote:

> Okay.  We are speaking the same language, but mine is a bit more
> abstract (could be considered good or bad).  A group of changes (say ip
> address, mask and gateway for an interface) may be aggregated into a
> single event using the trigger mechanism.  The triggers are still in a
> tree like so:
>
> /leaf/trig
>       ip/change
>       ip/add
>       ip/del
>       network/change
>       dhcpd/range/add
>       dhcpd/range/del
>       dhcpd/globals/change
>
> etc...
>
> I will think through your proposal a bit more.  I am thinking it could
> be better, as long as we can resolve temporal coupling between the
> scripts (i.e. the system interfaces file must be updated and network
> restarted before shorewall interfaces and restart...)

Well, basically the init scripts are run here on said option(s)
'restart'/reload' and use the RC:S option for run order or order
the scripts via name as Eric suggested (20ip). Surely
some of the code could be either put in a set of functions
or directly called. Personally, I think of the actual trigger as it's own
file/variable that could simply be set with a boolean value..

if [ -z `leaf-cdb get leaf/trig/$1/$2/boolean` ]; then break;
   else exec leaf-cdb get leaf/trig/$1/$2/script
fi

OR per Eric's idea with 'ls ordered output' added

 #ls eth0
40 eth0/etc/interfaces
60eth0/etc/shorewall/interfaces

-or some variant on this idea.
-- 
~Lynn Avants
Linux Embedded Firewall Project developer
http://leaf.sourceforge.net


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

_______________________________________________
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to