1 |
On Wed, Feb 04, 2004 at 12:53:40AM +0000, Stuart Herbert wrote: |
2 |
> The Linux Filesystem Hierarchy Standard (FHS) 2.3, released 29th Jan 2004, |
3 |
> introduced a new top-level directory, /srv. It's basically a hierarchy for |
4 |
> storing file trees for services. |
5 |
I'm both for and against an /srv tree. |
6 |
|
7 |
On the against side, it has very little use for anybody that is |
8 |
interested in a simple server or workstation, where the machine doesn't |
9 |
do much. These cases loose only a shorter pathname by instead having |
10 |
/var/www, /var/cvsroot etc. |
11 |
|
12 |
On the for side, there is a LOT of use for this in networked and |
13 |
non-simple cases. As an example, I have a /var/www and /var/ftpdata with |
14 |
6 domains spanning 30 hostnames of content. It's shared between two |
15 |
frontend servers that provide HTTP/FTP/SMTP/IMAP-SSL. The data is |
16 |
physically stored on a RAID array attached to a third box that serves it |
17 |
via NFS to the frontend boxes. The domains are virtual, and using |
18 |
vpopmail for email puts the email in /var/vpopmail/domains. This results |
19 |
in a nasty set of NFS exports, as well as data being badly scattered |
20 |
around /var. I also try to keep quotas on each domain, so they don't |
21 |
overrun the system, but it's a pain with spread data like that (and |
22 |
vpopmail-based mail has to be owned by a specific user/group to work so |
23 |
that excludes user/group quotas anyway). |
24 |
|
25 |
Wholescale export of /var is not an option for many reasons. The |
26 |
solution to this (which i'll do with my boxes at some point in the near |
27 |
future) is using /srv. Ideally I'd like /srv/[domain]/{www,ftp,mail}/, |
28 |
as this would make exporting and everything relatively simple, and |
29 |
clearcut as to how everything works. I'd put it on a seperate partition |
30 |
and mount it with noexec,nosuid just like I do with /tmp for security. |
31 |
This may cause some problems with people that use cgi scripts than |
32 |
require an execute bit, but I don't allow that on my servers anyway, so |
33 |
I wouldn't suggest forcing it onto users. |
34 |
|
35 |
The following item from the FHS specification describes the best use of |
36 |
it: |
37 |
> This main purpose of specifying this is so that users may find the |
38 |
> location of the data files for particular service, and so that |
39 |
> services which require a single tree for readonly data, writable data |
40 |
> and scripts (such as cgi scripts) can be reasonably placed. Data that |
41 |
> is only of interest to a specific user should go in that users' home |
42 |
> directory. |
43 |
/home/httpd is not correct for apache as it is NOT a user, it's a system |
44 |
daemon. |
45 |
|
46 |
As an attempt at compromise between all parties, we need either a |
47 |
configuration method that users can choose between /var and /srv for |
48 |
their data, or some means that /srv is relatively non-obtrusive. |
49 |
|
50 |
For the non-obtrusive solution, lets have the existance of a /srv item |
51 |
in the root directory, and let default to a symlink, and document to |
52 |
users that they can put it on a seperate partition/space if they want |
53 |
further seperation. This would require the least work I think. |
54 |
|
55 |
The configuration option is a tricky case, due to problems with binary |
56 |
packages building with locations put in at build time, amongst other |
57 |
things. |
58 |
|
59 |
My personal preference is for the creation of a /srv, and having it |
60 |
default to being a symlink to somewhere else in the existing tree to |
61 |
ease migration. |
62 |
|
63 |
-- |
64 |
Robin Hugh Johnson |
65 |
E-Mail : robbat2@××××××××××××××.net |
66 |
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 |
67 |
ICQ# : 30269588 or 41961639 |
68 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |