Steve Jones sljones3 at arkansas.net
Wed Jul 14 10:58:03 PDT 2004

This has been CC'd to blfs-dev as it applies to them also.

What follows is why I think /srv should stay, what it's for and how I
use it.

On Wed, 14 Jul 2004, Dagmar d'Surreal wrote:

> I'd just like to know why this directory is being included at all, other
> than the rather goofy paragraph in FHS 2.3 casually declaring that every
> system should have it, which frankly I consider to be insufficient
> justification.  Seems like a wasted inode to me.
It is required by the FHS, and I use it on my own system for my local
apache tree, mp3 storage, video files, source code repository, cvs and
svn repositories, and database repositories.  The reason LFS doesn't use
/srv is that LFS doesn't install any servers.  The problem is that BLFS
doesn't use it for the default location of served data.

> Reasons:
> 1. This directory has apparently been created out of whole cloth
> (meaning no distribution has ever used it before to my knowledge),
I admit that the FHS rational is quite fuzzy and incomplete.  But in the last
sentence of the /srv section it states:

"Distributions must take care not to remove locally placed files in
these directories without administrator permission."

With the footnote

"This is particularly important as these areas will often contain both
files initially installed by the distributor, and those added by the

This keeps that website that took many hundred of hours to build intact
when apache is upgraded.

> apparently to support user laziness.  Supporting user laziness is a
> slippery slope to be avoided that leads to things like /Programs
> and /Libraries directories.
And what do you call /lib, /usr/lib, /bin, /sbin, /usr/bin, /usr/sbin,

Any way, I thought using Linux was about being lazy, why type /Programs
instead of /bin. :)

> 2. Currently LFS populates this with two things... Jack and squat.
As stated above, the usage of /srv should be a BLFS thing.

> 3. "[...] no program should rely on [...] data necessarily being stored
> in /srv."  This justification is counter to the point of the FHS. 
This is one area that the rational doesn't make clear.  In my interpreted
that line implies two things, 1) configuration and state files already
have a place to live ( /etc and /var), 2) this tree is for site specific
data ( your sites web-space, public ftp, cvs, ...).

Right now the current state of BLFS forces the user to know what /srv is
all about and make the configuration changes necessary to take advantage
of it.  Before it appeared, I never knew exactly where to keep my mp3
collection so it would be available to my home network.  Now it has a
proper place to live.  Also for example, the apache default installation
is overly dependent on /var as a place to store HTML files.  On my multi
partition system this would fill up that small partition rather quickly
instead of having a tree where I can put things where I want them.

The FHS was badly in need of /srv.  IIRC redhat ( 6.2 days) used to put
the http files and ftp trees under /home.  I always thought that wasn't
good place for them but I couldn't figure out any other place.
/usr/share wasn't any good either since I use RO partitions for / and

To keep from rambling and repeating my self, BLFS should adopt /srv and
use it for it's proper usage regardless of whether or not it's dropped
from LFS.

Steve Jones
sljones at arkansas.net

More information about the lfs-dev mailing list