On Mon, 2003-02-10 at 21:58, Lynn Avants wrote: > 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
Hmmm. I am still not quite getting this. I think that it assumes one callback for each variable? Am I wrong? Either that or we would have to have some way to walk the tree when we were done setting values, looking at each "boolean" to see if the "script" should be run? I now have a full triad of prototypes for the system I proposed in cvs (devel/ccarr/devel/leaf-*). The programs are leaf-cdb, leaf-tmpl and leaf-trig. There is some documentation and usage statements for each, with more on the way as soon as I get some sit-down time. There is also a single test trigger - ip/change - that will show the full circle of behavior (albeit a trivial example). This trigger will ungracefully replace your /etc/resolv.conf and /etc/hosts files, so I do not recommend running "leaf-trig ip/change" directly on your system without making copies of those files. The included makefiles install executables to /leaf/bin, a test config-db to /leaf/cdb, a test template hierarchy to /leaf/tmpl and a test trigger hierarchy in /leaf/trig. The next step for me is to look thoroughly through bering and map out the interface, i.e. db keys-values and triggers, then implement one of the more complicated ones to make sure that the framework will stand up to advanced usage. Has anyone already done some of this work? If so I'd like to take a look at it before beginning. Thanks, -- ----------------------------------------------------------------------- Chad Carr [EMAIL PROTECTED] ----------------------------------------------------------------------- ------------------------------------------------------- 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