>> Matthew Jacob said:
>> >Fair enough. However, as the number of computers running in the
>> >world that require lights out sustainable operation increases,
>> >unless we clone you, I predict that even you will beg for this
>> >property within five years.

Hmm, not sure about that.  I find a central configs tree (see 
http://www.quick.com.au/FreeWare/configs.html) handles 80+
"lights out sustainable operation" machines quite nicely, 
despite the fact that they run different os's, releases and hardware. 
I try to avoid having anything to do with most of them - I 
personally manage only about 40 or so (ok might be more), but all
run configs which I've setup "in the tree", so most can be re-built
at short notice by a novice.

In the above situation I suspect a "registry" (of the M$ flavour anyway) 
would seriously increase our problems.

Paul Evans writes:
>I'm picturing a method where a specfic file is assocated with a specifc 
>type (hence a specfic manager), a user mode agent actully verifys and logs 
>all changes before they're saved to disk.

Yes, this sort of thing is a good idea, though you don't always need to 
involve the kernel.  I use named(8) as the primary tool to do regression
testing of DNS changes (via CVS pre-commit checks).  See 
http://www.quick.com.au/sjg/dns.html

> "/etc/hosts is a host_file and contains 3 three alphanumerics per line, 
>an IP, a host and an FQDN. The # comment character is valid."

Make that "at least 3 alphanumerics per line" :-) otherwise it will
break a lot of systems - loghost being the obvious example.

>I'd like an opnion on this as I think it's a good framework for providing 
>both an enhanced configuration mechinism, HSM, and an ACL mechinism.

It sounds cool, but as I mentioned you can already do this sort of 
thing using CVS and pre-commit checks.  The trick is to not do the changes 
to the working set, that way the real config files can only be updated 
with checked and verified changes.

--sjg