[nycbug-talk] why /var?

[Jay]

On Fri, 18 Feb 2005 12:31:27 -0500 (EST), Dru <dlavigne6 at sympatico.ca> wrote:
> 
> Out of pure innocent curiosity, why do you prefer /var? I don't see the
> logic as I never thought of a website as "variable" data but I'm
> interested in hearing someone else's point of view.
> 
> Dru

I can't speak for anyone else, but I can tell you why I like /var.  It
all depends on how you define 'variable'.  From a system standpoint,
websites are fairly variable.  Unlike the executables in /bin, /sbin,
and /usr/*, web content is intended to change.  Maybe not everday, but
often.  In an ideal world, executables are completely static; if they
didn't have bugs, we'd never touch them.  Also, if you have any kind
of user-generated web data--bbs, bloggs, file submission pages--web
data is extrememly variable.

The best answer, though, is that /var is where system daemons put
their data.  Most partition labels don't accurately reflect use
anymore, anyway.  We don't let many users store publically accessible
executables in /usr/bin or /usr/local/bin, even though that's what
they're there for.  Close to half of anything in most most variations
on the bin theme is likely to not even be binary, but executables in
some interpreted or compiled and interpreted language like perl,
python, or java.  And if we're going to be really serious about truth
in advertising on filesystems, the mail spool should almost certainly
go in /tmp, and the only honest label for the rest would be to make
one big /etc partition and leave it at that.

But these things have a long and not always rational history, and /var
is where daemon's put their data, and /usr isn't where users put their
data.  And it makes sense to put the webroot with the mail spool and
the database directories so that you can harden /usr and enforce a
serious look, but don't touch policy on that partition.

This is probably a theological issue, though.

best,

--jay