Subject: Re: /var/cron -> /etc/cron
To: Current NetBSD users <firstname.lastname@example.org>
From: Gandhi woulda smacked you <email@example.com>
Date: 04/07/1999 19:40:51
On Wed, 7 Apr 1999, David Maxwell wrote:
# On Wed, Apr 07, 1999 at 02:55:54PM -0700, Gandhi woulda smacked you wrote:
# > # hier(7) says
# > # /var/ multi-purpose log, temporary, transient, and spool files
# > # Which doesn't fit semi-permanent user-configuration files.
# I've said before that my arguement has nothing to do with not backing
# up /var. I certainly feel the need to backup mailboxes, and would feel
# the need to backup things like print jobs if I had enough of them.
Then, to put it simply, hier(7) needs some adjusting.
# I don't have a /var/pkg. What's in yours?
D'oh!! I meant "/var/db/pkg".
# Mine are in /etc, it's config data.
I figured it has the potential to grow and is not needed at boot
time, so it went to /var. (just remembered why I did that)
# > .../var/yp?
# I don't use/care about yp, but I suspect it's config data.
...and so would belong in /etc, according to your definition.
Not acceptable, especially for an embedded system.
# By semi-permanent, I mean that they are not static, like /sbin/init,
# but are not constantly changing, like /var/spool/mqueue. I find
# crontabs to be very much like password file entries. (in terms
# of comparing properties)
Still bogus, IMO.
# > Could we please leave /var/cron there?
# Here's my question. If a non-Unix person went looking for cron's
# config files, what would make him think "/var! That's where it'll
# be!" ?
A non-unix person wouldn't know where the hell to find the kernel and
probably wouldn't understand what /var was for in the first place.
A minor point in your favour, but I will say, "educate the poor
fellow/lady". A non-unix person certainly has no business mucking
about with crontabs if they haven't been properly instructed at
the user level on how to use UNIX.
# That was my point. For such a system, if it can live with a static
# /etc/passwd, it could probably live with a static /etc/cron.
Probably right, considering that its user list would be static and
there would not be a need to modify cron in the first place. In fact,
*** why don't we just get rid of /usr/sbin/cron and */cron/tabs
altogether in the case of embedded systems?
# > Alternately, maybe we should just make /etc its own filesystem if we're
# I'd like to see how that could work. (sarcasm). Please tell me how
# /etc/rc* and /etc/fstab would be handled.
Of course not -- you'd have to mount /etc as a unionfs.
# I haven't seen any explanation for why it was moved from /etc in the
# first place. Anyone?
Because it's VARying data which doesn't need to be present at boot time
in order for the system to run? (which is why I have named stuff,
except for resolv.conf, living in /var)
My take on it was originally that the absolute essential boot configs
lived in /etc, while the stuff that was only needed once the system
went multi-user lived in /var. I still don't understand why we're
putting *everything* config related into /etc regardless of its
importance. Most of it seems harmless enough to put there even though
it violates the principle of necessity.
I think I agreed with the move earlier, but I must have been high
on something, because it makes no sense to me now. The only advantage
I can see for moving /var/cron into /etc is that if /var fills up,
logging stops. Of course, that could happen with mail, too.
Of course, if size is really a problem, what's preventing one from
implementing quotas on /var?
System V any flavor: just say NO!