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

[Greg Morgan]

Back in March 18, 2002 I looked at a different approach from the weblet configuration. The date reflects the date of a Visio diagram I drew of my concept. (It was version four of Visio before Microsoft bought them and I wasn't dual booting into Linux at home at the time.) Anyhow, the concept took me on an odyssey in the last year. The odyssey started when I said what if I keep all the .lrp packaging the same. After all there is a known algorithm on how to open and edit one of these archives. All that is required is a place to uncompress and untar the file. Moreover, creating an ISO or floppy image is a known algorithm, etc. I also have been fascinated by Red Hat's Anaconda installer. One of the things that the LEAF project has done is to make me aware of how many applications use this whole Linux on a boot diskette idea. So I spent some time musing on combining the use of a modified Anaconda installer that would image a diskette, ISO, or other media. Part of the odyssey included exploring Anaconda; learning all about the cdrecord tools; learning about LRP packages; and studying a book on Python GUI programming, etc. (I want to do a brain dump of the cd stuff, when time permits.) The final concept was to leave each LEAF distribution the same and configure them from a separate boot up configuration system. Now you could even run this sort of a system in a User Mode Linux system.

Here's some of the benefits that I thought that could be achieved with this design. I decided to call this design the Gila Monster installer keeping in line with the snake theme of the Python language used to program Anaconda, and Arizona, USA where I live:

o It uses the first law of reverse engineering, "Always steal the best." Its not really stealing because of open source but the Red Hat Anaconda installer has to determine all the hardware issues that Ray Olszewski spoke of. However, Anaconda includes kudzu, the hardware detection tool. How many support emails have been generated because a user cannot determine their network cards? kudzu could detect these and other hardware devices.

o Anaconda includes a character version of the install that is executed on low memory platforms like LEAF.

o The command line supports passing in command line parameters. For super low memory situations, a command could be passed to the modified system so that just the hardware information is collected. This information could be saved on a diskette. An upscale platform could read in the diskette and run the full GUI configuration tools that could be built to image a working LEAF system.

o Since the configuration files where designed using XML, the Simple API for XML, or SAX parser would be used because it supports lower memory situations better than the Document Object Model, or DOM parser.

o Red Hat already has lots of configuration screens created. For example a user could use the existing Anaconda time configuration screen to set their time zone. The files found at http://leaf.sourceforge.net/devel/cstein/files/kernels/zoneinfo/ are already on the Anaconda installer.

o The algorithm that putty uses to generate ssh keys could be duplicated in a new screen.

o The cdrecord tools could be used to create either ISOs or burn a CD version of a firewall. After all kudzu detects CD-RW and DVD-RW drives for Red Hat. If the installer was executed from a platform with a CD-RW drive, then say, a Dachstein CD could burned.

o GUI tools could be used to drag and drop a LEAF to LEAF distributed office configuration. This may simply the issue of two related, say, Real Estate offices hooking their networks works together in a ssh, stunnel, CIPE, or ipsec tunnel.

o Once configured, spare diskettes could be created by using the existing Anaconda kick start mechanism.

o The biggest advantage is that you would not have to squeeze down into a weblet footprint. A Gila Monster ISO would be created. It would have all Python programs, etc. A user would burn the Gila Monster ISO. Then boot up the system. Instead of configuring a Red Hat system, the installer would configure LEAF distributions. The XML configuration file could be stored on a floppy. However, if a CD-RW disk is used it may be saved on the installer CD?

o A user would not have to download all the files to run Python, etc. The whole system would be on one ISO that the user would burn with their favorite burner software. If the user prefers MS Windows, then the user would boot the system from CD. Once a working LEAF configuration was created, the user would reboot into their normal workstation mode.

So being that my day job includes application design using Oracle databases, I spent some time coming up with an initial normalization of the LEAF firewalls. The ideas I settled on were:

o A user may have one or more ISP. An ISP would include information about a corporate LAN should LEAF be used as a router in an organization.

o A user may have one or more hardware platforms that will be used to host LEAF. These could include one or more descriptions of the same PC, but with fantasy hardware added like Disk On Module, CD-ROMs, Zip drives, etc.

o A user may have one or more root passwords or other users that he would like to use. This needs to be normalized away from the other files because the other files could be sent to the mailing list for trouble shooting. This file would also contain other security information that would require configuration such as parts of the SSH keys.

o Details of each LEAF distributions has known attributes. All of the frequently configured attributes could be collected in object representing that distribution. As the design system matured additional features that were coded by hand could be added to this file. Supporting GUI configuration tools could be created to address these variations.

o Likewise the firewalls that run on the distributions has known attributes. These could be configured just like the distributions attributes.

o Finally, all these other entities or normalized tables would be brought together in a user configuration file. A pointer to the ISP, security information, platform, LEAF distribution, and firewall would be kept here. A GUI would be developed to allow a person to point an click to configure a Dachstein release. Perhaps they want to try Bering. Select all the other items and choose Bering.

I think the only challenge with either the weblet configuration system or this concept is the amount of work involved to understand the problem and come up with a working system. So far I am just at the understanding phase. Although a beginning GilaMonster.xml file is presented below. It is a good thing that family got in the way of making more progress on this design. But it was a bad thing that work wasn't completed because it is an interesting problem.

Here's a picture of how the files work together. I created them as one file with the beginning <GilaMonster> tag. However, they need to be split apart for support reasons.


+--------------------+ +--------------------+
| | | |
| GMUserConfig |<--------| GMUserPlatformList |
| |<---+ | |
+--------------------+ | +--------------------+
^ |
| |
+--------------------+ | +--------------------+
| | | | |
| GMUserSecurity | +----| GMUserISP |
| | | |
+--------------------+ +--------------------+


+--------------------+
| |
| GMLEAF |
| |
+--------------------+


+--------------------+
| |
| GMUserFirewalls |
| |
+--------------------+

Notes from 3/18/2002:

GMUserConfig - Contains all the information to complete a LEAF install. It references all the other major elements starting with GM. The other elements contain a combination of both elements and attributes.

GMUserSecurity - Contains just the root password and other security information. One password may be used for several configurations. Secure Shell encryption Keys and other secure tunnel information could also be stored here in some sort of key safe.

GMUserPlatformList - Contains all the hardware information that will be used to host a LEAF configuration. For example information pertaining to processor, Ethernet cards and storage media would be kept here. Multiple GMUserConfigs could reference any platform described here.

GMUserISP - Contains all the ISP information. This includes the type of ISP--cable, DSL, Dialup--and static, dynamic IP information, or PPP script to connect to the ISP. A user could have multiple ISPs. However, all the ISP information that needs to be configured once would live here. Mutilple GMUserConfigs could then reference the same ISP information.

GMLEAF - Contains all the default configuration data for each distribution. All the IP address, and other variables that are edited in the current LEAF method of configuring a distribution would be stored here.

GMLEAFFirewalls - Contains all the default firewall configuration data for each firewall distribution. Like GMLEAF all the firewall information would have to be collected.

Being a good boy I typed this collection of thoughts in AbiWord first before pasting it into Mozilla. ;-)

