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. Here
are the problems I know of:
- Some admins want to tightly control which cgi scripts are available,
beyond merely picking packages to install. For example you might want
to install analog without activating its cgi script.
- Some admins may need to use http://host/cgi-bin/ for their own
custom cgi scripts for historical or local policy reasons, but would
also prefer to be able to use cgi scripts from debian packages,
without tracking/linking them on a per-package basis.
- Some might want http://host/doc to be their own content, and not
the debian docs. I think the Debian web site is one example.
- 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.
- 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.
- /var/www violates the FHS. Of course the FHS has not laid out a place
for web stuff, though they might eventually with /srv. This proposal
does not mandate /srv, but it does lay groundwork to make it ok
for web servers to use /srv when it becomes part of the FHS, and to
help make it easier to transition to it.
- Any others?
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.
This brings me to the policy proposal:
--------------------------------------------------------------------------
11.5. Web servers and applications
11.5.1. Filesystem locations for web-accessible content
This section describes the filesystem locations that should be
used for web-accessible content provided by the Debian system.
CGI executable files are installed in /usr/lib/cgi-bin/<cgi-name>.
HTML documents for a package are stored in
/usr/share/doc/<package>.
Web applications should store static web-accessible files (icons,
non-documentation html pages, etc), under /usr/share/<package> and
/usr/lib/<package>. Variable web-accessible files (such as mrtg
graphs) may be stored under /var/lib/<package>.
Web applications may also store web-accessible files in /var/www/,
but use of this directory is deprecated and will become a bug in a
future edition of Debian policy.
All of the above content is gathered together in the directory
/var/lib/debian-www/, which includes links to /usr/lib/cgi-bin/,
and /usr/share/doc, and to which links can be added to content
in /usr/share/<package>, /usr/lib/<package>, /var/lib/<package>,
and /var/www (deprecated).
Packages should only add symlinks, and possibly subdirectories
to the /var/lib/debian-www/ directory, and not actual content.
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.
The following URLs may be used for Debian provided content, but
are deprecated in favor of the new URLs listed above:
http://<host>/cgi-bin/ for CGI programs.
http://<host>/doc for documentation.
11.5.3. Web server configuration and virtual hosts
Web servers should ship with a default configuration that may include
a default front page, specfic to that web server, at http://<site>/,
and must include http://<site>/debian-www/.
The web server should restrict access to http://<site>/debian-www/doc
so that only clients on the same host can read the documents. If the web
server does not support such access controls, then it should not provide
access at all, or ask about providing access during installation.
Web servers may default to using /var/www as their web document root.
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. /var/www/debian-www should be a
link to /var/lib/debian-www/. As this direcotry is not approved by the
FHS, use of /var/www is deprecated.
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. In any case, debian-www in that directory
should be a link to /var/lib/debian-www/, and the web server should
take care to not overwrite existing index.html files, etc in that
directory, and to clean up after itself when it is removed.
--------------------------------------------------------------------------
Here how the problems I listed at the top of this mail can be addressed
using the new system. Note that I'm using /srv/ as the web document roots
in these examples, mainly as it makes talking about vhosts easier, but they
are only examples.
- So you want to control every cgi programs that is enabled. Make
/var/lib/debian-www/cgi-bin your own directory, instead of a link
to /usr/lib/cgi-bin/, and add links to the cgi programs you want.
It should also be possible to make this vary by vhost if you wanted.
- So you want http://host/cgi-bin/ to be your own custom cgi scripts.
No problem, it is, debian cgi scripts are
http://host/debian-www/cgi-bin/.
- So you want http://host/doc/ to be your own content. No problem,
debian /usr/share/doc is at http://host/debian-www/doc/ (generally
where "host" is "localhost").
- So apache2 wants to provide its own index.html without conflicting
with the index.html of any other web server that might be installed,
while at the same time keeping the debian content available. Then
/srv/apache2/index.html can be apache2's web document root, and
http://<apache2-host>/debian-www/ stil works. In the short term,
while /srv is only theory, apache2 might go on using
/var/www/apache2-default as it does now, but with the addition of a
debian-www link in there to make it policy compliant.
- So you want to add a vhost that still includes the Debian content.
Just make sure that /srv/<vhost>/debian-www -> /var/lib/debian-www.
As to how we would transition to this, all of section 11.5.1. matches
current policy, or allows current policy (/var/www) but deprecates it.
11.5.2. allows the old URLs for cgi-bin and documentation to be preserved,
but deprecates them. 11.5.3. allows web servers to go on using /var/www
(or /var/www/apache2-default) as they do now.
So we could adopt this into policy without requiring immediate changes
to everything. First the change would be the web servers, which would
start providing debian-www links in their web document roots, and access
to the debian-www urls for their vhosts. Next would come package
providing cgi scripts, which could begin to document and link to the new
urls to the cgi scripts. And then packages that provide "web
application" content in /var/www would move over to the new set of
directories, and to providing symlinks to it in /var/lib/debian-www/.
After most stuff was converted to using the new system, web servers
would drop support for the old http://host/<doc> and http://<host>/cgi-bin/
and the deprecated parts would become policy violations.
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.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature