Re: draft proposal for a new web server policy
Hi Joey,
I am cross posting this answer but I think we should keep the
discussion on one mailinglist only. I leave up to you which one you think
is more appropriate.
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.
> - 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)
2) provide a default DocumentRoot for each webserver where we can store
the default pages we are actually shipping.
Personally i prefer 2 but of course i will let users decide what they
prefer.
> - 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.
> - 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 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)
> This brings me to the policy proposal:
>
> --------------------------------------------------------------------------
>
> 11.5. Web servers and applications
>
> 11.5.1. Filesystem locations for web-accessible content
>
[SNIP]
> 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.
> 11.5.2. URLs for web-accessible content
>
> This section specifies the URLs that should be used to access
> web-accessible content provided by the Debian system.
>
> The Debian web content will be available at the URL
> http://<site>/debian-www/. This includes
> http://<site>/debian-www/cgi-bin for CGI programs,
> http://<site>/debian-www/doc for documentation, and
> http://<site>/debian-www/<application> for web application data.
>
> These URLs should also work for any virtual hosts on the Debian
> system, unless the administrator has chosen to not include the
> Debian content on a virtual host.
I think this can be interpreted in 2 different ways but please correct me
if i am wrong. What I read here is:
- all the links/urls/references must be relative (so no encoding of <site>)
or (and this probably apply to apache* only):
- if debian-www is not found on the specific <site> try to access the
default one (that it is possible when specifing aliases at global level
other than per vhost base)
I am farly sure you mean the first, don't you?
> 11.5.3. Web server configuration and virtual hosts
>
[SNIP]
> 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).
> 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.)
> 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.
Thanks a lot
Fabio
--
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues
http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp00004.html
Reply to: