[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FHS and /var/www

On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> > > So you think it's a good idea to ignore the the sentence above?

> > No, I don't think that using it as a default webroot is "rely[ing] on a
> > specific subdirectory structure of /srv existing or data necessarily being
> > stored in /srv", because the web server can be reconfigured to look
> > elsewhere.

> If the apache or other httpd debs ship the directory and then set it as
> the default webroot, surely that is 'relying' on the directory existing?
> Unless you don't think that packages need to ship with sane working
> defaults, which strikes me as not the sort of argument you normally make.

Actually, I think the sane default for a package that serves content to the
network is to not serve any at all, so it's more relying on the directory
*not* existing.  But as you've shown, this is not a safe assumption either.

> /srv/ is, AIUI, the admin's playground to structure as they see fit,
> much like /usr/local.  I am fairly sure you wouldn't advocate a webroot
> of /usr/local/www, so I'm having a hard time seeing why this is this better.

/usr/local/www is explicitly forbidden by the FHS.  So is /var/www.  In the
case of /srv/www, we're not forbidden to use it as a default, we're only
forbidden to put content there by default.

> My objection is because the FHS tells us that we can't rely on a
> particular layout of /srv/ - making the webroot be /srv/www is relying on
> a particular layout of /srv.  This is an obvious contradiction to me,
> but I see that you disagree.  I'm just not sure how you can reconcile
> "we want to ship applications that work out of the box" and "we have no
> idea what the directory structure will be on the target system".

The process for deploying content under apache with the current settings is
"copy it to /var/www".  If we used /srv/www as a default, the process would
be "mkdir -p /srv/www && ..."  I don't think that's a hugely significant

> > Does "wildly inappropriate" mean that shipping such a default would
> > incorrectly expose data to the network that wasn't meant to be exposed?

> Yes.  My webservers tend to use something like
> /srv/www/<sitename>/{config,cgi-bin,htdocs,lib,logs,blah,blah}/ as the
> normal layout.  Exposing /srv/www as a document root would give access to
> lots of things that are not public in many cases - we tend to not bother
> with .htaccess files since config/ and so on are not under the webroot.

> However, as I said, it being wrong for me is personal - the fact that
> the FHS tells us that /srv/ is the domain of the local admin to reorder
> however they feel like is enough to argue against relying on /srv for
> anything packaged.

Well, I think the possibility of running afoul of incompatible local
configurations is a pretty good reason not to use /srv/www as a default, so
I think that's absolutely a policy issue.

Would the suggested /srv/www/localhost/htdocs as a default work for you?
Apparently this is widely deployed on other distros, and seems to be
entirely compatible with what you're doing.  I think the chances are pretty
slim that this directory exists *and* contains content that isn't meant to
be served.  Or, if "localhost" might imply content that's only meant to be
served to the local host, then maybe /srv/www/default-site/htdocs?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: