Hello Lynnand all other configurators  
I did read the mails but kept back to not disturb the brainstorming ;) 

sorry for the long post.
> > This works fine for things like ifconfig/route, and even
> > iptables/ipchains, where the built configuration resides in memory, but
> > it begins to fail when configuration is via a file on the "disk".  Using
> > dhcpd as an example, not only does the configuration file have to be
> > intelligently updated if a variable it depends on changes, something has
> > to restart (or HUP or whatever) the daemon to get it to recognize it's
> > config has been updated.
> Duly noted. Where does the responsibility of the 'check' and 'restart' lie?
> This would seem to be the respnsibility of the back-end (save-script), on
> first glance. Would a "trigger" be a good method? Would a seperate db 
> need to be made to keep track of "triggers" and the needed information?
> I'm assuming a dynamic db based on a list of used variables contained
> in the package itself. Thoughts?
I was thinking in the same line  
parrallel to the database containing the (global) variables there 
should be a  database with a tree structure like
The value of dependant file is the action to take after change ( hup 
restart etc)  

during change of value varname ( by Api)  you could use a script like:

for file in  /dbtree/dependancy/varname/*  do  update $file  
which means touch the /actiontree/update/$file
so after all the value changes are ready and you do a "commit"

all the files in actiontree/update/$files are filled with their vars and
written to the original config files  
after doing this the  actions (hup, restart reload or whatever are 
I know this last part is still bad formulated. ( Isn't clear for me yet)
> > I think the best general solution so far has been presented by Chad
> > Carr.  A templating system, combined with a configuration database or
> > tree, allows boot-time creation of customized configuration files from
> > standard (unmodified from distribution form) pacakges and localized
> > configuration information.  With a standard package <> congifutation
> > API, the configuration system can support "callbacks" or similar,
> > letting a package know when values it depends on have been modified,
> > triggering a rewrite of the configuration file, the restarting of a
> > daemon, or whatever else might be necessary.
> With some playing, I'm starting to agree with this to a point. A tree that 
> contained '/path/variable/value' would be simple to set and change. 
> However pairing the variable/value might not be too fun to use in
> the files that use this infomation. Considering this, if there was an 
> added single db file that would concentrate the tree db information,
> there would be an option to easily find 'where' to change a value
> (by hand) and location to source for the run-time packages themselves.

> Let's say something like this:
> /db-tree/interfaces/eth1/ip_address  (contains
> /etc/db.cfg contains:
> PREFIX=/db-tree
> LAN_IP='cat /$PREFIX/interfaces/eth1/ip_address'
> Then the application uses:
> source /etc/db.cfg
> #Internal interface ip address to use
> Thoughts???

3 playing examples :
to get a directory structure and a database file in sync so they are not 

# reads variables from database and creates a dir structure

sed 's/=/ /g' $database |while read varname value
cd $configdir
set -- `echo $varname |sed 's/_/ /g' `
while [ "x$2" != "x" ]
mkdir  $1
cd $1
echo $value >$1

# reads files from dirs and assigns them
# to a var = value pair in newvars
rm $database
cd $configdir

find .  -type f  |while read file
value=`cat $file`
varname=`echo $file |sed 's/^\.\///g'|sed 's/\//_/g' `
echo "$varname=$value" >>$database


# called as fillinvars  templatefile realconfigfile
. $database
rm $2
cat $1 |while read line
# the next lines could be omitted if we don't want to have 
# comments in the real config ( only in template)
[ " `echo $line |cut -c1 "" = "#" ] 
echo $line >>$2
eval echo $line >> $2   # this is the only real one ;) 

Ofcourse it certainly can be done more elegant more clean and 
without showing  error messages. ( I am not a unix coder anyhow ;) )
I just added this scripts to show that it should be doable without much 

a template would then look like

# lots of comments
ALL: $eth1_ip/$eth1_netmask

the real config file

Packages could contain only the templates not the realconfigs as 
they are created at boot time.

any thoughts,flames,comments 

Eric Wolzak
member of the bering crew

This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!

leaf-devel mailing list

Reply via email to