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

[Greg Morgan]

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

My presupposition is that the LEAF lrp archive is a great tool. It is great for what it does. Its that just that the gziped tar archive is not easy to edit by hand. In any system that evolves from these discussions, the system has to have an implementation plan. I don't believe this is complex at all. Where does a project like this start? I think you have to go and survey all the files and variables that a CGI GUI or other more user friendly system would display for the user to edit. How would any program know where to find these variables to edit, if you didn't know what package they were in or even which file that they are in? How will you know what priority a package will be on an implementation plan, if you cannot survey its importance in the larger scheme of all packages?

The template system I started to describe here is executed externally from the LEAF image. It does not use the LEAF footprint to work in. The result of running a modified Anaconda installer it to spit out LEAF images. The XML is not stored with the working LEAF Image. If the resulting GUI system is not mature enough to support all desired edits,then the floppy image can still be hand edited where support is lacking in the GUI.
http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg06097.html

> So I think there are two camps evolving in this discussion.
“Three sir”. Two camps trying to edit all this information via a web GUI, and the third camp is my proposal. The third camp is a system using Python programming that is hosted on a full featured platform using templates. The Python GUI would allow a person to develop more full featured GUIs, if is not running on the target LEAF platform. This still presumes we are taking about say a 16meg host. In a way the third camp could be likened to a cross compiler.

> XML. That's where I remember this whole idea coming to
> a halt a year or so ago, when somebody suggesting using
> this and I and a couple of other people said, "yikes."

Let's leave XML out of the picture for a moment. What is the goal here? Somehow we want to let users have a GUI to edit their LEAF systems. At the very heart of this system is editing a variable. So as a programmer I want to know what my target or specification is. So I was thinking in a general way of what any resulting system will have to look at? I don't care about CGI, web, forth, C, XML, db or any other _policy_. I want to know what _mechanism_ I need to provide to those other tools so that they can do their job properly. So, here are the attributes of that said variable:

o The variable still has to function is a bash/ash shell script. This attribute defines all other attributes.

o A variable lives in a file.

o A variable's file is located somewhere i.e. there is a path to that file.

o The bash variable can have a comment on the line before the variable for read ability. It would be nice to leave the comments intact so that a person will know what the variable does.

o To simplify the parsing system, bash comments that do not start at the beginning of the line would be ignored.

o A variable is enabled or disabled by putting a #, pound character at the very beginning of the line. An example would be # HOST7 in the network.conf file.

o A bash variable uses an =, equal sign to set its value.

o LEAF uses many different formats to set a value depending on what the variable is used for.

o Most variables will be a bash variable but some variables that a user would want a GUI to set are in files that do not use bash variables. For example, a user would want to set the values in the /etc/host file. A bash function somewhere would have to be created to generated these types of files. (I know this program exists for /etc/host, but I am just being through here.)

o Survey the LEAF variables values in order to come up with a distinct list of value formats. What algorithms must be defined to support these value formats?
o variable_name=simple_value
o variable_name=space_seperated_values_in_quotes
o variable_name value valueN (/etc/host file)
o blah blah blah until all variation is accounted for.

o Define a word to describe these value formats: ok how about “type”.

o Name the types of variables so that a parsing algorithm can be designed and associated with the named variable. Mirroring the list above:
o “simple” variable_name=simple_value
o “space” variable_name=space_seperated_values_in_quotes
o “space_no_equal” variable_name value valueN (/etc/host file)
o ...

o Represent the above attributes in a sample database:
<Variable Name="myvar" Type="simple" Enabled=”no”>
<comment>this var does that</comment>
<value>1234</value>
</Variable>

o In this example, how would the “simple” algorithm represent this case?
# this var does that
# myvar=1234

o How could I load this sample database?
> > :'a,'b s/^\(.*\)\(=\)\(.*\)$/<Variable Name="\1" Type="simple">^M
> > <comment><\/comment>^M <value>\3<\/value>^M<\/Variable>/

o How could the target file be modified to make inserting the list of variables from a database?
o Either define a region for all variables to be dumped between in the files that require editing. The LEAF distribution configuration files would be modified to have this kind of target in them as an example.
# BEGIN GUI CONFIGURATION VARS
# END GUI CONFIGURATION VARS
o or dump them into a file that is destroyed each time the GUI modifies the values. This would be a simple approach from a programming prospective. This is much like the /etc/host file is built from the network.conf file. The file would be sourced by a shell script. It may be easier to have several of these sourcable files created instead of one giant file.
o or have a template of how you want the sourced file to look. This file would be edited and put in place to be sourced after it is edited by the GUI.

o If this GUI editing system is to be reused across all LEAF distributions, how would these distributions have to change in order to reuse the code?
o Use variables in lrp.conf.
o Use case statements in shared packages that draw on the variables found in lrp.conf.
o These variables in lrp.conf may or may not be in the configuration system. For example bering only uses the Shorewall firewall. This would variable would not be edited by the GUI editing system.

o Would you use XML on the LEAF distribution, if the GUI editing was placed on the firewall disk? Probably not because of space consumption on floppy disk images.

o Would you use XML on a cross compile type system? Probably because the XML file could be viewed and edited by hand. The XML “database” would _not_ reside on the LEAF disk. You would miss the point of my posts if you did not understand that I proposed modifying a system like Red Hat's Anaconda installer to use XML. The saved state of a configured system would be stored in one resulting XML files. Other supporting XML files would provide direction to create the configuration. The modified Anaconda GUI installer would create usable diskettes. The usable diskettes could still be hand edited, if required.
> XML. That's where I remember this whole idea coming to
> a halt a year or so ago, when somebody suggesting using
> this and I and a couple of other people said, "yikes."
The yikes would only be in the modified installer not the LEAF distribution. The GUI cross compiler system is a means to the end of having a working LEAF system.

> Ok, you get the sed award of the month. But seriously, would you
> please comment on the deficiencies of something like this:

1.) I believe you only show me the end result.

2.) The weblet package contains simple variables. This would work but it does not cover all the cases.

3.) If the file has to be hand edited for some reason, or say, you are the maintainer of weblet and leave the project, the file in this state does not leave me information as to what each variable means. Ahem, not that the weblet configuration file is that well documented to begin with.

4.) If I look at this variable from the desired result of having a GUI editing the WRN_FW variable, how do I know which parsing algorithm to apply to WRN_FW? Wouldn't you agree that knowing the “type” of variable that a GUI is going to operate on is very important for the successful operation of the GUI's purpose? By “type” I mean a target or a type of data passed into a parsing algorithm.

5.) Yes it is sourcable. It has to be so that bash scripts can use the variable.

6.) Yes I would agree that “using sourcable straight text config files are a good system”.

7.) I don't believe you have given us enough “glue” to get to the place that this sample represents.

>
> #[weblet]
> #:DEPENDENCIES="root etc"
> #:DESCRIPTION="A shell based httpd for gathering LEAF statistics"
> #:PKGLIST="/etc/weblet.conf /etc/www /www /bin/weblet"
> WRN_FW=5
<snip>
>
> It's sourcable but still contains the glue. Would you
> agree that using sourcable straight text config files
> is a good system still used by Makefiles?

Whatever “policy” is used to implement a GUI editing system, I believe I have at least described some of the “mechanisms” behind the “pig with lipstick” i.e. GUI. Hopefully, these thoughts will help chart a course for a GUI front end.

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