common, FHS-compliant, default document root for the various web servers
Stefano Zacchiroli
On Wed, Nov 04, 2009 at 04:08:02PM +0100, Holger Levsen wrote:
> Uhm, why postpone this so long? I'd hope we could find a consensus quite soon.
> Then, we might not be able to fix _all_ web apps until squeeze, but at least
> tthose few with dir-or-file-in-var-www :-)
I see it a tad more complicate than you, let's hope its me
overestimating the task :-)
- the agreement actually should not come among web app maintainers, but
rather among web *server* maintainers: they should agree over a
specific dir and change the default configuration of the web server so
that that dir is the document root (for the default vhost, for web
servers supporting vhosts)
* possibly, migrating to that would require offering migration paths
to package users
- then you might start migrating web apps packages so that they install
(static) stuff under that dir, preserving the per-package path as
detailed in the webapps-common policy
- then, the rule should go into policy (possibly under §9.1.1, has an
exception to FHS, not sure about the section though) and that can't
happen before due to the usual practice-should-predate-policy
If it were me to try to achieve this, I would go for a DEP to keep track
of consensus, ... but no, I'm not willing to drive this, at least not
now :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Gunnar Wolf
> > Uhm, why postpone this so long? I'd hope we could find a consensus quite soon.
> > Then, we might not be able to fix _all_ web apps until squeeze, but at least
> > tthose few with dir-or-file-in-var-www :-)
>
> I see it a tad more complicate than you, let's hope its me
> overestimating the task :-)
>
> - the agreement actually should not come among web app maintainers, but
> rather among web *server* maintainers: they should agree over a
> specific dir and change the default configuration of the web server so
> that that dir is the document root (for the default vhost, for web
> servers supporting vhosts)
>
> * possibly, migrating to that would require offering migration paths
> to package users
That's easy, as there is fewer of us than web app maintainers. And it
is a first step. We might even have a transitional symlink making
/var/www point to /var/lib/www or whatnot?
> - then you might start migrating web apps packages so that they install
> (static) stuff under that dir, preserving the per-package path as
> detailed in the webapps-common policy
>
> - then, the rule should go into policy (possibly under §9.1.1, has an
> exception to FHS, not sure about the section though) and that can't
> happen before due to the usual practice-should-predate-policy
>
> If it were me to try to achieve this, I would go for a DEP to keep track
> of consensus, ... but no, I'm not willing to drive this, at least not
> now :-)
It is a bit ambitious to have it _completely_ done by Squeeze. But we
can start pushing the right way. And anyway, I do not feel it is
asking too much. Yes, we cannot just go from using /var/www to
having its existence violate policy and making insta-RC, but as soon
as the (major at least) webserves change their defaults, we can start
filing wishlist bugs, pointing maintainers to this being a work in
progress and expecting it to be strictly enforced by policy for
squeeze+1.
--
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Neil McGovern
> - the agreement actually should not come among web app maintainers, but
> rather among web *server* maintainers: they should agree over a
> specific dir and change the default configuration of the web server so
> that that dir is the document root (for the default vhost, for web
> servers supporting vhosts)
>
For reference, when the initial RFH on a webapps policy was sent out,
all httpd maintainers were included.
> If it were me to try to achieve this, I would go for a DEP to keep track
> of consensus, ... but no, I'm not willing to drive this, at least not
> now :-)
>
I personally don't like the DEPs, but would be happy to accept reasoned
patches into the webapps policy submission.
Neil
--
<enrico> What is a sane place to look for washing machines around Manchester?
<mhy> enrico: the canals :-)
Stefano Zacchiroli
> 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 ...)
- 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 ...
Giacomo A. Catenazzi
> [ adding -policy to Cc: ]
>
> On Wed, Nov 04, 2009 at 04:08:02PM +0100, Holger Levsen wrote:
>> Uhm, why postpone this so long? I'd hope we could find a consensus quite soon.
>> Then, we might not be able to fix _all_ web apps until squeeze, but at least
>> tthose few with dir-or-file-in-var-www :-)
>
> I see it a tad more complicate than you, let's hope its me
> overestimating the task :-)
>
> - the agreement actually should not come among web app maintainers, but
> rather among web *server* maintainers: they should agree over a
> specific dir and change the default configuration of the web server so
> that that dir is the document root (for the default vhost, for web
> servers supporting vhosts)
>
> * possibly, migrating to that would require offering migration paths
> to package users
>
> - then you might start migrating web apps packages so that they install
> (static) stuff under that dir, preserving the per-package path as
> detailed in the webapps-common policy
>
> - then, the rule should go into policy (possibly under �9.1.1, has an
> exception to FHS, not sure about the section though) and that can't
> happen before due to the usual practice-should-predate-policy
Personally I would like to have a competently different approach:
- web server ask where to put the root (probably proposing default
a /srv/www location). But not further assumption about the location.
Admins, per FHS, could choose other paths.
This could be done by a new update-http-root application.
(and ev. could handle multiple vhost).
And possibly allowing no public location (thus forcing local only
connections): we tend to forget about this, but IMHO more and more
desktop computers are installed with webserver because of local
convenience. Thus we really need to securely support this common
cases.
- No webapp are installed "live" by default:
We have too much crap web application, and some/most of our users
don't realize that they are installing a public accessible crap.
[the desktop users]
Thus IMHO we need a "update-webappl" utility, which would
list, ask and ev. install the just installed webapplication.
This is not so far as the installation of apache modules, which
ask for which apache (apache/apache2/apache2-ssl/...) to enable
modules. We just list the possible web root.
Naturally admins can skip this point (e.g. not allowing debian
to handle webappl, but doing manually).
Probably a webserver-specific support script will handle the
generation of symlink (default) or via configuration (webserver
specific) of the /usr/lib/cgi or /usr/share/* dir.
In short:
- no hardcoded default root location (only a default value for a
real user question)
- not installing by default (without asking) web apps.
ciao
cate
PS: first mail in debian-policy, so maybe I missed the point of
the discussion (which take place in the other mailing lists)
Jan Hauke Rahm
> Personally I would like to have a competently different approach:
>
> - web server ask where to put the root (probably proposing default
> a /srv/www location). But not further assumption about the
> location.
> Admins, per FHS, could choose other paths.
This is done in a few webapps right now. But we (as in maintainers)
still need to provide a sane (FHS and policy comliant) default for
non-interactive installations and even for users who have no clue about
what they're doing and simply press enter.
> This could be done by a new update-http-root application.
> (and ev. could handle multiple vhost).
> And possibly allowing no public location (thus forcing local only
> connections): we tend to forget about this, but IMHO more and more
> desktop computers are installed with webserver because of local
> convenience. Thus we really need to securely support this common
> cases.
Well, if we go for a solution that implements vhosts (in case of apache
and other web servers that even know about vhosts) we could include some
command to bind the vhost to localhost. I'd be okay with it. If,
however, we decide to have one debian specific DocRoot which all webapps
whould use, then we don't have vhosts for all packages but one generic
one. We can still have this per default bound to localhost but if one
webapp is public, all are.
> - No webapp are installed "live" by default:
>
> We have too much crap web application, and some/most of our users
> don't realize that they are installing a public accessible crap.
> [the desktop users]
Isn't that what the topic was about? *confused*
> Thus IMHO we need a "update-webappl" utility, which would
> list, ask and ev. install the just installed webapplication.
>
> This is not so far as the installation of apache modules, which
> ask for which apache (apache/apache2/apache2-ssl/...) to enable
> modules. We just list the possible web root.
>
> Naturally admins can skip this point (e.g. not allowing debian
> to handle webappl, but doing manually).
>
> Probably a webserver-specific support script will handle the
> generation of symlink (default) or via configuration (webserver
> specific) of the /usr/lib/cgi or /usr/share/* dir.
What exactly should these scripts do then?
> In short:
>
> - no hardcoded default root location (only a default value for a
> real user question)
As said above, we need a DocRoot that is FHS and policy compliant. If I
understand you correctly you want a DocRoot for each and every webapp
instead of one global DocRoot?
> - not installing by default (without asking) web apps.
You mean a debconf template that says: "I know you typed 'aptitude
install webapp' but we're smarter than you are and thus not doing it
unless you really want to and type 'yes' now." ? Remember Debian is not
only about a secure system but also about a working system. Don't make
life harder than necessary. I'd agree to binding to localhost, though.
Hauke
Harald Braumann
Stefano Zacchiroli <za...@debian.org> wrote:
> - 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 ...
/debian/ seems to be the de facto standard for Debian archives. So I
guess it wouldn't be such a good idea to use it for something else
(sorry, can't really come up with a better name myself).
Cheers,
harry
The Fungi
> /debian/ seems to be the de facto standard for Debian archives. So I
> guess it wouldn't be such a good idea to use it for something else
> (sorry, can't really come up with a better name myself).
Something short, generic and distro-neutral like /app/ would be my
personal preference if I were developing a standard for my servers.
Unfortunately, going that direction as also increases the chances of
remapping a path the admin was already using...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
Jan Hauke Rahm
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
Charles Plessy
>
> 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?
Dear Hauke,
As a maintainer of a web application, I share your worries. I never had any
user request to make it work out of the box with alternative web servers, so I
guess that my users have nothing to gain and everything to lose in a change. I
strongly suggest that the transition is experimented on a few volunteer
packages before increasing the workload of many persons – users and developers.
For new packages, grouping everything in /usr/share/www sounds like a good
idea. The alias name, « vendor », I find a bit disturbing because we do not
sell anything. But picking the name will be the priviledge of the Do-o-crat who
will lead the transition, I presume.
Still, having /usr/share/www as a document root does not prevent complex
packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
/var/tmp, /var/run and /etc. Maybe you can double-check how many web servers
are able to cope with that before starting to invest a lot of time. Otherwise,
since shipping configuration files in /etc/webserver/conf.d will still be
necessary for these packages to work, there will little benefit in moving files
to /usr/share/www.
Anyway, thank you very much for your initiative. Exploring new directions is good !
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Jan Hauke Rahm
On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
> As a maintainer of a web application, I share your worries. I never had any
> user request to make it work out of the box with alternative web servers, so I
> guess that my users have nothing to gain and everything to lose in a change. I
> strongly suggest that the transition is experimented on a few volunteer
> packages before increasing the workload of many persons – users and developers.
I think this is a bit black or white. Users (ar rather admins) gain the
possibility to easily guess where a package is to be found. No looking
for /usr/share/package/html or something, just assume it's
/usr/share/www/package. And they don't lose everything, they just need
to read the chapter (yet to be written, of course) in the release notes
about web applications being moved; additionally NEWS.Debian should be
provided by any relevant package and so on.
Also, I said, a proper migration path has still to be figured out. The
question for now is: do we want this change at all and -- if so -- shall
I file bugs against the web servers. I'd suggest severity wishlist for
the start.
> For new packages, grouping everything in /usr/share/www sounds like a good
> idea. The alias name, « vendor », I find a bit disturbing because we do not
> sell anything. But picking the name will be the priviledge of the Do-o-crat who
> will lead the transition, I presume.
Well, I find 'vendor' a bit confusing as well but I'm not a native
english speaker and I don't have better ideas. Shoot if you have any.
Something like 'debian', 'webapps', 'applications' seem way to generic
for this.
> Still, having /usr/share/www as a document root does not prevent complex
> packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
> /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers
> are able to cope with that before starting to invest a lot of time. Otherwise,
> since shipping configuration files in /etc/webserver/conf.d will still be
> necessary for these packages to work, there will little benefit in moving files
> to /usr/share/www.
And there isn't even a way we could (or want to) solve this.
Applications of many sorts have to deal with FHS, webapps are nothing
special in that matter. We can't allow an admin to fiddle aroung with
files in /usr/share, nor can we just pump all webapps into /var as this
will break (or at least bloat) many backup strategies and cause other
problems.
Until now I thought simple symlinks work with every webserver and thus
didn't see a problem for that. It's the application that sometimes needs
patching to deal with its being splattered around. Am I wrong here?
Hauke
Henrik Andreasson
Caudium can and will adjust to any standard that the community agrees
upon and it can handle different directories without problem.
I really dont have that much input for how this should be done but leaving
it as it is now is worse.
> Thanks for your response, Charles!
>
> On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
>> As a maintainer of a web application, I share your worries. I never had any
>> user request to make it work out of the box with alternative web servers, so I
>> guess that my users have nothing to gain and everything to lose in a change. I
>> strongly suggest that the transition is experimented on a few volunteer
>> packages before increasing the workload of many persons ? users and developers.
Stefano Zacchiroli
> > > 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.
> >
> > - 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.
Fine, it seems we're done with this aspect then.
> > - 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.
Right, but it is possibly hard to type and a bit ugly, I've
counter-proposed "/vendor/" (see my separate mail on that).
> 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?
I think that migrations from complex setup to this new setup will stay
complex no matter what we do. Also, it is not really something we can
"standardize" upon as migrations are very specific to each involved
packages and will ultimately be dealed with by single maintainers. So
I'd refrain to propose a generic upgrade path and just describe the new
situation we want to obtain.
> 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?
Well, defining consensus is always a tricky business :), but I haven't
heard significant voices against, am I wrong? I'd personally proceed as
follow: write a draft document (even a very brief one!) which summarizes
the proposal so that people do not need to dig into the thread to follow
the evolution. Once we have it, re-post it to the relevant lists (I'd
say -devel, -policy, -webapps) and ask for comments.
Actually, your suggested MBF text can pretty much be that document. If
it were me, I'd open a DEP on that just because I fear losing track of
it, but YMMV.
> Attached is a suggestion for MBF as well as a dd-list of all relevant
> web servers (if I did my job right).
Wow, thanks!
Stefano Zacchiroli
> idea. The alias name, « vendor », I find a bit disturbing because we do not
> sell anything. But picking the name will be the priviledge of the Do-o-crat who
> will lead the transition, I presume.
Well, it is actually pretty common in cross-distro lingo, Debian is a
vendor as well as pretty much every other distro is. The advantage of
settling on such a name IMO would be a higher chance in making it
popular in other distros. Also, it is a name that I _think_ is pretty
unlike to be used by local admins.
> Still, having /usr/share/www as a document root does not prevent complex
> packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
> /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers
> are able to cope with that before starting to invest a lot of time. Otherwise,
> since shipping configuration files in /etc/webserver/conf.d will still be
> necessary for these packages to work, there will little benefit in moving files
> to /usr/share/www.
I don't understand this argument. Sure, complex packages will be split
in several dirs, our policy states the rule for that to happen. The
whole point of this standardization is to have a single URL prefix under
which _entry_points_ for shipped web applications can be found, no
matter how the applications are deployed on the filesystem. I found such
a goal worthwhile by itself and orthogonal to the other concern you
raise.
Jan Hauke Rahm
> On Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm wrote:
> > 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?
>
> I think that migrations from complex setup to this new setup will stay
> complex no matter what we do. Also, it is not really something we can
> "standardize" upon as migrations are very specific to each involved
> packages and will ultimately be dealed with by single maintainers. So
> I'd refrain to propose a generic upgrade path and just describe the new
> situation we want to obtain.
I agree, I was just pointing out that common setups can have a proper
migration path. We could give a hint when we're at it but the maintainer
needs to think of something him/herself after all.
> > 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?
>
> Well, defining consensus is always a tricky business :), but I haven't
> heard significant voices against, am I wrong? I'd personally proceed as
> follow: write a draft document (even a very brief one!) which summarizes
> the proposal so that people do not need to dig into the thread to follow
> the evolution. Once we have it, re-post it to the relevant lists (I'd
> say -devel, -policy, -webapps) and ask for comments.
I'll try to come up with something within the next 24 hours. Don't know
yet if it's gonna be a DEP or just another mail but summarizing what we
got so far sounds like a plan.
Hauke
Stefano Zacchiroli
> the lintian error dir-or-file-in-var-www exists for a long time, and I
> believe that most packages with active maintainers have already been
> split according to the FHS. What I question is whether it is worth the
> effort to move the content of /usr/share/<package> to
> /usr/share/www/<package>:
>
> - How many purely static websites do we distribute as Debian packages?
> (Note that /usr/share/doc/<package> is already served as http://localhost/doc/package/)
>
> - How many dynamic websites will start to work out of the box without
> the need for a specific configuration for each webserver?
I now understand better your argument, thanks for rephrasing. I don't
have an answer, because I haven't done the test, but I do agree that it
would be interesting to know in advance. Still, it is not exactly clear
to me how to test this, how would you automatically discover whether a
package has a static splash screen (note indeed that it is not only
about "purely static" web applications, but also about "regular"
webapps, with a static splash screen).
>
> I checked at the web application I maintain (emboss-explorer), and in its
> particular case, it would still need an apache.conf file. That is not enough to
> make statistics, so I am just asking if there will be many packages that can
> take advantage of the proposed reorganisation. [And unfortunately source.debian.net
> looks borken again…].
Can you perhaps explain why so?
I frankly hope that with /vendor/ + /usr/lib/cgi-bin/ (which we already
have), and maybe with some symlinks under /vendor/ we will be able to
address quite a lot of issues. It would be interesting to known which
one we can't.
Now that I think of it, probably a per-package data dir would help, but
that can be a tad more tricky due to single-instance of
multiple-instance nature of the webapp in question ...
> Of course, if the use of /usr/share/www/<package> is optional,
> everybody wins.
It is forcibly optional: if you have some static content you should use,
otherwise not.
sean finney
> I frankly hope that with /vendor/ + /usr/lib/cgi-bin/ (which we already
> have), and maybe with some symlinks under /vendor/ we will be able to
> address quite a lot of issues. It would be interesting to known which
> one we can't.
objection, you honor! :)
something that hasn't really been brought up (i mentioned it on the
non-webapps thread in -devel already) is that this makes packages
potentially opened in an unconfigured state. unless you can ensure that
the system is only running on localhost, it has some significant security
implications. personally i'd rather that /usr/lib/cgi-bin goes the way
of the dodo, and that packages are required to ship/generate webserver
config files if they want to function out of the box.
sean
Russ Allbery
> something that hasn't really been brought up (i mentioned it on the
> non-webapps thread in -devel already) is that this makes packages
> potentially opened in an unconfigured state. unless you can ensure that
> the system is only running on localhost, it has some significant
> security implications. personally i'd rather that /usr/lib/cgi-bin goes
> the way of the dodo, and that packages are required to ship/generate
> webserver config files if they want to function out of the box.
Wholeheartedly agreed, particularly if we can put a management system in
place similar to the (really nice) Apache module management system that
lets admins selectively enable specific applications, which installing
everything into a default CGI-active directory doesn't permit as easily.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jan Hauke Rahm
> sean finney <sea...@debian.org> writes:
>
> > something that hasn't really been brought up (i mentioned it on the
> > non-webapps thread in -devel already) is that this makes packages
> > potentially opened in an unconfigured state. unless you can ensure that
> > the system is only running on localhost, it has some significant
> > security implications. personally i'd rather that /usr/lib/cgi-bin goes
> > the way of the dodo, and that packages are required to ship/generate
> > webserver config files if they want to function out of the box.
>
> Wholeheartedly agreed, particularly if we can put a management system in
> place similar to the (really nice) Apache module management system that
> lets admins selectively enable specific applications, which installing
> everything into a default CGI-active directory doesn't permit as easily.
Not that I'm opposing to what you're saying but... every application in
the archive is configured during the installation process, possibly
asking debconf questions, providing defaults etc. After the installation
it should run in a mode that suites most use cases and is secure. We (or
at least I) always expected that.
Now with web applications, if I read you suggestions correctly, you want
to just throw the files in the system, leave it unconfigured without
meaningfull defaults, even leading to an unsecure state, and then blame
the web server for not securing the application?
Or am I misunderstanding you?
Hauke
sean finney
On Tue, Nov 10, 2009 at 09:15:43AM +0100, Jan Hauke Rahm wrote:
> Not that I'm opposing to what you're saying but... every application in
> the archive is configured during the installation process, possibly
> asking debconf questions, providing defaults etc. After the installation
> it should run in a mode that suites most use cases and is secure. We (or
> at least I) always expected that.
i think there's some ambiguity due to different uses of the term
configuration... i meant largely wrt the application configuration,
not the package's status wrt dpkg (though the latter probably also
implies the former).
> Now with web applications, if I read you suggestions correctly, you want
> to just throw the files in the system, leave it unconfigured without
> meaningfull defaults, even leading to an unsecure state, and then blame
> the web server for not securing the application?
the issue that i'm raising is that in this proposal the default "vendor"
docroot is on by default, and the existing cgi-bin directory has
files that are executed by the webserver without regard to whether the
application is (or is properly) configured. therefore it will be activated
as soon as the files are unpacked and the onus is then placed on the
packager and (more likely) the local admin to make sure that this window
of oppurtunity is closed with appropriate webserver configuration after
the package has been installed.
given that there is likely a requirement for real world applications
to register themselves with a webserver anyway (for things which couldn't
"just work", extra Alias's for FHS splitting, etc), i don't see the
argument for making some subset of the package active when the larger
problem still exists and it potentially exposes the system security wise
in the meantime.
i'm not arguing against having standards and a system for getting apps to
work out of the box, in fact that's why this list was created in teh first
place. but much of this discussion is treading over already trodden paths :)
sean
--
Stefan Fritsch
On Monday 09 November 2009, Jan Hauke Rahm wrote:
> > > 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?
> >
> > Well, defining consensus is always a tricky business :), but I
> > haven't heard significant voices against, am I wrong? I'd
> > personally proceed as follow: write a draft document (even a very
> > brief one!) which summarizes the proposal so that people do not
> > need to dig into the thread to follow the evolution. Once we have
> > it, re-post it to the relevant lists (I'd say -devel, -policy,
> > -webapps) and ask for comments.
>
> I'll try to come up with something within the next 24 hours. Don't
> know yet if it's gonna be a DEP or just another mail but
> summarizing what we got so far sounds like a plan.
I think it would be best to have a wiki page that lists the problems
you are trying to solve and also possible pitfalls that have to be
taken into account. Then it is easier to check if a proposed solution
would solve the problems while not breaking anything else.
One of the pitfalls is apache2-suexec. It has the document root
compiled in and doesn't allow more than one document root.
Neil McGovern
> 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.
>
Sorry, I have to disagree with this approach. We would easily end up
with items in /usr/share/www/bugzilla and also in /usr/share/bugzilla,
how would you handle .inc files, for example?
> > - 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'm sorry, but I really don't see what this is trying to solve.
>From 5.1.1 of the webapps policy:
Web applications should be completely agnostic of the global document
root.
Both the above two points also cause issues with vhosting. How would you
register bugzilla with domain foo.bar, but not wibble.baz?
Many of these issues were discussed back in 2005 on the debian-webapps
list, leading to the webapps policy paper. It's a good read, please make
sure that you're aware of it :)
Neil
--
<blarson> I use three different operating systems: Sarge, Etch, and Sid.