On Tue, 2003-02-04 at 19:20, Matt Schalit wrote:
> But it was pointed out to me that the XML database in Chad's idea
> was something to be kept seperate from LEAF and not stored on it.
> I think that the XML is used on seperate OS to configure the system.
> I think the idea of Chad's was to combine an XML config-db with a
> remote based gui and produce template-built runtime conf files
> that would be used on the LEAF.
I think I haven't been following this thread closely enough. Or maybe I
have not been perfectly clear. Or maybe you are talking about a
different Chad. Sorry for the mixup and long post on any of the above.
I do not think that XML is suitable for LEAF (pre or post config). My
config-db-as-filesystem-hierarchy idea consists of a key-value pair
"database" that happens to be made up of separate files for each
key-value pair. The "api" generates sourceable name-value pairs that
can be eval'd by shell scripts.
It is meant to be used _on_ the system. Please do not confuse this with
what I actually have in my devel source tree. The two are not
interrelated (and I have not done any actual work on this one ;-))
This is a slightly modified version of what I sent Lynn offlist this
morning to better explain my _theory_ (emphasis on theory since I
haven't actually done any of it yet).
<snip>
The basic idea is that there is an api that gives you sourceable
material from the tree relative to the path /leaf/cdb, something like
this:
leaf-cdb get interfs/eth0/ipaddr
returns:
interfs_eth0_ipaddr=172.24.8.24
if the /hydra/cdb/interfs/eth0/ipaddr file contains
172.24.8.24
so the calling script can just eval it like so
eval `leaf-cdb get interfs/eth0/ipaddr`
This also works for entire trees or arrays of material from the
"database:"
eval `leaf-cdb get tree interfs/eth0`
# now I can use relative paths; ipaddr, netmask, gateway, etc
The templating system is much harder. I am afraid it would need to be
written in C. Ideally, you could use it like this:
leaf-cdb get tree interfs | leaf-tmpl -o /etc/network/interfaces
would generate the /etc/network/interfaces file using the "symbol table"
from the output for the leaf-cdb command.
This may, however, be really very hard without perl.
The piece de resistance is the trigger system. The template and
config-db systems are just support. The trigger system makes it go.
Something like:
leaf-trig fire ip_change eth0
would use run-parts to run all the scripts dropped into the
/leaf/trig/ip_change directory with the argument eth0. One of these
scripts will call
leaf-cdb get tree interfs | leaf-tmpl -o /etc/network/interfaces
and then restart the network. The scripts are prioritized like rc
scripts to resolve temporal coupling.
If I need to respond to the ip_change event, I can simply drop a script
into /leaf/trig/ip_change. If I do not care when ppp* interfaces
change, I can bail immediately if the first argument starts with ppp.
So, for a web interface, the work flow could go something like this:
# optionally feed name-value pairs on stdin
leaf-cdb set tree interfs/eth0 ipaddr 172.24.8.24 netmask
255.255.255.0 gateway 172.24.8.1
leaf-trig fire ip_change eth0
Then the handler scripts take it away:
- file /leaf/trig/ip_change/001interfaces: modifies interfaces
and
restarts network -
#!/bin/sh
leaf-cdb get tree interfs | leaf-tmpl -o /etc/network/interfaces
/etc/init.d/network restart
- file /leaf-trig/ip_change/10minhttpd: modifies minhttpd
startup
script that has ip address in it, then restarts minhttpd -
#!/bin/sh
leaf-cdb get tree interfs | leaf-tmpl -o /etc/init.d/minhttpd
/etc/init.d/minhttpd restart
Simple to use, if it is designed properly. However, the technical
hurdles of the implementation may prove to be too much. It is easily
done with perl (as are many things), but the power and simplicity of
shell and C, especially when used together, are great (as all UNIX folks
know) and I think it can be done.
The beauty of this is that the trigger responder does not know who fired
the trigger, the one responsible for firing the trigger does not know
(or care) who is listening, and the config-db is just an anonymous
backend data store (strangely, it can even be used to store the results
of temporal events, like the result of a particularly sensitive
templating operation, for anonymous retrieval later) decoupled from any
specific package.
I am not trying to convince folks. I am not even sure that the
technical hurdles can be overcome without perl. I am no C guru, but I
can hold my own and would be willing to work on it if shell does not
suffice to create the interfaces we are looking for.
</snip>
So, to recap my carefully considered opinion (if anyone cares):
- No XML (especially not on the box)
- one file per name-value pair
- hierarchy is still hand-editable
- hierarchy can represent nearly anything XML can (at least basic XML)
- API gives get, set, take and del methods that can act on individual
name-value pairs or trees (with the optional "tree" modifier)
This is what I am thinking of as far as a usage statement for the api:
usage: leaf-cdb get|set|take|del [tree root] [args ...]
get - return sourceable name-value pairs for args on stdout
set - set name value pairs using args
take - return sourceable name-value pairs using args, then delete
del - delete keys from repository
The optional [tree] modifier just says to cd to that position in the
hierarchy before getting, setting, taking or deleting keys. Therefore,
keys are relative to that position. The optional [root] arg is tied to
the tree modifier and gives the starting postion for tree operations.
The [args] are key names and are required for get, set or take; not
required for set if you pass name-value pairs on stdin. They will be
parsed by transliterating underscores with slashes and constructing the
path, relative to [root] if [tree] modifier is included or relative to
/leaf/cdb if not provided. I.e.
interfs_eth0_ipaddr=172.24.8.24
interfs_eth0_netmask=255.255.252.0
interfs_eth0_gateway=172.24.8.1
interfs_eth1_ipaddr=0.0.0.0
Could be passed on stdin to the command
leaf-cdb set
OR
eth0_ipaddr=172.24.8.24
eth0_netmask=255.255.252.0
eth0_gateway=172.24.8.1
eth1_ipaddr=0.0.0.0
Could be passed on stdin to the command
leaf-cdb set tree interfs
OR
leaf-cdb set tree interfs eth0/ipaddr 172.24.8.24 eth0/netmask
255.255.252.0 eth0/gateway 172.24.8.1 eth1/ipaddr 0.0.0.0
Each of the above would (possibly) have the same effect. I say possibly
only because when we did a "set tree" it was implicit that we were
setting the entire tree and that all previous name-value pairs should be
deleted from that point down. That makes it much easier to go from,
say, static to dynamic ip addressing since you don't have to delete the
previous settings, but you could simply say:
leaf-cdb del tree interfs
prior to doing your thing and it would have the same effect, so it may
not be necessary to do anything implicit unnecessarily.
Well, what do you think? Completely in the weeds?
----------------------------------------------------------------------
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
