On Wed, 10 Dec 1997, Brian Buhrow wrote:

> 	The idea that history is not associated with text configuration files
> is completely false.  Registries, on the other hand, seem to really have no
> concept of history and change logs unless the application which controls
> them has a notion of history.  We have a number of text files that many
> people edit around here.  We train them all to use RCS judiciously and find
> that we have a good history of who did what and when.  This is one area
> where text files as configuration files shine, in my opinion.

I agree thsat a site that uses RCS enjoys many benifits, but the fact is
most sites don't. Does this mean we should make them? probably not By the 
same token I don't propose to completely change everything that is near 
and dear to our hearts, but I think we can improve upon a configuration 
mechinism that's already good.

Perhaps we simply need a unified configuration file format, and a way 
to make RCS-style version control automagical. This would be a good 
start. The new configuration files could be <exsisting_name>.cfg We could 
then use the new files if present, and the olds ones if not.

I'm concerned about breaking away from the standard way of doing things, 
I frankly wouldn't want to. I think we need a way that does both. (A 
registry mounted on "etc", with the appearance of text files, but with 
low level locking and version control)


> -Brian
> 
> On Dec 9, 10:59pm, Paul Evans wrote:
> } Subject: proposed: changes to "etc" (?)
> } 
> } One of the specific draw backs of UNIX I keep running up against is the
> } difficulties related to configuration across software packages and 
> } different UNIXices. Specficly I'm talking about files in any dir that 
> } ends in "etc"
> } 
> } Having said that, I acknowledgbe there's nothing we can do about other 
> } peoples misguided beliefs (Hello Solaris Dev team are you there?)
> } 
> } I'm not propsing to instigate something the Red Sysadmin book refers to 
> } as a "vendor gratuitous change" But, I think an initive is needed here, 
> } for several reasons:
> } 
> } 	1. difficulties in management due to differnces in format
> } 	2. error prone by nature, i.e. typos
> } 	3. lack of history log
> } 	4. Security concerns (This last to are far ranging)
> } 	5. Program inplementations of parsers are redundant (hence more 
> } 		possible failure points)
> } 
> } From what I can see there are two possible alternitive solutions:
> } 
> } 	1. A user mode configuration library that uses a protected
> } 		binary file. (a *gasp* registry)
> } 
> } 	2. A VFS based solution involving mounting the above to create 
> } 		the illusion of the files in "etc" (as ascii), but with 
> } 		an API for program use.
> } 
> } Just wanted to pitch this out as I suspect it could have a lot to do with 
> } the proposed capabilties an HSM or new VFS layers/drivers 
> } 
> } thanks for listening.
> } 
> } --
> } 	Paul Evans  
> } 	paule@martex.gen.oh.us _ pevans@cleindians.com
> } 
> >-- End of excerpt from Paul Evans
> 
> 
> 


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