[fhs-discuss] tighten the use and intention of the "/var" hierarchy

[Christoph Anton Mitterer]

Hi.

I guess the idea behind /var is that of variable STATE data,.. and not
just ANY variable data (most data is variable anyway).

Defining the intended usage of /var is rather difficult, but IMHO a few
things are typical for data that goes in there:
a) the data is either NOT extremely important (e.g. logs[0], or
dynamically generated content, lock and pid-files[1]) _OR_
b) the data is there (in /var) only temporarily (e.g. emails or other
stuff in a spooling directory or cached data which should however go to
some other place finally[2]) _OR
c) the data is only used internally within programs and not exposed (at
least not directly) to the user (this is e.g. that case with package
management databases, lock files, other "state data" and/or cached data
(e.g. fail2ban could store it's currently banned addresses there) )... of
course, such [internal] data might be actually very important, just take
the package management databases as an example.

All other kinds of data (I hope I've caught every thing above) should not
go to /var, but other places (in many cases this would be /srv or /run).

Especially it's IMHO wrong, that many databases (e.g. postgresql, mysql)
are often configured to put there data files in /var/lib.
This kind of data neither fits (a) (cause it IS very important), nor (b)
(the database itself does not surprisingly go away) and although the user
does not directly operate on the database files,... he directly operates on
the data (e.g. via SQL queries),... so it's also not (c).
So IMHO, database should go e.g. to "/srv/postgresql", or "srv/mysql".

Another example is, that web-content is often put into "/var/www".
This is IMHO wrong for e.g. plain HTML files, directly edited/created by a
user.
BUT it would be indeed the right place, if the content placed there is
(fully) dynamically generated from a database. 


I'm not sure how to formally define this, I guess it needs examples like
mine attached. The message should include "precious and/or user data goes
in most cases to /srv".


Cheers,
Chris.



[0] Of course there are (corner) cases (e.g. in security) where logs can
be very important.
[1] Yes also lock and pid files are important but it's usually easy to
regenerate them.
[2] e.g. emails would finally go to the user, when he receives them, or to
the imap/pop3 servers directory in /srv/* .