Greg Morgan

<GilaMonster>
<GMUserConfig>
<GPLcomment>GPL License and Copyright</GPLcomment>
<config name="" platformID="" LEAFID="" firewallID="" userispID=""
securityID="" sslkeyID="" description="">
</config>
</GMUserConfig>

<GMUserSecurity>
<GPLcomment>GPL License and Copyright</GPLcomment>
<security name="" securityID="" description="">
<user ID="root" password="" MD5=""/>
<user ID="oxyuser" password="" MD5=""/>
</security>
<ssl name="" sslkeyID="" description=" this is the beginning of a key safe">
</ssl>
</GMUserSecurity>

<GMUserPlatformList>
<GPLcomment>GPL License and Copyright</GPLcomment>
<Platform name="" PlatformID="" memorysize="" description="">
<device name="ie/dev/fd0" type="floppy"</device>
</Platform>
</GMUserPlatformList>

<GMUserISP>
<GPLcomment>GPL License and Copyright i.e. Information about ISP
that can be used in all configurations. The list would include
DNS servers, Static or Dynamic IPs, Gateways. Note that a user
_May_ have several ISP accounts. Moreover, once defined the account
_May_ be used in multiple configurations. The user could be trying
several distributions for example. </GPLcomment>
<ISP name="" userispID="" description="">
</ISP>
</GMUserISP>

<GMLEAF>
<GPLcomment>GPL License and Copyright i.e. has all the parameters
to a stock distribution</GPLcomment>
<LEAF name="Bering" LEAFID="BRNG" type="LEAF" description="">
</LEAF>
<LEAF name="Dachstien" LEAFID="DS" type="LEAF" description="">
</LEAF>
<LEAF name="Misquito" LEAFID="MQ" type="affiliate" description="">
</LEAF>
<LEAF name="Oxygen" LEAFID="OXY" type="LEAF" description="">
</LEAF>
<LEAF name="Packet Filter" LEAFID="PF" type="LEAF" description="">
</LEAF>
<LEAF name="Wireless-Gateway-On-A-Floppy" LEAFID="WRP" type="LEAF" description="">
</LEAF>
</GMLEAF>

<GMLEAFFirewalls>
<GPLcomment>GPL License and Copyright</GPLcomment>
<firewall name="Seattle Firewall" firewallID="seawall" description="">
</firewall>
<firewall name="Shoreline FireWall" firewallID="shorewall" description="">
</firewall>
<firewall name="The rfc Linux Firewall" firewallID="rfc" description="">
</firewall>
<firewall name="Echowall" firewallID="ew" description="">
</firewall>
<firewall name="Mountian and Stein releases" firewallID="ms" description="">
</firewall>
</GMLEAFFirewalls>
</GilaMonster>



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