Subject: Re: /var/cron -> /etc/cron
To: NetBSD-current Users <current-users@netbsd.org>
From: Curt Sampson <cjs@cynic.net>
List: current-users
Date: 04/02/1999 16:18:29
There's been some discussion about things like static, shared /etc
dirs and the consequences of the loss of information in /var. I'd
like to clarify why I feel crontabs should be moved to /etc, and also
along the way what my conceptions of /etc and /var are.

The reasoning behind my method here is a lot to do with being able
to easily do a partial back up a system, and retain useful
functionality. When you think about backups in these terms, there
are essentially three possible results from the loss of a file:

    1. No loss: the file can be restored in its entirety though
    means other than the backup. Typically we're talking about OS
    files that can be restored from the original distribution, such
    as /usr/bin/vi.

    2. Transient loss: we lose something we have now, but that
    doesn't affect future system operation. Examples would be mail
    and log files; we don't change the operation of the system if
    we don't replace these particular mail and log files. I also
    put at(1) jobs into this category, because though we miss a
    future event, we miss only that one particular future event,
    not a general class of them.

    3. Permanent loss: we lose something that, unless replaced,
    will change future system operation. The password and group
    files are examples.

What I'm aiming to do is to get all of the files in category 3, in
which I include cron, into a place that's small and easy to back
up, so you can back up just that and user data and, with some
additional work should a crash occur, get back to a system that's
functioning fairly close to how it was before.

Currently, crontabs are the only thing in /var that are in category
3 above; that is, the only things that, if not restored after a
crash, will make a change in future system functionality. That's
why I want to move them to etc. I want to back up /etc and my user
data, and know that, though I may lose what I was working on at
the time of a crash, when I restore I won't lose future functionality.

Now the main objection that seems to have been brought up here is
that some people want to share /etc among multiple machines. Well,
this is not at all what /etc is designed for, and putting crontabs
there isn't the only thing that will break it. I'm not saying that
you can't share /etc, but /etc is not currently divided on a
shareable/nonsharable basis the way /var and /usr are, and so doing
this sharing requires going through /etc and doing the division
yourself.

In fact, I don't see any point in even attempting this division as
part of the way we distribute NetBSD, becuase the division itself
is site-dependent: files may be machine-specific or shareable
depending on how the site is set up. For example, if you're using
DHCP at your site to configure your hostname and network interfaces
an so on, /etc/rc.conf is probably sharable. On the other hand, if
you're not using DHCP for that at your site, /etc/rc.conf is not
sharable. For other files, such as /etc/ssh_host_key and
/etc/ssh_random_seed, it's hard to imagine how they could ever be
sharable.

The short of it is: shared vs. non-shared files in /etc have to be
done at the site; we as distributors of NetBSD can't do it. Therefore
compromising something we can make decisions on (long-term vs.
transient information) for something we can't is not a good decision.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org