Matt Schalit wrote:
The original LRP scripts pretty much just assigned IP's and maybe added some static routes. This is all well and good as far as it goes, but there is fundamentally no way the basic network.conf file concept can be extended to configuring arbitrary packages without some kind of "middleware" to connect the two. By way of a somewhat simplified example for basic networking, ifconfig is the "package" that needs to be configured. The network.conf file is the configuration database (name=value pairs), and the network setup scripts are the "middleware".Ray Olszewski wrote:At 10:13 AM 2/4/03 -0600, Charles Steinkuehler wrote:A few quick points about some of the recent discussion:I'd like to disagree with this. It really does matter. One of the big strengths of the anscestral LRP (Dave Cinege's version, I mean) was the simplicity of its basic network.conf file. As LRP first went to the mountains, then evolved into LEAF, and as LEAF tried harder and harder to incorporate many specialized packages, each with its own config files and syntax, much of this simplicity was lost.
Regarding the config-db format: It really doesn't matter. The files should be human-readable (plain text), with enough structure (probably via filesystem directories and filenames) to be easily navigated, but all access to the database information by the packaging and any configuration system will be through a defined API, allowing the back-end format to change if required. Who knows...future versions might move to a packed binary format with small C or assembly programs for access, to save space and/or gain speed. While initially a lack of tools may require "power-users" to hand-edit database entries, I would generally consider this unsafe and discourage the practice.
Yes there was some amount of simplicity across a LRP release that stemmed from his tight-a## control over it. I guess that was a pretty big benefit. I think part of that simplicity was inherent to the lack of complex networking it could do combined with it's lack of firewall. When Charles built those into his releases, combined with PPPoE and ipchains and all the other new challenges, it made spaghetti at first glance.
This works fine for things like ifconfig/route, and even iptables/ipchains, where the built configuration resides in memory, but it begins to fail when configuration is via a file on the "disk". Using dhcpd as an example, not only does the configuration file have to be intelligently updated if a variable it depends on changes, something has to restart (or HUP or whatever) the daemon to get it to recognize it's config has been updated.
LRP has traditionally dealt with the problem of config files by creating new packages at runtime with updated configuration information, which is a big cause of the "same information replicated in many places" problem. My partial backup scripts were an attempt at extracting just the configuration information, allowing packages to reside on read-only media, but did nothing to address the fundamental probem of multiple copies of the same configuration data. I would like to see something that allows packages to build their configuration files at run-time, based on user-entered configuration data, rather than simply "sweeping the problem under the rug" by brute-force backup of raw configuration files.
I think the best general solution so far has been presented by Chad Carr. A templating system, combined with a configuration database or tree, allows boot-time creation of customized configuration files from standard (unmodified from distribution form) pacakges and localized configuration information. With a standard package <> congifutation API, the configuration system can support "callbacks" or similar, letting a package know when values it depends on have been modified, triggering a rewrite of the configuration file, the restarting of a daemon, or whatever else might be necessary.
Chad Carr wrote:
> 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.
Chad: Any chance you could post your current code, and/or any documentation somewhere for review?
--
Charles Steinkuehler
[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
