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

Possible MBF wrt common, FHS-compliant, default document root for the various web servers

On Thu, Nov 05, 2009 at 04:39:06PM +0100, Stefano Zacchiroli wrote:
> On Thu, Nov 05, 2009 at 10:21:48AM +0100, Jan Hauke Rahm wrote:
> > Okay, I understand. Now, I see two ways actually to solve this.
> > 
> > 1. If we have a generic location for packages to drop their
> >    html/php/whatever files, like /var/lib/www, all web servers can keep
> >    their DocRoot as /var/www and provide an alias for /var/lib/www, for
> >    instance /debian. That way webapp packages don't even have to care
> >    about the web server in charge, we don't need a webapps-common, we
> >    just need all web servers to provide that alias (or if they can't,
> >    they have to symlink it). Every webapp would be available at
> >    localhost/debian/webapp. Since it's either a symlink or a conffile
> >    that makes this /debian alias, it can be changed by the local
> >    sysadmin without any risks and without touching our packages data.
> > 2. If however all packages put their files in different locations, we
> >    need your suggested solution with scripts for each webserver. A
> >    package like webapps-common could run
> >    foreach server in /usr/share/webapps-common/webservers/*; do
> >       ./$server webappPath webappName
> >    done
> >    and the web servers provide aliases/symlinks accordingly.
> > 
> > So, what's wrong with (1) that we don't go this simple path?
> Fair question.  As I can't came up with an answer, I guess that (1) is
> indeed a better solution, due Occam's razor.
> I only have a couple of remarks on some details:
> - According to FHS, /var/lib/ is for "variable state information". As we
>   are talking about static HTML content, which only change upon package
>   upgrade, I believe it would not be appropriate. A better place would
>   probably be /usr/share/www/PACKAGE/ (maybe some FHS guru can give us
>   some insights here ...)

Full ack, and I even like /usr/share/www. It's easy to understand and 
pretty unprobable that we'd have a package called www in the archive
some day needing this location.

> - Regarding the URL that would be mapped to that dir, I don't
>   particularly like /debian/ (even though I've advanced it). However the
>   alternative solutions I can come up with (e.g. /packages/) are
>   actually uglier. So I guess /debian/ can stay. Some of the -webapps
>   people can probably come up with wiser suggestions ...

Manoj suggested '/vendor-apps' and I like that. It says what it should
say and doesn't steal any probable path.

I still see a problem with the upgrade path for existing installations.
I might be wrong but I think the most difficult cases are very custom
setups with lots of changes by the local admin. I'm thinking of e.g.
webmail.domain.tld being a virtual host with DocRoot
/usr/share/squirrelmail. If the files there move to
/usr/share/www/squirrelmail we break a lot of setups. So, what about
shipping a symlink from the old location to the new one as a migration
path? This doesn't solve the very default (e.g. users accessing
squirrelmail via localhost/squirrelmail) but that is so easily solved
via alias directive or symlink that I suppose a NEWS.Debian entry would
fit best here.
What do you say?

Now, I'm willing to run this, i.e. file bugs against web servers, wait
for them to be fixed, then file bugs against web applications (if
needed, I'm right now looking into a way to make a lintian check for it,
e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I
don't feel like we're having a clear consensus here, do we?

Attached is a suggestion for MBF as well as a dd-list of all relevant
web servers (if I did my job right).

Now critizise!
Subject: Install alias '/vendor-apps' to /usr/share/www as canonical DocRoot for packaged web applications
Package: apache2
Severity: wishlist
User: jhr@debian.org
Usertags: canonicaldocroot-server

Dear maintainer,

when discussing the appropriate location for web application files it
was suggested to have one canonical location for those in the file
system that all these web applications should use. All web servers in
the archive should support this decision by providing a default way to
access this location.

It is consensus in debian-devel@l.d.o that this location shall be
and packages are supposed to drop their files in subdirectories, i.e.

(If a web application additionally needs files that are auto-generated
and/or to be touched by local admins or users, the application itself
should cope with that and provide a proper location for that, i.e.
probably '/var/lib/package/html' or similar.)

As a default this location shall be accessable via

If this web server has an alias functionality it is best to use that as
conffiles are the easiest way for admins to adjust the setup to their
needs. If, however, such a functionality is not given, a symlink
    /var/www/vendor-apps -> /usr/share/www
may solve the problem.

If this web servers *needs* the target of a symlink or alias directive
to exist, it may install it as an empty directory. This should be
avoided if possible (a 404 response is no good reason).

Additionally to this new location it was brought up that web
applications should a) be able to run with default settings, but also b)
be somehow secure. Therefor this new location shall -- if anyhow
possible -- be bound to localhost per default.

This bug is filed against every httpd in the archive which is the first
step to solve the current situation. Please provide this new setup soon,
so we can start filing bugs on web applications to move their files.

Krzysztof Krzyżaniak (eloy) <eloy@debian.org>
   lighttpd (U)

Jari Aalto <jari.aalto@cante.net>

Henrik Andreasson <debian@han.pp.se>

Adam Conrad <adconrad@0c3.net>
   apache2 (U)

Debian Apache Maintainers <debian-apache@lists.debian.org>

Debian Erlang Packagers <pkg-erlang-devel@lists.alioth.debian.org>

Debian lighttpd maintainers <pkg-lighttpd-maintainers@lists.alioth.debian.org>

Stefan Fritsch <sf@debian.org>
   apache2 (U)

Sergei Golovan <sgolovan@debian.org>
   yaws (U)

Francois-Denis Gonthier <neumann@lostwebsite.net>

Debian QA Group <packages@qa.debian.org>

Steinar H. Gunderson <sesse@debian.org>
   apache2 (U)

Pierre Habouzit <madcoder@debian.org>
   lighttpd (U)

Tollef Fog Heen <tfheen@debian.org>
   apache2 (U)

Francesco Paolo Lovergine <frankie@debian.org>

Torsten Marek <shlomme@debian.org>
   lighttpd (U)

Thom May <thom@debian.org>
   apache2 (U)

Jose M. Moya <josem@debian.org>

Ryan Niebur <ryanryan52@gmail.com>

Mattias Nordstrom <mnordstr@debian.org>

Leonel Nunez <leonel@enelserver.com>
   cherokee (U)

Alvaro Lopez Ortega <alvaro@gnu.org>
   cherokee (U)

Kari Pahula <kaol@debian.org>

Gerrit Pape <pape@smarden.org>

Jose Parrella <bureado@debian.org>

Franz Pletz <fpletz@franz-pletz.org>
   lighttpd (U)

Iñaki Rodriguez <irodriguez@virtualminds.es>

Peter Samuelson <peter@p12n.org>
   apache2 (U)

Thorsten Schmale <thorsten@schmalenegger.com>

Marvin Stark <marv@der-marv.de>

Salvo 'LtWorf' Tomaselli <tiposchi@tiscali.it>

Fabio Tranchitella <kobold@debian.org>
   nginx (U)

Gunnar Wolf <gwolf@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply to: