Re: [leaf-devel] Template system [was Webconfiguration]

[Greg Morgan]

One of the things I had not designed but thought about was variables. So here's a possible definition in XML.

<GMLEAFPackage>
<Package Name="weblet">
<RequiresPackage Name="" DependancyOrder=""/>
<File Name="weblet.conf" Location="/etc">
<Variable Name="" Type="">
<comment></comment>
<value></value>
</Variable>
</File>
</Package>
<Package Name="nextpackage">
<RequiresPackage Name="libz" DependancyOrder="0"/>
<RequiresPackage Name="libxyz" DependancyOrder="1"/>
<File Name="nextfilename" Location="/etc">
<Variable Name="" Type="">
<comment></comment>
<value></value>
</Variable>
</File>
</Package>
</GMLEAFPackage>


Whereas GMLEAF would define specifics to a distribution, GMLEAFPackage would define specifics to a package. This XML gives some of the ideas that have to be addressed in any GUI configuration system.

o All the configurable files of a package must be collected.

o All the variables in a package must be collected.

o All the types of variables used in all LEAF distros must be collected and given a type name.

I believe this is at the heart of any new configuration system that tries to make it easy on the users. If any standards are defined then they primarily would focus on how shell scripts are constructed. A carefully constructed variable section would be created at the beginning of each script. Another way to do this would be a configuration file that is sourced. The tweaking of the packaging system would be that all files would be cleaned up accordingly.

The first two items are obvious. In any simplified configuration system you have to know all the packages that will be configurable. Additional packages could be added as they are developed. In each package you have to know all the important files that must be hand edited. Once all the variables have been collected, a general pattern of variable types will emerge. That is what the XML type=�� field is designed for. What do I mean by type? Let's think about three off the top of my head.
There is the simple shell variable myvar=1234.
There is the space separated list myvarspace=�1234 1235 1236�.
There is the etc host kind-of-variable �127.0.0.1 localhost alias1 alias2�.

The GUI would simply replace search and replace name for the value or define the configuration file from scratch. I would think building a configuration file that is sourced into another file would be the easiest to build. The second would be to have a search target at the beginning of a file where all variables would be defined. A search target would be something like
# BEGIN GUI CONFIGURATION VARS
# END GUI CONFIGURATION VARS
This of course would depend on the standard that is selected.

Here's how these three types of variables may look in a database. Again the presentation of the flat file database is provided in XML.
<Variable Name="myvar" Type="simple">
<comment>This is #, pound style comment that goes before the variable on the proceeding line.</comment>
<value>1234</value>
</Variable>
The line reconstructed would be
# This is #, pound style comment that goes before the variable on the proceeding line.
Myvar=1234

Here's a sample space separated list variable.
<Variable Name="myspacevar" Type="space">
<comment>this var does that.</comment>
<value>1234</value>
<value>1235</value>
<value>1236</value>
</Variable>
The line GUI reconstructed would be
# this var does that.
myvarspace=�1234 1235 1236�

The host style variable could have one of two implementations. One would be to let the user type in the configuration value free form.
<Variable Name="127.0.0.1" Type="host">
<comment>loop back host</comment>
<value>localhost alias1 alias2</value>
</Variable>
The line GUI reconstructed would be
#loop back host
127.0.0.1 localhost alias1 alias2

The other implementation provides more control for the GUI program to reconstruct the /etc/host line.
<Variable Name="127.0.0.1" Type="host">
<comment>loop back host</comment>
<value>localhost</value>
<value>alias1</value>
<value>alias2</value>
</Variable>
The line GUI reconstructed would be
#loop back host
127.0.0.1 localhost alias1 alias2

If a database system like XML is used, then some simple vim tricks can be used to generate variable lists. Ok regexs are not always easy to read but the following

:'a,'b s/^\(.*\)\(=\)\(.*\)$/<Variable Name="\1" Type="simple">^M <comment><\/comment>^M <value>\3<\/value>^M<\/Variable>/

quickly converts weblet.conf to the XML rough format. Note that hand edits would be required to move the comments around. However, sed could be used to do just about the same and it reads across end of line boundaries.
# Warning/Error thresholds for the weblet utility
# Disable checking of any value by setting it to -1

# Firewall thresholds: deny/reject messages
<Variable Name="WRN_FW" Type="simple">
<comment></comment>
<value>5</value>
</Variable>
<Variable Name="ERR_FW" Type="simple">
<comment></comment>
<value>50</value>
</Variable>

# Memory thresholds: percent available
<Variable Name="WRN_MEM_PCNT" Type="simple">
<comment></comment>
<value>10</value>
</Variable>
<Variable Name="ERR_MEM_PCNT" Type="simple">
<comment></comment>
<value>5</value>
</Variable>
# Memory thresholds: KBytes available
<Variable Name="WRN_MEM_K" Type="simple">
<comment></comment>
<value>512</value>
</Variable>
<Variable Name="ERR_MEM_K" Type="simple">
<comment></comment>
<value>256</value>
</Variable>

# Default Disk thresholds: percent available
<Variable Name="WRN_DISK_PCNT" Type="simple">
<comment></comment>
<value>10</value>
</Variable>
<Variable Name="ERR_DISK_PCNT" Type="simple">
<comment></comment>
<value>5</value>
</Variable>
# Default disk thresholds: KBytes available
<Variable Name="WRN_DISK_K" Type="simple">
<comment></comment>
<value>200</value>
</Variable>
<Variable Name="ERR_DISK_K" Type="simple">
<comment></comment>
<value>100</value>
</Variable>

# Default Disk thresholds may be overridden by per-device settings
# [WRN|ERR]_DISK_<device>_[PCNT|K]
<Variable Name="WRN_DISK_ram0_K" Type="simple">
<comment></comment>
<value>768</value>
</Variable>
<Variable Name="ERR_DISK_ram0_K" Type="simple">
<comment></comment>
<value>256</value>
</Variable>

I don't know if you would want to call it a standard but the /etc/lrp.conf file may have to take on a more active roll in all distributions. For example the dhclient.lrp package has a conflict. I cannot pull the package from Jacques Nilo's site and use it on a Dachstein router without editing the /etc/dhclient-exit-hooks script. In a dynamic IP address situation, this is he place that the IP address is renewed or a new IP address is received. The firewall in use must be restarted. So Jacques version restarts shorewall while Charles Steinkuehler's Dachstein exit hook script must restart the stein series of firewall scripts. What if I want to use Scott Best's Echo Wall firewall because of all the configured port settings? All distributions would have to agree to a �tweak�. /etc/lrp.conf would contain a variable called firewall or some such. The firewall variable would be set to say, �echowall� i.e. firewall=�echowall�. Then every where that an operation on the firewall was required a case statement would be coded.

. /etc/lrp.conf
case $firewall in
echowall)
#test file for existence and do some operation
stein)
# same here
shorewall)
# same here
*)
# Log an error message and display another one on the console that
# something is terrible wrong here.
esac

Like I said in another post this is a very interesting problem. However, some deep thought must be given to variables and the type of script clean up or tweaking that is required to make a GUI configuration system possible. Hopefully, the standards and other required issue resolution would not take both the spirit and character out of each distribution!

Regards,
Greg Morgan




-------------------------------------------------------
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