Hi, I followed with great interrest the discussion.. My 0,02 euros ( more than 0,02 $ ;-) ) ( forgive my frenchie english..)
I few months ago ( maybe a year) , I faced the task of maintaining a dozen of leaf boxes ( dachstein at that time) with similar config but quite different that the released versions ( pppoe,ez-ipupdate,...) Here is a small explanation of what I did ( I didn't yet upgraded it to bering). My design goals - keep the downloaded packages untouched by my tweakings mainly don't modify linuxrc,... - ease the preparation of a new "leaf " instance only config.cfg must be modified - I have a clear view of what I changed from a released version ( all is in myconfig.lrp) I have a - package called myconfig.lrp - A script (config.cfg) stored on the floppy out of the package containing only val=value lines ( internal net, ezipupdate username and host name,....) in the myconfig.lrp - a script /sbin/unconfigured.sh that gets called after the package extraction and before init - a directory /myconfig /myconfig/templates/<packagename>/*.tpl where package is a the name of the .lrp ( dhcpd, dnscache,ez-ipupd) a flat file called /myconfig/template.conf containing #------- package template destination user group permissions dhcpd dhcpd.conf.tpl /etc/dhcpd.cong root root 777 #----- the template files ( *.tpl) contains template of config files ( dhcpd.conf,...) with tags like ##INTERN_IP## that references the INTERN_IP variable defined in the config.cfg file. the unconfigured.sh gets called by the startup process after everything is has been extracted into the ramdisk and before init. it does: - translate the config file into a sed script that will replace the ##VAR## with the value - for each line in /myconfig/template.conf - if it doesn't find a variable CONFIG_<PackageName>=Yes in the config.cfg, it skips that line - else, it passes the template throught sed using the generated script and (over)write the real config file with the output. - it changed to owner, group and permissions - end for. there also a small script that directly copy files from a directory on the floppy somewhere in the ramdisk ( with a config files ) this is used for files like the ssh keys files, /etc/passwd, ... I think we could extend the idea - make a friendly user interface to the config.cfg file ( web or other) - split the config.cfg in a few files ( like etc/sysconfig in redhat) but we need to centralize the definition of the contents of config.cfg Regards, Etienne PS: I keep seeing fat 8.3 file names, isn't it possible to move to fat32 compiled into the leaf kernels and modify the mount command to use fat32 instead of msdos ,??? ----- Original Message ----- From: "Greg Morgan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 03, 2003 11:44 AM Subject: [leaf-devel] Re: Template system [was Webconfiguration] > 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 > > ------------------------------------------------------- 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
