On Jul 5, 2004, at 1:24 PM, Erich Titl wrote:
Your analysis is convincing, especially as it covers the most important part of getting the system configured the way the user wants it.
My suggestion to allow the inverse way was wrong in the way it was formulated. I would actually love if the UI showed the _actual_ state of the system. regardless of the config files, because the end user will typically also use such tools to check the actual system status.
If this is consistent with the system status at load of the UI we'd have a good starting point.
Whenever a change is confirmed in the UI this state should be written to the config database _and_ the system which would keep us in a consistent state. This would, of course, require quite a sophisticated control mechanism, e.g. when the user changes an IP address, subsystems like shorewall and ipsec would probably have to be reconfigured and restarted.
The purpose of having "trig" is to handle system-wide notifications of cdb changes for just this purpose. The idea is that the user makes a configuration change in the cdb, then the UI calls a predefined trigger method for that change. Any package that needs to know about that change "registers" for the event by dropping a shell script in the proper directory on the system, which is called when the trigger fires. The package can do whatever it wants in that script, up to and including rewriting its configuration files, setting other cdb variables, restarting dependent services, etc.
Hope this makes sense.
It does to me.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
