On Sat, 2003-02-08 at 14:35, Eric Wolzak wrote:
> Hello Chad
>
> > I am game for writing code that will accept any hierarchy
> > delimiter and allowing folks to use any of them. My preference is
> > actually '.' but it is not a proper character in a shell identifier. I
> > do think that the '_' doesn't properly emphasize the "path" or "object"
> > nature of the hierarchy access. But like I said, I am game for
> > anything.
> agreed ( I like the _ because I don't need somuch escape signs ;) )
>
> > > if a tree exists eth1/ip/mask then it is impossible to create a
> > > eth1/active
> >
> > I can't replicate this. Can you give me a screen shot of your terminal
> > session?
> Neither can I anymore, tomorrow I got the problem, but probably
> there was something different corrupt in the database
> Now it functions. I cannot replicate it.
I have found one bug that you may have been seeing. Add this as line 84
of leaf-cdb (the lset function must create directory parents before
adding a file into a key):
mkdir -p "$2" || { exit 1; }
> > > what I did was create a tree dependant which a structure
> > > varname/dependanttmplate1
> > > varname/dependanttmplate2
> > > etc.
> > >
> > > The trigger to any action is the change of a variable
> > > allthough it shouldn't be trigger each time a var is changed but first
> > > after the complete change is ready
> > > So my idea was set flag I am changeing.
>
> > Locking or update atomicity is a different issue than triggers. They
> > should be addressed separately. The trigger handlers are just a
> > methodology for notification of a system event so that anyone may react
> > to the event, anonymously.
> The idea behind the database is that we can configure the box by
> communicating with an api by way of for example a webinterface
> Each time a webpage returns changed vars then the real config files
> aren't in sync with the database anymore. So all configs which
> templates contains the changed variables should be updated.
> What I ment is that IMHO it isn't a good idea to update all the config
> files during an editing session.
> Remember the vars or the files that contain them.
> And after the editing session is finished update those config files by
> filling them with the variables.
> We can of course save us some accounting by updating all config
> files. ;) It depend on what is faster.
I think I am miscommunicating. The config-db api is like an "object"
("set" this, "get" that from some "key" or "tree") and the final method
called after manipulating that object is a "commit" which tells the
object to flush the manipulated settings to disk (regenerate config
files), and apply the changes (restart whatever services are tied to the
value).
The "commit" in this case is nothing more than a triggered event
(probably implemented almost as simply as (for instance):
# run-parts --arg="eth0" /leaf/trig/ip/change
that runs all the scripts in that dir with "eth0" as the first
argument). The "handlers" listening for the event decide what is meant
by the commit - that way there is not one central object that must know
everything that must happen when an ip address changes.
The web interface knows nothing but a purely abstract interface:
variables to change and triggers to fire after they are changed.
> thinking a loud now I realize that we are creating a kind of OOP
> language structure. (correct ? )
> In that case it could be usefull too write the system in a UML like
> description. :)
> A package has one or more configuration scripts that have one or
> more configuration parameters,
> Those parameters has several properties
> it has one or more values
> it has a value type
> it has 0 or more repetition
> So the whole configuration could be looked at like a tree.
> The problem is now that a paramter can belong to 1 or more
> packages.
> ( makes it complicated again :( )
Yes, kind of. But I don't know anything about UML and I think the
complexity is much lower than you are thinking. It is really like this:
A package has a set of keys in the config-db under his control, plus he
cares about three other "core" or "global" keys that belong to other
packages. He defines his own keys for manipulation by the web interface
(and populates them with default values) and installs handlers (drops in
scripts) to handle both his own triggers (i.e. - dhcpd/scope/change,
dhcpd/scope/add, etc.) as well as the documented events that are fired
when the other keys he cares about changes.
There is no need to document the whole system including all handlers;
just the keys and events. Packages vary from one LEAF install to the
next, and because of the radical decoupling, the individual package
basically documents itself by where it places scripts, the keys it puts
on the system, etc.
> > > We could have a configuration-template
> > > for example /etc/hosts has etc_hosts.tpl
> > > $host_ip $hostname
> >
> > Actually, it is even easier than this. There is a template root sibling
> > to the cdb (/leaf/tmpl) and any system file that needs to be templated
> > may be dropped in relative to its final path on the system, i.e.
> > /etc/hosts template goes in /leaf/tmpl/etc/hosts and templating program
> > automatically finds it and writes it to the correct place.
>
> how do you find which file has to be updated
> grep "changedvarname" /leaf/tmpl/ ?
> the api doesn't know who (which file) put the variable in the
> database.
> If you search all templates with each change you could have a
> problem with the performance on low performance systems ?
The trigger handler decides what to do when the variable is changed,
e.g.
- Web interface changes the ip address of eth0; fires the ip/change
trigger with argument of "eth0" (web interface is done!)
- I have installed a script to handle this event because I care if an ip
address changes on one of the interfaces I am configured to use.
- if I am bound to eth1 only, I look at my first arg, see that
it is "eth0" and exit immediately (I have nothing to do)
- if I am using eth0, I need to rewrite my config file. I know
that it is located in /leaf/tmpl/etc/dhcpd.conf (for instance)
so I call the config-db api to get the current values for eth0
and pass them to the templating program like so:
# leaf-cdb get tree interfs/eth0 | leaf-tmpl -o /etc/dhcpd.conf
- then I restart myself:
# /etc/init.d/dhcpd restart
- then I back myself up (heh. I don't know the intimates of how
this one is done, Mr. Wolzak)
VOILA! All dirtiness gone!
> > > 1) lists the used variables and the type
> > > type means here
> > > string
> > > value
> > > one out of optionx|optiony|optionz
> > > optional value
> > >
> > > and a default value.
>
> > > varname type optionstochose default "helpfull name"
> > > eth1_ip N - 192.168.1.254 "IP Address"
> > >
> > > a (web) interface could easily pick this up and almost automaticaly
> > > create a webpage. to edit this var.
> >
> > Yes, but we may want to create a hierarchy for this purpose and use the
> > same tools to avoid parsing another format.
>
> OK
> What i wanted to say, but wasn't clear for myself yet is that a line
> with vars could have a repeat property.
I am obviously not getting what you are saying here. Please elucidate
further. Please keep in mind that I am only speaking of the framework
and infrastructure here, and not in detail on the specifics of the web
interface. We need a firm concept and toolset before we start webbing!
--
-----------------------------------------------------------------------
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
