[ On Fri, August 7, 1998 at 15:58:15 (-0700), Curt Sampson wrote: ]
> Subject: Re: /usr/pkg/{etc,share}; /var/db/pkg
>
> On Sat, 1 Aug 1998, Greg A. Woods wrote:
> 
> > With the exception of /etc/passwd and the related /etc/*.db files, and
> > possibly /etc/aliases.db, no files in /etc/ are edited only by programs
> > (i.e. never edited by humans).  All files in /var are created and/or
> > edited by programs and should probably never be edited by humans.
> 
> You forgot /etc/dumpdates, /etc/skeykeys, and /etc/ssh_random_seed.

Oops!  Yes, /etc/dumpdates is definitely in the wrong place -- it should
be in /var/db.  The other two are from add-on packages and we can blame
either their author's or their pkg/port maintainers, but IMNSHO they
should also be in either /var/db or /var/run, as appropriate.

> I don't find `edited by a human' versus `edited by a program' a
> very useful distinction from a system administration point of view.

Well, you probably should.  If you as an administrator (i.e. *not* as a
systems programmer) edit a non-editable file you'll *likely* get
yourself into more trouble than not and you'll have to change hats to
try and figure out what's going on.

Yes, my tongue is firmly in my cheek here, but I think this should help
get the point across.

I.e. sys-admins shouldn't be "editing" things like /unix and /dev/kmem
live -- that's a task best left reserved for systems programmers.  I as
a systems programmer know what to do (or not do) if I edit non-editable
files, but the average sys-admin cannot be expected to know these things.

> More useful is that /etc contains configuration information necessary
> to the running of the system, and /var contains logfiles and
> generated information.

So, what exactly is the difference between a file edited *only* by a
program (eg. a daemon), and a file containing "generated information"?  ;-)

For example strictly speaking the files in /var/at/jobs are "generated"
information.  Obviously someone who knows what they're doing might try
to edit them, but doing so is *highly* discouraged.  However they are
critical for the "running of the system".

> In other words, if you lose your entire
> disk, you can restore /etc from backup and start with a fresh /var
> created with /etc/mtree, and you'll be fine (except for losing a
> bit of mail and your recent logfile info).

You'll also have lost all your per-user crontabs.  And you'll have lost
all your log files, which depending on your situation may be critical
too.

Note also that if you trash your system and restore it from backups then
/etc/dumpdates sure as heck isn't going to do you any good -- you should
be starting with a fresh level zero after getting things operational.

In the past I've generally had a daily incremental dump of /var and I
generally restore it and then manually clear out any big print jobs,
news batches in the UUCP queue, etc. (i.e. true junk) before bringing
the machine back up to multi-user mode.

> Thus, to my mind, the package install database does not belong in
> /var, since, if lost, you can't uninstall packages and you can't
> regenerate that information.

If you're restoring only /etc from backup then you'll have to re-install
all the packages anyway, thus re-creating your /var/db/pkg contents.

If you're restoring /usr/pkg then you'd damn well better restore /var
too (unless you follow my final suggestion below).

> I'd say it belongs under /usr/pkg, though, not /etc, in order to
> acommodate shared /usr setups.

Well, personally I'd put it under /usr/pkg/libdata.  It's got no
business in /usr (i.e. where /usr/pkg is a separate filesystem) on my
system!  ;-)

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>