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! Hauke
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
/usr/share/www
and packages are supposed to drop their files in subdirectories, i.e.
/usr/share/www/package
(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
http://localhost/vendor-apps/package
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.
Thanks!
Krzysztof Krzyżaniak (eloy) <eloy@debian.org> lighttpd (U) Jari Aalto <jari.aalto@cante.net> micro-httpd Henrik Andreasson <debian@han.pp.se> caudium Adam Conrad <adconrad@0c3.net> apache2 (U) Debian Apache Maintainers <debian-apache@lists.debian.org> apache2 Debian Erlang Packagers <pkg-erlang-devel@lists.alioth.debian.org> yaws Debian lighttpd maintainers <pkg-lighttpd-maintainers@lists.alioth.debian.org> lighttpd Stefan Fritsch <sf@debian.org> apache2 (U) Sergei Golovan <sgolovan@debian.org> yaws (U) Francois-Denis Gonthier <neumann@lostwebsite.net> boa Debian QA Group <packages@qa.debian.org> thttpd 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> aolserver4 Torsten Marek <shlomme@debian.org> lighttpd (U) Thom May <thom@debian.org> apache2 (U) Jose M. Moya <josem@debian.org> mathopd Ryan Niebur <ryanryan52@gmail.com> dhttpd Mattias Nordstrom <mnordstr@debian.org> bozohttpd Leonel Nunez <leonel@enelserver.com> cherokee (U) Alvaro Lopez Ortega <alvaro@gnu.org> cherokee (U) Kari Pahula <kaol@debian.org> tntnet Gerrit Pape <pape@smarden.org> fnord Jose Parrella <bureado@debian.org> nginx Franz Pletz <fpletz@franz-pletz.org> lighttpd (U) Iñaki Rodriguez <irodriguez@virtualminds.es> webfs Peter Samuelson <peter@p12n.org> apache2 (U) Thorsten Schmale <thorsten@schmalenegger.com> monkey Marvin Stark <marv@der-marv.de> mini-httpd Salvo 'LtWorf' Tomaselli <tiposchi@tiscali.it> weborf Fabio Tranchitella <kobold@debian.org> nginx (U) Gunnar Wolf <gwolf@debian.org> cherokee
Attachment:
signature.asc
Description: Digital signature