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 db_tree/dependancy/varname/dependant_file1 db_tree/dependancy/varname/dependant_file2 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 done) 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 192.168.1.254) > > /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 > $LAN_IP > > Thoughts??? 3 playing examples : to get a directory structure and a database file in sync so they are not exclusive. var2dir ------- #!/bin/bash # # reads variables from database and creates a dir structure # configdir=/leaf/test/config database=/leaf/test/vars sed 's/=/ /g' $database |while read varname value do cd $configdir set -- `echo $varname |sed 's/_/ /g' ` while [ "x$2" != "x" ] do mkdir $1 cd $1 shift done echo $value >$1 done .................... dir2var #!/bin/bash # # reads files from dirs and assigns them # to a var = value pair in newvars # database=/leaf/test/newvars configdir="/leaf/test/config/" rm $database cd $configdir find . -type f |while read file do value=`cat $file` varname=`echo $file |sed 's/^\.\///g'|sed 's/\//_/g' ` echo "$varname=$value" >>$database done --------------------------- fillinvars #!/bin/bash # # called as fillinvars templatefile realconfigfile # database=/leaf/test/vars . $database rm $2 cat $1 |while read line do # # the next lines could be omitted if we don't want to have # comments in the real config ( only in template) if [ " `echo $line |cut -c1 "" = "#" ] then echo $line >>$2 else eval echo $line >> $2 # this is the only real one ;) fi done --------------------------------------------------- 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 coding a template would then look like /leaf/template/hosts.allow # # lots of comments # # ALL: $eth1_ip/$eth1_netmask the real config file ALL: 192.168.1.32/255.255.255.0 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! http://www.vasoftware.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
