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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
