> 
> >> 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.
> 

Well, perhaps we just need a unified adminstration "package" a set of
userland adminstration programs that incorporate things like RCS'ing 
files in "etc", with velidity checking, and configuration distribution.

This would certianly go a long way toward solving my qualms about UNIX 
adminstration in general. Yes, I know there are many a third party and 
site specefic script (as evidenced above), but someone has to stand up and 
make it "unified".

Perhaps a contributed "admin" (/usr/admin) distrib set/tree. For a clean 
system like NetBSD that runs on so many platforms, an adminstration 
managing suite would be very nice and easy to make comprehensive.

I'm sure tech-kern isn't the place for this discussion, but I'd like to 
do this. 

So where to start? Who to talk to? help!?

thanks.

--
	Paul Evans  
	paule@martex.gen.oh.us _ pevans@cleindians.com

On Sat, 13 Dec 1997, Simon J. Gerraty wrote:

> 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
> 
>