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

Re: draft proposal for a new web server policy



On Sun, Dec 07, 2003 at 10:58:17AM +0100, Fabio Massimo Di Nitto wrote:
> On Sat, 6 Dec 2003, Joey Hess wrote:
> > Maybe it's time to think about amending section 11.5. of policy (Web
> > servers and applications) to address some of the problems with it.
> 
> indeed it is.

It's long, long, long overdue.

> >  - Some web servers (eg apache2) can cooexist with other web servers
> >    installed concurrently. But historically we've had the debian web
> >    server install a default /var/www/index.html particular to that
> >    server, and only one web server can do that at a time. So apache2
> >    currently violates debian policy by using a different directory as
> >    its web server root. Which leads to many other administration
> >    problems, such as anything dropped in /var/www not being available
> >    under apache2.
> 
> We should consider 2 options to address this problem:
> 
> 1) provide a single default DocumentRoot for all webservers with a common
>    Debian entry page (as suggested by aj and DanielS on irc) and a
>    possible /serverinfo/ to let the user verify immediatly which server is
>    accessing (in case of multiple web servers running at the same time as
>    suggested by DanielS)

This is, of course, my preferred option.

> >  - If you use vhosts, you can only have one pointing to /var/www,
> >    so only one will get the debian content provided there. To add it to the
> >    others, you have to maintain lots of symlinks.
> 
> Even if it is not our task I would like to at least suggest users a common
> schema on where to store vhosts and possibly in a future having a small
> tool to handle them. It would make life easier for users approching the
> first time httpd.

vhost-base was a (shockingly-implemented) attempt at this - I still have
sources kicking around for anyone who doesn't mind looking at abhorrent
Perl that largely doesn't work to see where I was going.

> >  - Any others?
> 
> From a user point of view nothing more comes in my mind. As one of the
> apache maintainer i would like to see the default DocumentRoot situation
> clear in policy from the beginning before start having 200 different
> implementation, one from each httpd.

I think everything needs to be clear in policy. apache2 is, so far, the
only httpd to yet have tackled the virtual host problem, thank <insert
deity here>.

> > I notice that many of these come down to a namespace problem. We have
> > appropriated the default top-level namespace of the web server for
> > Debian-provided content, which doesn't give the admin enough control. If
> > they take back control, for example by changing the web document root to
> > /home/web or /srv/web, and creating their own cgi-bin directory, then
> > they lose all the benefits of the Debian integration. Unfortunatly many
> > hrefs are absolute, and so they break when you do things like this, so
> > even making http://host/debian link to all the debian provided stuff is
> > not feasable without a lot of work.
> 
> Just FYI there was a proposal to address the /cgi-bin/ problem but your is
> more complete and addresss that problem as well. (#167513)

I'm not sure I love the /debian-www/ bit; it's a bit aesthetically
displeasing, but to each their own. Good idea otherwise, however.
	
> >      Web applications should store static web-accessible files (icons,
> >      non-documentation html pages, etc), under /usr/share/<package> and
> >      /usr/lib/<package>.
> 
> Perhaps the DocumentRoot can be addressed here with something like
> /usr/share/<package>/defaultdocumentroot (or something similar, name is
> not important for me..) if we will agree to use the 2nd solution i
> proposed above, and users will still be able to change the default
> DocumentRoot to point where they prefer without losing any advantage of
> the Debian infrastructure.

Slightly on-topic, I was saying to Fabio on IRC that every httpd could
provide /usr/share/<package>/serverinfo or such, for /serverinfo (as
discussed further up). This could be status for the apaches, vague
information for boa/lighter servers, or whatever.

> >      If they include an index.html (or localised index.html.ll or similar
> >      files) there, they must take care to not overwrite files created by
> >      the administrator, or by other web servers, and removal of the web
> >      server should remove those files.
> 
> I think the removal has to be done if we isolate these files where the
> user is not supposed to touch them. At this point in time where we use
> /var/www we do not touch them. (at least apache doesn't).

This is why I believe having a common root and /serverinfo/ is a good
idea. This way, we can have a default Debian index.html, chock-full of
information, including a, 'Yo! Want to see <a href="/serverinfo">how
this server's going</a>?', and admins could override this easily. All
this infrastructure could be included in a httpd-base package, or such
(possibly combining with a bit of the old vhost-base stuff?).

> >      Alternatively, web servers may choose to use a different directory
> >      as their web document root. It is acceptable to prompt the user
> >      for what directory to use.
> 
> apache already does that but we do not touch or even investigate the
> contents of a non-default documentroot. In case of default we only check
> for index.html at install time. Would this behaviour be accepted in this
> proposal? We mainly use this approch to avoid any risk of overwriting a
> user installed index.html (other methods have been failing, see bts for
> reference.)

I suppose the other achoice is to put all Debian content in
/debian-www/, and only have index.html redirecting to /debian-www/, so
that way the user only has to overwrite a ~100-byte file. Or something.

> > At this time, I'm seeking comments, but not seconds for this proposal.
> > In particular, I'm interested in any problems with the current web
> > policy which I did not address.
> 
> You did a really good job.

Yes. On behalf of someone who tried and failed to implement this
(vhost-base, the remenants of which can still be seen in apache2[1]),
thankyou very much for finally enumerating this.

:) d

[1]: sites-{available,enabled} and all that infrastructure used to be
     managed by vhost-base, until Thom decided (rightly, in 20-20
     hindsight) that it was a stupid idea - or, at least, a
     stupidly-implemented good idea. mods-{available,enabled} stems from
     the same thinking.

-- 
Daniel Stone                                                <daniels@debian.org>
Debian X Strike Force:                    http://people.debian.org/~branden/xsf/

Attachment: pgpdU3qgdyWct.pgp
Description: PGP signature


Reply to: