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

[Christoph Anton Mitterer]

On Mon, 2011-05-16 at 21:36 +0200, Tollef Fog Heen wrote:
> If you argue that /var/www/$vhost is the right place,
No I don't... I meant if keeping /var/www at all (and not just dropping
it) ... then I'd say that it should only be used for web content that is
dynamically generated (e.g. out of a database or something like this).

>  surely you're not
> seriously suggesting to move database data to /srv?
I'am! I mean what we currently have in e.g. /var/lib/postgresql/data,
should imho go to /var

Uhm why not?


> An important difference is whether the admin ever interfaces with the
> files and makes decision about the inner directory structure.  For a web
> application or FTP server, they certainly do, but for an XMPP server
> they generally don't care about how it's stored and usually don't care
> about where it's stored either (as long as it's backed up).  Maildirs go
> in a user's home directory, so that's a completely separate discussion.

That would be another "definition" on how /srv vs. /var should be
used... namely via "is the data directly/manually handled/edited".
And if one uses such a definition,... you'd be right.

But I'd say that this makes much less sense,..
There are really only few kinds of data that are for sure just
_manually_ handled by the admin.
Even for FTP and HTTP this may not be the case quite often.
Imagine mirrors (automatically managed), or things like image galleries,
source repositories (I mean on FTP,.. not SVN or so).... all these are
quite often automated.


> If there's no problem with the current structure, then don't change it,
> and putting everything in /root would present problems.  I'm sure you're
> able to figure out some problems with it. :-)
Several problems were already named:
- more difficult to import the _REAL_ important data (and here I don't
mean necessarily things like the package managers DB, wich can be
recreated by reinstalling).
- problems that different classes of data can eat up the space on the
filesystem and one would like to keep this separated (e.g. I don't want
my postgresql server to block, because my /var/log runs full and vice
versa)


> there's a big problem with reusing /srv and
> that is the structure has been explicitly defined as admin territory and
> so there are no directories you can use there that are guaranteed to not
> clash with existing directories the admin has created for other
> purposes.
I still wouldn't say that we should define anything below /srv (just let
it as is).
It should be really the task of the sysadmin how data is organised
there, but of course this doesn't mean that distros weren't allowed to
make good suggestions (e.g. in their installation routines, take debconf
as an example).

For example, distros could suggest:
PostgreSQL:
/srv/postgresql/<version>/<cluster>

and if the admin nods this of it just creates what it proposed, e.g.
/srv/postgresql/9.0/main


Apache:
/srv/www/<vhost>

and e.g. debconf could ask whether this and perhaps
even /srv/www/default-host or /srv/www/main-server should be generated
or not.


XMPP:
/srv/ejabberd/

but the user could also say, "no don't use this but /srv/ejabberd/1
cause I want to run multiple ejabberds"


You see it's totally free and open.
The difference is just, that distributions should no longer provide one
single default location.
This was quite often rather restrictive anyway, e.g. when they put
postgresql in /var/lib/postgresql ... where should another DB cluster go
then (Debian already solves this right now quite nicely, though)?

And I'd even say that it's not too dangerous with respect to conflicts:
The package installation scripts could just check whether the dirs they
want to use already exist and fail or warn if so.


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5677 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110517/dcca67f8/attachment.bin