FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-04-2009, 03:50 PM
Stefano Zacchiroli
 
Default common, FHS-compliant, default document root for the various web servers

[ 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

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
 
Old 11-04-2009, 05:15 PM
Jan Hauke Rahm
 
Default common, FHS-compliant, default document root for the various web servers

On Wed, Nov 04, 2009 at 11:03:20AM -0600, Gunnar Wolf wrote:
> Stefano Zacchiroli dijo [Wed, Nov 04, 2009 at 05:50:01PM +0100]:
> > > 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?

I don't get it. This would of course solve the problem of FHS compliance
but apart from that it doesn't gain anything, does it?

My understanding of the problem is that we (as in package maintainers)
cannot drop our files in the document root of the system admin; there's
a chance of conflicting files. So, we avoid /var/www as this is meant to
be the sysadmin's place.

Currently packages handle the problem by looking for a safe place, i.e.
/var/cache/$package/html or something and provide a configuration for
the webserver (at least for apache2 this is done by several packages).
/var/www can remain docroot and the webserver still knows about the
newly installed webapp.

If we now introduce a new docroot, /var/www isn't the standard docroot
anymore, so
a) the webserver doesn't know about it and ignores the files of the local
admin,
b) the admin sees the new docroot and puts his/her files there (which is
wrong but I'm pretty sure it'll happen).

Now, do I totally misunderstand the issue here, or are we just moving
the /var/www problem to /var/lib/www?

Hauke
 
Old 11-04-2009, 06:09 PM
Stefano Zacchiroli
 
Default common, FHS-compliant, default document root for the various web servers

On Wed, Nov 04, 2009 at 07:15:55PM +0100, Jan Hauke Rahm wrote:
> I don't get it. This would of course solve the problem of FHS compliance
> but apart from that it doesn't gain anything, does it?
> Now, do I totally misunderstand the issue here, or are we just moving
> the /var/www problem to /var/lib/www?

No, actually we gain, but it was poorly explained (I've surely
contributed to that).

What I was aiming to is a kind of document root which is under full
control of the package manager; hence where the sysadm cannot touch
anything by hand. That's actually the only way to have a meaningful
package-based namespace.

The property I'd like is that if a package drops static files there
under a dir like package/, then those files automagically appear (in the
default vhost) as http://localhost/package/.

Now, written this way, it looks harder to implement, because it is a
kind of overlay over a default docroot (unless we assume the default
docroot is read-only for the sysadm, which doesn't look reasonable).

I see two solution to this:

- either the final URL is something like
http://localhost/debian/package/ (replace "debian" with whatever
prefix you like) and have some other per-web-server mechanism take
care of adding an Alias/link/whatever from "debian" to that new static
doc root

- or we add some kind of postinst-time registration mechanism (with all
the usual drawbacks) that check that new static doc root and register
every (new) dir there as Alias for the installed web servers. Assuming
that web servers can register themselves to the mechanism, that would
also solve the problem that webapp maintainers not necessarily have
the knowledge of the syntax of all available web servers

Any other idea?

Many thanks for sharpening the analysis, Jan.

Cheers.

PS please keep the -webapps Cc:, I believe it is truly relevant to this
thread
--
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
 
Old 11-04-2009, 07:48 PM
Jan Hauke Rahm
 
Default common, FHS-compliant, default document root for the various web servers

I'm commenting a bit between the paragraphs to sharpen my mind

On Wed, Nov 04, 2009 at 08:09:18PM +0100, Stefano Zacchiroli wrote:
> What I was aiming to is a kind of document root which is under full
> control of the package manager; hence where the sysadm cannot touch
> anything by hand. That's actually the only way to have a meaningful
> package-based namespace.

I agree. The files installed by the package manager must be seperated
from user/admin files.

> The property I'd like is that if a package drops static files there
> under a dir like package/, then those files automagically appear (in the
> default vhost) as http://localhost/package/.

That would mean dropping all files in whatever dir is configured (in all
available web servers) as DocRoot.

> Now, written this way, it looks harder to implement, because it is a
> kind of overlay over a default docroot (unless we assume the default
> docroot is read-only for the sysadm, which doesn't look reasonable).

Right, either the admin can (and will) write to the DocRoot (which was
meant to be reserved for the package manager), or we need two DocRoots
configured which I don't think is possible with common web servers.

> I see two solution to this:
>
> - either the final URL is something like
> http://localhost/debian/package/ (replace "debian" with whatever
> prefix you like) and have some other per-web-server mechanism take
> care of adding an Alias/link/whatever from "debian" to that new static
> doc root

Like all packages drop their files in /var/lib/www/package and some
default package (or the web server itself) drops a symlink
/var/www/debian -> /var/lib/www ?
This would again lead to at least one file name in the sysadmin's space
that he/she can't use which is what we try to avoid in the first place.

> - or we add some kind of postinst-time registration mechanism (with all
> the usual drawbacks) that check that new static doc root and register
> every (new) dir there as Alias for the installed web servers.

That is basically what happens today in many cases, except that the
files aren't dropped in one location but rather in /var/cache/$package
or similar. The package's postinst registers the new files/dirs with the
web servers (usually just apache2 and/or lighttpd).

> Assuming that web servers can register themselves to the mechanism,
> that would also solve the problem that webapp maintainers not
> necessarily have the knowledge of the syntax of all available web
> servers

You mean like a trigger that is dealt with by any web server installed?

> Any other idea?

Actually, I don't see a way to implement that (but then I'm probably not
the best code writer). It would be really nice if the web servers could
somehow register themselves for this but I think in the end this is
really what webapps-common was aimed at, isn't it? Except the
self-registering of web servers webapps-common could solve this all. A
package build-depends on it and gets provided with necessary
post{inst,rm} lines to register with known web servers. Considering that
there are that many web servers in the archive, it should be managable
for webapps-common maintainers to keep up2date with those.

