Re: [leaf-devel] The ideas presented so far...
On Sun, 2003-02-02 at 18:11, Matt Schalit wrote: CONFIG-DB PROPOSALS 1. flat-db 2. api-flat-db 3. api-xml-db 4. api-binary-db 5. template-api-xml-db Everyone, The proposals by Chad and Eric are now in CVS. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ccarr/devel/leaf-cdb/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ericw/configuration/leaf/test/ -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- 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
Re: [leaf-devel] The ideas presented so far...
Chad Carr wrote: May I suggest that the config-db be maintained as a config-tree, with the root at /leaf-cdb (or something shallow like that) and keys may be nested as deeply as needed by creating directory levels. I.e. you could make the key interfaces/eth0/ipaddr like this: echo -n 172.24.8.24 /leaf-cdb/interfaces/eth0/ipaddr I also like the idea of a config-tree, Chad. It's proven itself useful for Linux a la /proc. I wish the config-tree api to have significant lattitude in how it displays the data: a) Something along the lines of a -H argument the way who -Hu prints out column headers. b) The ability to dump var=value pairs to stdout. Would you like to remark any furthur on how a tree is significantly better than a single config-db file and how the tree would store a variable's type information, for instance? Matt. --- 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
Re: [leaf-devel] The ideas presented so far...
On Tue, 2003-02-04 at 14:19, Matt Schalit wrote: Chad Carr wrote: May I suggest that the config-db be maintained as a config-tree, with the root at /leaf-cdb (or something shallow like that) and keys may be nested as deeply as needed by creating directory levels. I.e. you could make the key interfaces/eth0/ipaddr like this: echo -n 172.24.8.24 /leaf-cdb/interfaces/eth0/ipaddr I also like the idea of a config-tree, Chad. It's proven itself useful for Linux a la /proc. I wish the config-tree api to have significant lattitude in how it displays the data: a) Something along the lines of a -H argument the way who -Hu prints out column headers. b) The ability to dump var=value pairs to stdout. That's cool. I am game for anything. It seems that the second way would be most useful for operation, but perhaps the first would be good for display purposes, or something. Would you like to remark any furthur on how a tree is significantly better than a single config-db file and how the tree would store a variable's type information, for instance? The main reason we (at Toshiba) chose a tree is that it allows for the display of complex data structures without the use of any parser. It also allowed us to separate centralized configuration data into separate files that would not wreak havoc with RPM's (we used RedHat at Toshiba) hellish dependency structure and would not require the use of carefully hand-rolled postinstall scripts to modify global configuration files. Not as much of an issue here since packages are not dependent on LEAF, but what the hell. It also allows a package to own (and back up) a piece of the central config-db without fear of it getting overwritten by another package, horked up by another package, deleted by another package, etc. The main part of the system is the templating and trigger system that abstracts the config-db away from the runtime requirements of the packages themselves. It allows any sort of transformation to take place between the config-db and the actual configuration of the running application. As far as type info, there should be none. The storage should be strings (everything in the file is considered part of the value; we may have to consider a proper shell escaping feature in the api) and the caller should determine how he is going to interpret the data. What is an example of needed a real type and what would they be? The hierarchy could handle just about anything, in my opinion, but I don't think type information is really needed. I could be wrong. --- 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
Re: [leaf-devel] The ideas presented so far...
On Monday 03 February 2003 02:41 pm, Matt Schalit wrote: I would suggest letting people develop at will, at their own speed, as has been the history of projects here, and let the better ideas prevail. I feel positively about a roadmap, but don't feel it's absolutely necessary. I *am* glad you and I concur on the three types of ideas being suggested, and that from the discussions so far, the dependancies I listed most likely exist if all ideas are well designed w/others in mind. I definately can't disagree with this, other than sometimes the 'better' idea(s) don't prevail for a variety of reasons. No one will use a program that doesn't exist and this isn't along any further because no roadmap AND code was really ever presented. I am sure one of the main reasons Eric W. presented some code was so _something_ was there to start with. I really don't think he wants to re-write any code more than once or twice. But as some people are already creating a modified weblet admin package as I write this, I figure, let's not say that their project should conform to the others. It's really up to them to decide how many rewrites are worth it as they see the other ideas proceed. I agree, but I would like to see if several of us can agree on a roadmap to follow and break up some of the work. I don't write Java or Jscript, but I can write some functional sh. I prefer to let someone else code where I am deficient and bring the pieces together. I feel this could be done within a month or so with several developers working in pieces that would actually work together. But then again, we are talking about standards here. If we are going to say that the config-db is the only thing that people should customize for their LEAF box, then it's folly to start a weblet-admin program that alters /etc/init.d scripts. Yet if we say that the config-db is untouchable, and that we need to use a groovy api to access it, then it's folly to start a weblet-admin program that doesn't use the api. (Given an api, front-ends don't parse the db. They use the api.) I think it will be as it always has been. People will use what they want. If they don't create a more popular or useful system, it eventually dies due to lack of use/development. It either gets used and/or extended or doesn't. Standards are simply what keeps getting used. The biggest problem IMHO with a flat-db would be the ability to hand-edit the file(s). If no comments or description fields are used it will require a user to locate the variable(s) in the package conf file(s), then edit them in the 'db' file. I think it is a fair trade-off. If an easier configuration method is available (or choice), then you ought to be smart enough to figure out what variables to change if hand-editing. There are atleast 3 people I know of that maintain many Dachstein routers and have already gone to a similar approach. I think the idea is proven. All it needs to move between different variants is compatibility to the core configuration files and packages. So I'd like to see the config-db idea really take shape. I need to know what the format will be. One of these??? name = value namevalue name:value name.value name = value #descript Will we take a poll on whether to have more standards? (in addition to the current package format and libc standards) Will we take a poll on each proposed standard? That could take a while Other than a db format, it really doesn't matter. The libc thing is a matter of which binary tree(s) to use when generating an image. A flat-db can have many columns as desired, you can parse with sed, cut, and other shell-util's by columns/delimiters. Let's use passwd and shadow as a good example. I really don't think Matt and Greg are too far off from each other in the 'preconfig' department. Let's say a XML or Java applet takes the initial configurations for the system (and/or packages). Let's say this configuration is saved to a 'db' text file on a floppy. The user inserts the global CD-ROM which boots and generates a floppy or IDE image from reading the 'db' file on the floppy. Granted this global CD would need to have the capabilities of writing an IDE/CD image or atleast moving it on a harddrive partition, but that is feasible on 650Megs. Considering use of RH-s autodetection to the preconfig, it won't work _unless_ you run it on the LEAF box . I don't believe Perl is a feasible option on the LEAF box for CGI, I don't think so either, but I thought I'd list it as someone suggested it. ;-) especially when Jscript and shell-script are and wouldn't require an interpreter. Just for clarification, is Java being suggested instead of Jscript? My reasoning is determined by the need for an interpreter. Yes Java is being suggest by me. A remote Java app could run on a remote computer that had a Java Virtual Machine (JRE) installed and connect to LEAF via sshd using ssh and scp command api. Nothing
Re: [leaf-devel] The ideas presented so far...
On Mon, 3 Feb 2003 18:57:24 -0600 Lynn Avants [EMAIL PROTECTED] wrote: One of these??? name = value name value name:value name.value name = value #descript I realize of course that I am quite late to this discussion, and oddly more vocal lately than I have been, but it only comes from having done it recently and experienced some of the pitfalls already. May I suggest that the config-db be maintained as a config-tree, with the root at /leaf-cdb (or something shallow like that) and keys may be nested as deeply as needed by creating directory levels. I.e. you could make the key interfaces/eth0/ipaddr like this: echo -n 172.24.8.24 /leaf-cdb/interfaces/eth0/ipaddr This allows a myriad of strategies to be used (by the api) for delivery of complex data that is quite difficult to represent in (and parse from) a single flat file. Parsing becomes basically nil if the api is written well (I am thinking a handful of leaf-cdb-* shell scripts). It also allows packages to drop in default values, and even back them up to their own package, if needed, rather than having them swallowed up by some other global package. Feel free to discard. -- --- Chad Carr [EMAIL PROTECTED] --- msg06119/pgp0.pgp Description: PGP signature
Re: [leaf-devel] The ideas presented so far...
I thought I should add a couple of comments. There's a lot of this discussion that's basically way beyond me, but welll... :) On Mon, Feb 03, 2003 at 06:57:24PM -0600, Lynn Avants wrote: The biggest problem IMHO with a flat-db would be the ability to hand-edit the file(s). If no comments or description fields are used it will require a user to locate the variable(s) in the package conf file(s), then edit them in the 'db' file. I may be wrong, but I don't see any reason why comments would be banned from the flat-db files. I mean it's not that much code needed to recognize a # at the beginning of a line...? So as long as we don't complicate matters by allowing in-line comments, it should be fine? --- I like Chad's directory structure idea --- And finally; Given a template system, in which the actual config files are built by reading values from some sort of db and merging those with template data, consider this: Would it make sense to have some sort of 'repeatable section' mechanism? The example I'm thinking of is the interfaces section of dachsteins network.conf, in which there could be *some* variation in the number of instances, between individual LEAF boxes... Could be accomplished by use of tag/tag pairs... Just 0.02 $CURRENCY regards, Jon Clausen --- 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
[leaf-devel] The ideas presented so far...
Here's my attempt to summarize the project ideas offered recently, because I feel there are enough that some good ones might get lost: If I left any out, please add them in!! There are 3 general projects: I) central config-db II) package system III) gui admin program I can be done alone, even with the current lrcfg and lrpkg. II is dependant on I being done. III is dependant on II. Can we concur on the above? I think it's important to get our foundation in order. I think the dependancies are more logical than hard and fast rules. I don't want to have to rewrite a gui admin program if a new package system comes out a month later. MY SUMMARY OF THE IDEAS SO FAR = CONFIG-DB PROPOSALS 1. flat-db 2. api-flat-db 3. api-xml-db 4. api-binary-db 5. template-api-xml-db PACKAGE SYSTEM PROPOSALS [all are .tgz and FAT based == 8.3 filenames] 1. extend apkg to use one of the db ideas. 2. rewrite the package system from scratch to use one of the db ideas. 3. make packages automatically restart via trigger, when necessary 4. make remotely loadable packages via http, ftp, tftp, scp, etc. 5. make package system load all packages it finds, no more list. ADMIN PROGRAM PROPOSALS [all pre-config ideas utilize a master cdrom of utils/modules/packages/LEAF variants] [all post-config idea might use sshd on LEAF to facilitate scp and an ssh tunnel] 1. pre-config done on seperate OS using local Java app. 2. pre-config done on seperate OS using local Python app. 3. pre-config done on seperate OS using local Perl/www/cgi apps. 4. pre-config done on seperate OS via server based www/cgi apps. 5. pre-config done on LEAF box using Red-Hat dynamic hardware inspection app. 5. pre-config be upgrade capable (can clone a running LEAF) 5. post-config done on separate OS via LEAF based perl/weblet/cgi apps. 6. post-config done on separate OS via local based perl/www/cgi apps. 7. post-config done on separate OS via local Java app. 8. post-config done on separate OS via local Python app. 9. post-config done on LEAF using terminal based ascii gui, like Oxygen. 10. Make pre-config and post-config into one app. Well I'd appreciate it if you'd add to the laundry list those ideas that I failed to include, not out of malice, but from lack of understanding their scope. Best, Matthew --- 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
Re: [leaf-devel] The ideas presented so far...
On Sunday 02 February 2003 08:11 pm, Matt Schalit wrote: snip I) central config-db II) package system III) gui admin program I can be done alone, even with the current lrcfg and lrpkg. II is dependant on I being done. III is dependant on II. Can we concur on the above? I think it's important to get our foundation in order. I think the dependancies are more logical than hard and fast rules. I don't want to have to rewrite a gui admin program if a new package system comes out a month later. That looks correct to me. A roadmap is absolutely necessary. snip with other submitted material 5. post-config done on separate OS via LEAF based perl/weblet/cgi apps. 6. post-config done on separate OS via local based perl/www/cgi apps. 7. post-config done on separate OS via local Java app. 8. post-config done on separate OS via local Python app. 9. post-config done on LEAF using terminal based ascii gui, like Oxygen. 10. Make pre-config and post-config into one app. I don't believe Perl is a feasible option on the LEAF box for CGI, especially when Jscript and shell-script are and wouldn't require an interpreter. Just for clarification, is Java being suggested instead of Jscript? My reasoning is determined by the need for an interpreter. Added options: 5a) post-config done on separate OS via LEAF based shell-script/www/cgi. 5b) post-config done on separate OS via LEAF based Jscript/www/cgi. 9a) post-config done on LEAF using script. 9b) post-config done on LEAF using editor (hand). Thank-you for putting this together Matt, I would imagine it can consolidate some discussion. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- 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
