Subject: Re: proposed: changes to "etc" (?)
To: None <tech-kern@NetBSD.ORG>
From: Paul B Dokas <dokas@cs.umn.edu>
List: tech-kern
Date: 12/10/1997 11:23:35
On Tue, 9 Dec 1997, Paul Evans wrote:
> 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)

Well, I'll try not to get involved in this one.  Personally, I feel that
the current /etc/* files are fine.  Perhaps that's just because I've
never known anything else.  But, I'm open to suggestions.

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

[Let me preface this with the declaimer:  I'm know very little about
 how the kernel implements file systems and I know even less about file
 systems themselves.  Take everything that I'm about to say with a
 lot of salt...]

Now this one is interesting to me.  One thing that I'd love to see is
a well implemented user space filesystem (perhaps just a daemon that
talks to the kernel's VFS layer).  For example, imagine an RCS filesystem
built with a user space filesystem and the RCS commands.  When a file is
opened, the daemon does an 'co -l' on the file.  When the file is closed,
the daemon does a 'ci -u'.  It could probably even be extended to append
version numbers to files ala VMS (IMO this is ugly as hell, but it is
potentially useful in some cases).

In fact, it would be more useful to have a generic user space filesystem
daemon that executes shell scripts to implement the VFS operations.  That
way, we'd have a generic daemon that would be useful for experimenting
with new filesystems without having to muck around in the kernel.  The
FTP filesystem would be pretty trivial to implement with such a daemon.

Yes, this would be slow, insecure and open to all kinds of problems.  But
it would be useful in some very limited cases and for experimentation.


Just rambling on,

Paul
--
Paul Dokas                                            dokas@cs.umn.edu
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."