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).
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.
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
- h