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

Tollef Fog Heen tfheen at err.no
Tue May 17 00:19:09 PDT 2011


]] Christoph Anton Mitterer 

Hi,

| 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).

There is no keeping /var/www, it's not in the FHS.

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

I feel silly for having to explain elementary logic on this list, but
whatever.  A construction «If A then B» means exactly that.  It means
that if A is true then B is also true.  If A is false, it does not say
anything about B, you said above that A was not true, so saying
something about B is pointless.

| Uhm why not?

Let me re-ask my previous question:

  | a) This means that nobody uses it [/srv].

  No, it does not.  Really, where else do you put stuff such as the
  different web server vhosts you have?

Not «where does this go today», but where you would put it.  Please note
that /var/www is not in the FHS today, so apart from Debian misusing it,
there's no reason to put stuff there.

| > 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).

Sounds like you want /var to just be what should go in /var/cache,
really.

| - 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)

Then put its data on a different file system.  The FHS tries to tell
distributions how to structure the default file syste

| > 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).

So it'll just be free-for all and we just put it in the individual
packager's or the distributions hands what the default (which will often
be accepted as it is) should be?  How is that an improvement on the
current situation?

| 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"

If you want those setups on your systems, just change the configuration
files or make symlinks from /var/$wherever.  You're going to end up with
fragmentation where some services will default to /srv/$service and some
to /srv/$(hostname|vhost)/$service, for a start.

| You see it's totally free and open.

You seem to place value in having no sensible default locations that are
fine for most installations

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

That's, as you say, a solved problem, and it's hardly hard to tell
postgres where it should place its files.  And, unless you mean
providing a list of default locations, distributions would still provide
a single default location.  You are increasing complexity for something
that I believe has negative value.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


More information about the fhs-discuss mailing list