Fabio Massimo Di Nitto wrote: > 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.
I'd prefer debian-policy. > > - 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) I would be ok with this, except I think that it should be /debian-www/serverinfo to avoid eating more namespace. It would however, be a bit harder to transition to doing this. > 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. So the idea of the proposal is that a web server, after choosing the directory to use as the document root (possibly prompting the user), would set it up with its index.html and a link to debian-www. Presumably index.html is copyied in from somewhere, but the proposal also leaves it open to be created from a postinst, or not included at all. I'm not sure if there is any benefit to something standard like /usr/share/<httpd>/defaultdocumentroot. Maybe there is, if some program external to the web server wants to set up a later vhost for that web server. In any case, it would not be a formal DocumentRoot, but would instead be more of a document skeleton directory that is copied or linked into place. > > - 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. I'm sure personally that this will be /srv in the future (but time will tell). Wouldn't a tool to handle vhosts be fairly specific to the httpd? Under this proposal it could create the debian-www link, could copy in files from a /usr/share/<httpd>/defaultdocumentroot if we go that route, but would have to hook into something that knows about the web server to configure it. Anyhow, the details of that are, I hope, outside this proposal. > > 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? I meant the first (the second would break at least vhost aware cgi scripts like mailman). However, I hadn't thought that relative urls would be a consequence of it; it's ok if mailmail encodes site in an url, as long as that url is generated on the fly for a given site. Certianly no urls encoding the site name in static content. > > 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.) You're right, to meet current practice (which I hate..), the proposal should be changed to s/should remove those files/ought to remove those files (but may not for legacy web servers)/ or something like that. I think it would be better for the web server on a non-default docroot to try to set it up to conform to the policy. As it stands, the proposal would require web servers that prompt for a non-default documentroot to put the debian-www link in it, and encourages setting up a default page, but does not require that. -- see shy jo
signature.asc
Description: Digital signature
