On Sat, 2003-02-15 at 03:43, Eric Wolzak wrote:
> Hello Chad Lynn
>
> I added a routine sget to leaf-cdb (cdb) to get an output like this
> leaf-cdb sget tree shorewall/rules action/0 source/0 dest/0 dport/0
> 'ACCEPT' ' net' ' fw' '22'
> reason see below
I do not really think this necessarily requires a new syntax to be
clean; just a new organization of your hierarchy. Try something like
this:
shorewall/
rules/
count
<index>/
action
source
dest
proto
sport
dport
odest
Then you can call
cdb get tree shorewall/rules/0 .
which generates
action='ACCEPT'
source='net'
dest='fw'
dport='22'
...
> #
> # here is the logic
> #
> i=`/leaf/bin/leaf-cdb get shorewall/rules/action |wc -l`
> nr=0
> while [ $nr -lt $i ]
> do
> writerow $nr $nr `/leaf/bin/leaf-cdb sget tree shorewall/rules action/$nr
>source/$nr
> dest/$nr proto/$nr dport/$nr sport/$nr odest/$nr`
>
> nr=`expr $nr + 1 `
> done
Then you can call your function in a loop like so:
eval "cdb get tree shorewall/rules count" # creates $count
i=0 # loop var
while test $i -lt $count
do
eval "cdb get tree shorewall/rules/$i ."
writerow $i $i $action $source $dest $proto $dport ...
i=$(($i + 1))
done
We could also create a syntax like so to avoid the maintenance of the
'shorewall/rules/count' member:
cdb get count shorewall/rules
which counts the number of directories or files in that directory.
> I had problems with the setting
> leaf/bin/leaf-cdb get tree shorewall/rules action/$nr source/$nr .... >>
>/tmp/sourcefile
>
> and useing the
> . /tmp/sourcefile in the configuration setup to insert the vars .
Yes. This part of the code is documented but not yet written. The
interface does provide for this. I have one part of it written, but not
yet checked in until I get the other part done. It will work like this:
cdb get tree shorewall/rules . | tmpl -o /etc/shorewall/rules
cdb get tree shorewall/rules . | tmpl -o /etc/shorewall/...
Which will make the shorewall rules tree into a "symbol table" for the
template in /leaf/tmpl/etc/shorewall/rules (which may also be a
directory of template fragments). It will write the result to the
system file /etc/shorewall/rules. Voila!
I am working on the code to be able to place "directives" in the
templates like so:
### BEGIN tmpl
@FOREACH rule shorewall_rules
$i $i $rule_action $rule_source $rule_dest ...
@END
### END tmpl
$i will be aliased to a counter for the loop index. The first argument
will be aliased to (essentially) a variable named "${second_arg}_0". So
saying $rule_action will actually give you the value of
"$shorewall_rules_${i}_action"
This is just beginning to gel. I will probably have something after
this weekend, if you can wait that long.
> #
> The writeback part of the script is not completely functional yet , some detail
> problems , they allways take the most time ;(
> But I feal we are on the right way :)
> The size we loose with this system is partly recovered from the leaner config files.
I think so too.
> 2. Database
> The database must only be defined definitively for variablest that are used in
> different Packages. Otherwise someone calls the ehternet 0 ip address eth0_ip
> another eth0_ipaddr etc
Yes. I have defined in my tree some of the package vars for packages
that come by default with bering. These will actually be described by
the package, however.
> We should have a rule that each maintainers informs a central documentation what
> vars he used.
Yes. If simply for user documentation.
> Those should be documented on the leaf page wth a comment what the var is for.
> This to prevent the use of the same name in different packages or versions for
> different purposes.
The hierarchical layout creates a pseudo-namespace which prevents some
of this, but you are right nonetheless. Keep in mind also that it is
not improper that two packages that do the same or similar things (i.e.
udhcp and dhcpd) share the exact same variables in the config-db.
--
-----------------------------------------------------------------------
Chad Carr [EMAIL PROTECTED]
-----------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
