On Sun, 2003-02-09 at 05:58, Eric Wolzak wrote:
> Hello Chad, I really think we were miscommunicating,( we have different background
> ;) ) but I'll try again > >
>
> Packages
> Packages own templates of their configuration files or scripts to generate those
> packages ( even better)
> Packages own several variables ( necessary to configurate the package)
> The values of this variables are stored in a database
> A)
> Some of the variables are only used in scripts of this specific package ( f.e
> ppp0_dialnr) A change would have an effect only on this package
> B ) Others are used in several packages.(for.example eth0_ipaddress) a change to
> one of those would effect several packages
> A variable and a package cannot know if it ( variable) belongs to group A or B
> (someone could have added a new package that makes a variable belong to more
> than one package). So to be on the safe side, assume all packages belong to group
> B)
> The variable must know the scripts it is "tied to"
Not really. Why must it? Any interface that configures the variable
simply fires the trigger that says it has done so, which means "run all
the scripts in this directory" and it is done. If someone wants to tie
into a variable in package B, he simply drops a script into the trigger
directory for the event he wants to act upon, and when he is called,
gets the current value from the config-db, remakes his templated config
files, and restarts himself.
> The database is assessed only by a config-db api that reads and writes a "key" or a
> "tree"
> Some userinterface ( for example webinterface) requests variables from the
> database and uses them to create a webpage based on a script belonging to a
> "userinterface-script pool" .
> After input by the user, the now possible changed variables (in userspace) are
> presented to the config-db to be set in the database. (config-db.set var1 var2 ...)
>
> Now it is necessary to "commit" this changes so the config-files are still in sync
>with
> the database.
> At commit the config-files "tied-to" the changed vars are regenerated
> After change of config-files the belonging services are restarted.
>
> I think untill now we are communicating the same infrastructure.
Yes. The variables are "tied to" the scripts via the trigger
mechanism. That way, the variable can be untied simply by deleting the
script (or more likely just not installing the package). The beauty of
the mechanism is that the variables and scripts are "tied" in a loosely
coupled manner, which means that either can be removed or changed
without effecting the other, as long as the interface (config-db value,
trigger and args) remain unchanged.
> My proposition was to create a database in the same tree structure
> variable /tied-toscrip1.name (content script to run after changeing tied-
> toscript1.name)
> variable/ tied-to sciipt2.name
> (this was my "dependant" database.
>
> example
> #ls eth0
> eth0/etc/interfaces
> eth0/etc/shorewall/interfaces
>
> #cat eth0/etc/interfaces
> ifdown eth0
> ifup eth0
>
> # cat eth0/etc/shorewall/interfaces
> shorewall restart
>
> (<optimizing > )
> after changeing a variable drop the tied-script.name s in a queue
> after finishing the interaction user <-> interface
> update all scripts in the queue
> These commits can be queued untill the end of the user configuration session ( so
> after making 3 changes the sripts don't have to run 3 times)
> (</optimizing>)
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...)
> > - then I back myself up (heh. I don't know the intimates of how
> > this one is done, Mr. Wolzak)
> How, will depend on the packageing system to choose uptill now it will be
> lrcfg.back.script with some options.
I figured you could shed more light on this when the time came ;-)
> > 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!
>
> this is a misunderständing, I mentioned the webinterface to show one way of user
> interaction.
>
> I suggested that each package contains a file with the
> 1. names of the used vars
> 2. type of the vars ( to make it easier for the user interface)
> 3. possible values ( if a var can have only three different options )
Yes. Good. I only think we should drop files into a "www" tree in the
config-db instead to facilitate parsing with the same tools. I.e.
/leaf/cdb/www/dhcpd/
var/
begin_range
end_range
routers
domain-name-servers
domain
enabled
/leaf/cdb/www/dhcpd/
type/
begin_range
end_range
routers
domain-name-servers
domain
enabled
/leaf/cdb/www/dhcpd/
values/
enabled
> the idea behind is to make the system of "validating changes" and presenting to user
> easyier
> We need only a few routines in the commit section that checks a value and can be
> used by each script that adaps config files.
> used as toolset.
Yes. validate_ip, validate_hostname, validate_domain, etc.
> I thought about it as I was still considering that a script to create a config file
>would
> look like
> # this is xyz config
> $dev $ip_address
> # the hostname is $hostname
> $dialyesno dial $dialnr
> $option_1
> $option_2
>
> But the template script probably would be better in a form
> #!/bin/bash
> writecomment this is xyz config
> write $dev $ip_address
> write_if_set dial $dialnr
> writerepeat $option
>
> in this case that information is in the template script, a gui script could then
>easily be
> analog.
So far, the template script treats the template as a big heredoc (which
is _kind of_ abstract), except it processes it line-by-line. You can
take a look in devel/ccarr/devel/leaf-tmpl in CVS if you like. It isn't
completely cooked yet. I have some more ideas for it but am not sure
how to execute. I will have more in a few days. Let me know if you
have ideas.
> Sorry dreaming above the infrastructure ; )
That is a-okay! It is one of the major reasons we are doing all this so
someone should start thinking about it to make sure what we are doing
now will provide all the facilities that we need
--
-----------------------------------------------------------------------
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
