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,

#define SARCASM
*** why don't we just get rid of /usr/sbin/cron and */cron/tabs
altogether in the case of embedded systems?
#undef SARCASM

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

				--*greywolf;
--
System V any flavor: just say NO!