Re: /var/www or /var/web
sean finney <firstname.lastname@example.org> writes:
> hi paul, ben, et al,
Please follow the guidelines for Debian mailing lists: don't send me a
copy of messages unless I ask for one. I read the list.
> On Sat, 2007-01-20 at 12:34 +1100, Ben Finney wrote:
> > The methodology used to name subdirectories of /srv is unspecified
> > as there is currently no consensus on how this should be done.
> > ... Therefore, no program should rely on a specific subdirectory
> > structure of /srv existing or data necessarily being stored in
> > /srv. However /srv should always exist on FHS compliant systems
> > and should be used as the default location for such data.
> > <URL:http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM>
> > So, for content served by a web server on the system, something under
> > '/srv' is necessary to comply with the FHS. The most obvious choice
> > seems to be '/srv/www'.
> in the section you quoted above it specifically says no program should
> rely on a specific subdirectory, which contradicts what you've just
Let's try reading that again:
... no program should rely on a specific subdirectory structure of
/srv existing or data necessarily being stored in /srv. ...
which would apply if the package was going to *rely on the
subdirectory existing, or data necessarily being stored in /srv*,
which isn't the case.
However /srv should always exist on FHS compliant systems
and should be used as the default location for such data.
which applies if the package is going to configure a location to
*store data* that falls under the description of this section, "Data
for services provided by this system", which is the case.
In which case, the FHS is explicit that "/srv ... should be used as
the default location for such data".
So much for the FHS: it's clear that data such as that provided by a
web server should be stored somewhere under /srv.
> secondly, even if there were an outright conflict between debian
> policy and the FHS, debian policy wins wrt placement of files and
> directories in debian.
That's true. Is there such a conflict?
The Debian Policy document doesn't specify what document root should
be configured by a web server; the closest I can find is:
11.5 Web servers and applications
4. Web Document Root
Web Applications should try to avoid storing files in the Web
Document Root. Instead they should use the /usr/share/doc/package
directory for documents and register the Web Application via the
doc-base package. If access to the web document root is
unavoidable then use
as the Document Root. This might be just a symbolic link to the
location where the system administrator has put the real document
which speaks only about what web *applications* should expect, and
doesn't speak about what the web *server* package should configure.
\ "I object to doing things that computers can do." -- Olin |
`\ Shivers |