/srv?

Nick Fotopoulos weasel at beyondnormal.org
Wed Jul 14 12:42:20 PDT 2004


On Wed, 2004-07-14 at 12:58 -0500, Steve Jones wrote:
> 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
> administrator."
> 
> 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
> /usr.

FHS is really wishy washy about just what /srv is, for except they state
that the data stored here should stuff that is served up by some daemon
or server.  It however still says /var is the place where mail should
likely be stored.  Isn't this data also being served?

FHS also states that /var is for (amongst other things) "[...] transient
and temporary files."  So then what is /tmp for?  More volatile
temporary files?

We do need a better place to store web, ftp, databases that are made
public in one way or another and /srv sounds like the place to do it,
but I think we should hold out on /srv until they have worked out better
what it is, _isn't_, and a solid structure for the subdirs.  Both of the
ideas for subdir heirarchy are bad, which is why, i guess they havn't
chosen either one of them yet.

-- 
Nick Fotopoulos

"Nothing is fool-proof to a sufficiently talented fool."




More information about the lfs-dev mailing list