Hi Eric and List, > How large is the E-Smith (scripts Suite) and what does it need (perl ? )
I dont know how big E-Smith suite is as there are many other things involved. Their system is more complex than described (the files are build gluing toguether files in a directoy and other stuff). One thing is sure, they use Perl. But I'm not saying use E-Smith, just "the concept". LEAF is quite different. > > 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 ;) YES. A naming convention is needed. E-Smith is developed by a single company so the "core" variables are just defined. Others are added as needed by individuals, not allways keeping the needed order. In LEAF some kind of coordination has to be done before starting to build templates. But heck, this is much easier than making a parser understing shorewall files AND freeswan files and ... > 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 ? ) The logic that generates the needed files has to know this. For example, "when updating the firewall rules, build /etc/firewall1 /etc/firewall2 and restart firewall". Also, the template can have some intelligence, like "when finished building this file, execute this command". In our case, is the JAVA client that knows wich files need to be rebuilt after a given change. OR, you could take a easier approach and rebuild all the templates :)) E-Smith does that through "actions", but again they have a lot of hard disk space to waste :)) BTW, how is this done now in LEAF? > 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 ) As I said, templates are optional. If you just install tha new package as is, you will need to modify the needed values by hand, as currently done. At the same time a template could be provided, and in that case new variables have to be introduced in the database. In E-Smith, when the package is installed, it looks for the values in the database, if present, it leaves them as they are, if not present, it adds them to the database and gives them some default values. We could just do so manually if you dont want to complicate the system (space) too much. In that case, a kownfull expert is needed but heck, you are installing a package, this is supposed to be done by an expert :)) > 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 ;)) As we are doing it, only for templates and the database file. They are all text files. About multiplying by 2.25 the /etc directory size (the templates are usually bigger than the real files). As I said, in our case GUI and logic are in the client. The other way, how much space do you need for a parser that understands every config file in the system? > 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. A core variable list is needed. All templates NEED to use this names. A package could be installed without using the template system (involving manual editing of the file). For extensions, we could reach some kind of agreement (coordinator approval, FIFO, etc). For private extensions, such approval is not needed. This kind of consensus is only needed when using the template system. You can still use the old way without too much trouble. BTW, a couple of links discussing the E-Smith system: http://www.e-smith.org/docs/papers/perl-article.html http://www.e-smith.org/docs/papers/templates.html Keep this very interesting thinking guys :)) -- Jaime Nebrera Herrera [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
