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