On Fri, 7 Aug 1998, Greg A. Woods wrote:

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

This is not at all the case. /etc/dumpdates is *specifically*
designed to be human readable and editable. From the manpage:

    The format of /etc/dumpdates is readable by people....The file
    /etc/dumpdates may be edited to change any of the fields, if
    necessary.

/etc/skeys is similar; you probably wouldn't get very far
hand-calculating and changing some of the fields, but you can
certainly change others and delete lines by hand without a problem.

In other areas, .ssh/known_hosts is both computer and human-edited.

I maintain that /var is, as hier(7) says, for ``log, temporary,
transient, and spool files.'' The only thing in there that couldn't
be zeroed out without causing a permanent change in the operation
of the system is /var/cron/tabs, which should be in /etc anyway.

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

`Generated information' can be regenerated by the machine itself
after a system reboot.

> For example strictly speaking the files in /var/at/jobs are "generated"
> information.

No. They are not generated from other data, but are new data entered
into the system by a user. You canot erase them, reboot the system,
and recreate them. However, they are transient files that are
expected to go away after a relatively short period of time.

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

Yes. I think they don't belong in var; see above.

> And you'll have lost
> all your log files, which depending on your situation may be critical
> too.

Maybe. But your system will still run.

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

It does me good; then I know when the last dumps were done and I
can tell if the backup tapes I'm looking at are the most recent
ones. Also, it's not something you'd want to lose across a reboot.
But still, I might be persuaded that /etc/dumpdates belongs in
/var, if you want to go that route.

> Well, personally I'd put [the data currently in /var/db/pkg]
> under /usr/pkg/libdata.  It's got no
> business in /usr (i.e. where /usr/pkg is a separate filesystem) on my
> system!  ;-)

I agree.

cjs

Curt Sampson    cjs@portal.ca	   Info at http://www.portal.ca/
Internet Portal Services, Inc.	   Through infinite mist, software reverberates
Vancouver, BC  (604) 257-9400	   In code possess'd of invisible folly.