Hello Jaime , List > Hi all, > > I have been following the discussion about the need for a "graphical" system > to configure LEAF systems. As it has been already commented, one of the > daunting tasks is to be able to work through the easy system and keep the > power of direct editing.
Agreed > > We faced that question some time ago. We planned for some kind of graphical > config system for Lince (Bering derivate) and that was the hardest decission > to make. How to make the config easy and pretty? How to maintain the power of > the /etc files? > > We use E-Smith also and love its conceptual design. For those that have > never heard about it I'm going to try to explain it a bit. ESSG gives the > admin an easy and very integrated "control pannel" or web system trough you > can configure most of the features of the server. This way, any non expert > can configure and use the system with ease. At the same time, it gives you > acces to the /etc files, so an expert or VAR can make the modifications that > are needed. How is this done? How large is the E-Smith (scripts Suite) and what does it need (perl ? ) > > FIRST, you have a flat text file that works asa database and keeps > information of all the parameters of the system. Say WAN_IP=62.25.25.10 > Local_IP=192.168.100.1 VPN=On etc etc etc. At the same time it uses a bunch > of templates that just look like standard config files BUT with two big > differences: when you want to use the local IP you dont place it directly but > "call" it like a variable, like <Local_IP> bla bla bla, and has some logic > embedded (for, if, ...). That way, if you change the Local_IP value you dont > need to go and change it all around, but just in the database and you have > some intelligence. To be able to use the hostname in different config files there should be a standardized way to name things This becomes a problem as soon as several people work on the concept ;) > > SECOND, the real /etc files (the only kind of files the daemos really > understand) are NEVER touched. You build such files merging the corresponding > template with the needed values in the database. So, if you want to write > /etc/samba.conf you have to execute something like "build /etc/samba.conf > /templates/samba.conf" actually is more complicated than that but you get the > idea. > That is completely understood and a kind of the way I wanted to do it too, but what happens if we change for example the Hostname. How does the "central programm" knows what "realfiles " have to be updated and restarted ( are all template files investigated if the $HOSTNAME is anywhere in the programm ? ) > THIRD, through the web or easy system you NEVER touch the /etc files nor > templates, just the database values. So you change the needed values, and > when done execute the corresponding "build" and "restart" orders. > > FORTH, when needed, the expert guy just goes to the template file, modifies > it and the build the real file. If he edits directly the real file, the next > time a build order is executed the changes will be lost by the system. So he > just modifies the template as needed and builds. Modifying a template is > quite easy as it looks exactly like a real configuration file but with the > values not "hardcoded". If needed, he can add new variables to the database > file and use them. But if someone else uses this package, he cannot use this variables as they are not defined in his database ( or am I missing something here ) > LAST, some work is needed to prepare the different templates, but much > easier than parsing the real configuration files. > > This system is very elegant and can be exploded in some ways. For example, > my brother is bulding such a system as a JAVA application for LINCE as his > end of college project (in Spain to get an engineering title you need to do > project). All the intelligence and "graphical" system will run in the client, > but you could do so in any other language and embedded it the system (in a > webpage for example). > > Also, XML would be of great value in such a system, but my brother could not > figure exactly how the Java XML classes worked and decided to go in a more > direct way. > > What do you think? I believe this conceptual design could solve a lot of > problems to the Webconfigurator guys (independence of LEAF variant, not > needed to parse very different files). Basically I like the Idea, Some Questions and remarks I have are ; 1. What size is additional needed ? The reason I choose for direct parsing was the reduction in package size and ( I didn't succeed in easily writing back a file with placeholders ;)) 2. Adding an additional package will make the need for dynamical extending the central database. for example with an additional file that extend the vars in the database. ( otherwise even someone with a small floppy system should have all kinds of var that are only used with some special files. > Please, feel free to make any suggestion or ask whatever question you have. > > Regards. > > -- > Jaime Nebrera - [EMAIL PROTECTED] > Regards Eric Wolzak member of the bering crew ------------------------------------------------------- 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
