Date: Thu, 30 Mar 1995 19:19:23 -0800 From: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> To: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu> Cc: freebsd-bugs@freefall.cdrom.com Subject: Re: Changed information for PR misc/278 Message-ID: <10914.796619963@freefall.cdrom.com> In-Reply-To: Your message of "Wed, 29 Mar 95 11:56:56 EST." <9503291656.AA14584@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) Configuration specifications are hierarchical, named along the same > lines as sysctl(8) MIB variables: net.inetd.conf, disk.quotas.enabled, > config.lkm.autoload, passwd.userclass.grimblepritz.expiretime, etc. We can't do something like this! It makes too much sense! :-) > 2) Configuration information is stored in files with multiple > sections, or in directories, or both. So, disk.quotas.enabled might I'd prefer sections in one directory - /lots/of/directory/levels/make/me/crazy. > 3) Database schema information is integrated with the configuration > information, so that for every section (like disk.quotas), there is > also a schema.disk.quotas section, with entries like `entries' and > `entry.description' and `entry.type'. Hmmm. Or you could go with a "property" model where each foo.bar.baz atom had a list of properties. Syntax might be something like: config.lkm.autoload[value] = yes config.lkm.autoload[description_long] = "This option determines whether or not Loadable Kernel Modules (LKMs) are loaded on-demand as needed, without user intervention" config.lkm.autoload[description_short] = "Enable auto-loading of LKMs" config.lkm.autoload[default] = yes And so forth. Then I just query some known atoms for known property values and I get all the information I need. If you want to add field checking, you can even define "mask" and "checkfunc" properties for an arbitrary field. Extend the whole thing as you go along and RIGOROUSLY DOCUMENT the name of every special atom and reasonably generic property name. There you go. > 4) A search path for configuration information, so that site-wide > defaults with local overrides can be established easily. (Default > /etc/config:/usr/share/config.) Most surely. You could even make it: /etc/config:/usr/share/config:$HOME/.sys-config So that even those few user-specific parameters (MANPATH, ldconfig info, etc) can be set with the same scheme. > 5) A central libconfig to make this all work, and user applications to > edit it in a reasonable way. Yep. > No, I don't plan on implementing it. But it would be nice. Damn. And I was liking it, too, until we got to this caveat.. :-) Seriously, this would be a really interesting project - a chance to rip BSD's hoary configuration management screaming out by the roots and replace it with something MUCH nicer. Surely there is some insane person out there? Maybe even two? Come on out, you two! We won't bite! [much] :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10914.796619963>