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