So, after all I think we need some manpower in webapps-common and we
have a solution. Or not?

> Many thanks for sharpening the analysis, Jan.

You're welcome, although I prefer to be called Hauke. I'm a
middle-name-user

> PS please keep the -webapps Cc:, I believe it is truly relevant to
> this thread

Ack, sorry for dropping it before.

Hauke
 
Old 11-05-2009, 07:00 AM
Stefano Zacchiroli
 
Default common, FHS-compliant, default document root for the various web servers

On Wed, Nov 04, 2009 at 09:48:25PM +0100, Jan Hauke Rahm wrote:
> > Now, written this way, it looks harder to implement, because it is a
> > kind of overlay over a default docroot (unless we assume the default
> > docroot is read-only for the sysadm, which doesn't look reasonable).
> Right, either the admin can (and will) write to the DocRoot (which was
> meant to be reserved for the package manager), or we need two DocRoots
> configured which I don't think is possible with common web servers.

... or we find a technical way to enforce a kind of overlay, which is
what the two alternative solutions I advanced try to do.

> > - either the final URL is something like
> > http://localhost/debian/package/ (replace "debian" with whatever
> > prefix you like) and have some other per-web-server mechanism take
> > care of adding an Alias/link/whatever from "debian" to that new static
> > doc root
>
> Like all packages drop their files in /var/lib/www/package and some
> default package (or the web server itself) drops a symlink
> /var/www/debian -> /var/lib/www ?
> This would again lead to at least one file name in the sysadmin's space
> that he/she can't use which is what we try to avoid in the first place.

Well, everything is not black or white, we are not really forcing
anything on the sysadm. First of all it is just one file and only for a
single vhost in the default configuration (not in all possible
configuration the sysadm might prepare later on), and finally for all
web servers that support Alias-like directives it is not even a file: it
is just a config line that can be easily commented out.

> > Assuming that web servers can register themselves to the mechanism,
> > that would also solve the problem that webapp maintainers not
> > necessarily have the knowledge of the syntax of all available web
> > servers
>
> You mean like a trigger that is dealt with by any web server installed?

Yes, exactly.

> Actually, I don't see a way to implement that (but then I'm probably not
> the best code writer). It would be really nice if the web servers could
> somehow register themselves for this but I think in the end this is
> really what webapps-common was aimed at, isn't it? Except the

I believe so. If we go forward with that, that would be a first step
toward uniforming the packaging of webapps, whether it is called
webapps-common or not I personally couldn't care less.

> self-registering of web servers webapps-common could solve this all. A
> package build-depends on it and gets provided with necessary
> post{inst,rm} lines to register with known web servers. Considering that
> there are that many web servers in the archive, it should be managable
> for webapps-common maintainers to keep up2date with those.

No, not really. With webservers registering themselves I was thinking at
something like each maintainer of a webserver package providing a script
(which a specified API which is the same for all webservers). That
script will be in charge of mapping one generic Alias directive (coming
from a single webapp package) to the way of implementing that directive
in the specific webserver. This way the webapps-common infrastructure is
no longer in charge of maintaining neither the knowledge nor the
implementation of every single webserver, it is only in charge of
maintaining the generic infrastructure.

> So, after all I think we need some manpower in webapps-common and we
> have a solution. Or not?

That's out of doubt :-)

> > Many thanks for sharpening the analysis, Jan.
>
> You're welcome, although I prefer to be called Hauke. I'm a
> middle-name-user

Ooops, sorry :-/

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
 
Old 11-05-2009, 08:21 AM
Jan Hauke Rahm
 
Default common, FHS-compliant, default document root for the various web servers

On Thu, Nov 05, 2009 at 09:00:12AM +0100, Stefano Zacchiroli wrote:
> On Wed, Nov 04, 2009 at 09:48:25PM +0100, Jan Hauke Rahm wrote:
> > self-registering of web servers webapps-common could solve this all. A
> > package build-depends on it and gets provided with necessary
> > post{inst,rm} lines to register with known web servers. Considering that
> > there are that many web servers in the archive, it should be managable
> > for webapps-common maintainers to keep up2date with those.
>
> No, not really. With webservers registering themselves I was thinking at
> something like each maintainer of a webserver package providing a script
> (which a specified API which is the same for all webservers). That
> script will be in charge of mapping one generic Alias directive (coming
> from a single webapp package) to the way of implementing that directive
> in the specific webserver. This way the webapps-common infrastructure is
> no longer in charge of maintaining neither the knowledge nor the
> implementation of every single webserver, it is only in charge of
> maintaining the generic infrastructure.

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?

Hauke
 
Old 11-05-2009, 01:05 PM
"Giacomo A. Catenazzi"
 
Default common, FHS-compliant, default document root for the various web servers

Stefano Zacchiroli wrote:

[ 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)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-05-2009, 02:39 PM
Stefano Zacchiroli
 
Default common, FHS-compliant, default document root for the various web servers

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 ...)

- 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 ...

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
 
Old 11-05-2009, 02:50 PM
Jan Hauke Rahm
 
Default common, FHS-compliant, default document root for the various web servers

On Thu, Nov 05, 2009 at 03:05:07PM +0100, Giacomo A. Catenazzi wrote:
> 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
 
Old 11-06-2009, 11:11 AM
Harald Braumann
 
Default common, FHS-compliant, default document root for the various web servers

On Thu, 5 Nov 2009 16:39:06 +0100
Stefano Zacchiroli <zack@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
 

Thread Tools




All times are GMT. The time now is 09:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org