On Fri, 2003-02-07 at 08:06, Lynn Avants wrote: > On Friday 07 February 2003 07:23 am, Chad Carr wrote: > > On Fri, 2003-02-07 at 00:30, Erich Titl wrote: > > > > For a single key=value file there is one already in Bering and I believe > > > in Dachstein too, lrp.conf , why not use it? It only contains parameters > > > we need to use anyway. > > > If a hierarchical setup is chosen the directory idea is simple and easy > > > to parse, but more difficult for Joe Average to read and find things in. > > > Just refer to the /proc directory structure. > > This is my question as well with a different example, other than proc > is quite well known and used among experienced users, where a > leaf-db wouldn't be.
I see your point here. I am assuming that Joe Average's interface of choice is the web interface. If Joe wants to move beyond the capabilities granted by the web interface, we would have a first-tier document for him to read that explains the tight set of tools used and the layout of the hierarchy. > Now I'm going through this right now (as promised) and it is quite an > intriguing proposal. It stills somewhat avoids the question I am asking > though. When you first tried LEAF and possibly found you *wanted* or > *needed* to manually change an option, you used tools you were familiar > with or well documented via Google/whatever. Absoluely no one is going > to have a clue to use './leaf-cdb set tree X' or './leaf-cdb get tree X' > unless this is clearly explained before downloading an image/package and > documented when logging on for the first-time. David D did an excellent job > of doing exactly this on the later releases of Oxygen. I'm definately not > attempting to say _not_ to use this style of db, but rather attempting to > explain what short-comings that I see in the implementation. Again, I believe that the system should be designed so that Joe Average doesn't ever log in. If he chooses to go beyond, the doc picks up. > Two-line explanation: A flat-db is easily traceable and intuitive to somewhat > experienced *NIX users, a tree db is not easily either. For concession, use > of a tree db will _mandate_ clear, complete, and advertised documentation > for all users, developers, and package maintainers. Yes. I think that is a desire of this new sub-project. It does cut down on freedom and make the development of packages more difficult, but the development only needs to be done once (and whenever the configuration file format changes) and by the guy who knows best what should happen (the package maintainer). The benefit of getting a pluggable web configuration interface seems to me to outweigh the difficulty. > > A properly designed api makes it easy to get and set "name=value pairs" > > without actually having them in the same file. The strength in this > > approach is that an individual package "owns" the data in the files that > > map to its name=value pairs, and can be responsible for backup them up, > > then putting the file back into place on the next boot. The file is > > "assembled" rather than edited. > > Who owns shared information between packages? There are several people > that have already hacked single file and/or single package configuration. > If the package 'owns' and 'stores' it's own db values, how is replacing > something like a dhcp client going to 'drag-n-drop' w/o requiring it to set/ > configure itself. With the information stored in an configuration > file/package, you could reasonably assume that the same variables/values > are universally used between the similar programs. The system probably owns the core configuration data. Data that is shared (for example) between initrd.lrp, root.lrp, etc.lrp, modules.lrp could be owned by leaf.lrp (this is the core set of packages under Bering that it is basically impossible to run a system without). All other data may be owned by its respective package but can possibly be pushed into leaf.lrp if the package doesn't claim it. I suppose it doesn't matter technically who owns it as long as the package is not trying to be transported _after_ being backed up. > > > Another thought, maybe too late, I was wondering how a package like > > > shorewall could take its parameters from a pure key=value db. The keys > > > would have to be very elaborate then and such a set up might be more > > > complicated to understand than the current one. Tom probably had good > > > reasons to split his configuration files. > > > > The interaction between the config-db and the trigger/templating system > > is a pure abstraction. The name=value pairs on the output of the api > > become the input (and symbol table) for the template. With a properly > > designed templating system _any_ type or number of files can be > > generated, data can be morphed or manipulated after it leaves the > > config-db (i.e. netmask could be transformed to netbits or vice-versa). > > The work flow is: > > > > - change the config-db using the api > > - fire a predefined (and documented) trigger saying you have done so > > > > Then the trigger "handlers" take over. Any package that is interested > > in the occurance of a certain trigger installs a handler (drops a script > > into the corresponding directory) to do what he needs to have done when > > that trigger is fired. The trigger mechanism is likely just debian > > run-parts or the like; very simple. The general workflow for a trigger > > handler: > > > > - read the config-db or portion of the config-db that he is interested > > in using the api > > - use that as a symbol table for any number of templating operations > > that he needs to execute to transform his operating files > > - atomically attempt to apply the changes, restart his service or daemon > > or otherwise put the new values into action > > - check to see if it worked > > - roll back to the old values if it didn't (this will take some > > additional work) > > > Or put simply, set a 'dirty-flag' for every service available. This could be > done regardless of the db-style. This is more than a dirty flag. It is an anonymous dispatching system that allows independent but interrelated processes to communicate to each other with responders not caring who triggered the event and triggerers(?) not having to know who must be notified that something has happened. Very good for extensibility. The tough part is error transmission and recovery, but we can talk about that later. > > Your example of shorewall is very apropos. Shorewall will need to know > > about nearly every networking change on the box, as well as changes to > > it's own configuration. If a new interface is added, it must regenerate > > its interfaces file and restart. If someone adds a rule, it must > > regenerate its rules or policy files. > > > > It is up to the package itself (or the folks who are trying to integrate > > it with the web interface, I suppose) to interpret the event and make > > the necessary changes to the configuration files. > > > > The reason this must be is that if a web interface knows the results of > > its actions, it must necessarily be bound to the implementation, > > _inextricably_. Then if someone comes along and creates a fancy new way > > to configure interfaces at boot time or a new, even tinier dhcp server, > > the web interface would have to know about it to get it configured. > > This is bad. I think. If there is a well designed api and strong > > templating mechanism combined with a well-documented trigger interface, > > the new package can simply drop in a trigger handler that reads the same > > values that the old package did, generate its new configuration files > > and do whatever else needs to be done. > > > Ok, so now we're suggesting making the packages smarter. This follows > the logic since only the package can assume its use. It's a big step moving > responsibility from the front-end, back-end, and db-system to individual > packages. Logical or not, is this what we want to propose???? The voice of much experience: if you try to put control in the hands of the front-end, back-end and db-system you will have nothing but heartache during the maintenance phase of the project. As the software changes and falls out of sync with the pieces that control it, things will break, you will have a very hard time maintaining functionality, let alone adding functionality. The front-end will fall into disuse and before you know it, users are logging in again. Putting the control in the hands of the package maintainer allows him to decide whether he wants web configuration, then provides that if he wishes. leaf.lrp simply provides a simple and extensible framework for him to build on. > > This adds strength to the LEAF framework; a base from which to proceed > > and a consistency for package maintainers to build upon. The key is to > > build the complexity into the core components so that packages and > > features laid on top become ever more trivial to implement. If making a > > new package for Bering means writing a whole new subsection to a web > > interface (which some folks don't know how to do) they will be less > > likely to approach the task. If they just have to write a shell script > > against a simple and well-documented framework (and the web interface > > will just _work_), the boundary is lowered to playing the game > > correctly. > > So what is suggested is similar to integrating Linuxconf and RPM (or apt and > dpkg) and forcing the reponsibility to the package itself. This is quite > possible if we are willing to create a lot of 'smart' packages. If the package desires no web (or other new-style, such as snmp) interface, it need not change what it is doing. It can allow configuration only by login and all is kosher. No management system or package will touch his goings on. This is as it should be. Packages can be moved to the new way when they feel lonely... > Thanks for the thorough explaination, I'm going through the rest of your > code now. Quite an intriguing proposal to say the least. Thanks very much for taking the time to go through the code. I know how much time it takes to go through someone else's hare-brained schemes and very much value your input on mine. I hope that the code I have provided is enough to give the general sense. I am working on more as we speak (leaf-tmpl is next). -- ----------------------------------------------------------------------- Chad Carr [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
