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.
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? 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. 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. 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. 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). Please, feel free to make any suggestion or ask whatever question you have. Regards. -- Jaime Nebrera - [EMAIL PROTECTED] ------------------------------------------------------- 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
