]] 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 _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
