Re: draft proposal for a new web server policy
Hi all,
this is the last message that i am going to cross-post. We will
continue the discussion on debian-policy from now on.
On Sun, 7 Dec 2003, Joey Hess wrote:
> I'd prefer debian-policy.
Ok let's go for it.
> > 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.
Yes i agree.
> It would however, be a bit harder to transition to doing this.
imho harder or not.. it is needed so let's do it in the best way we can.
> > 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.
Yes, but acting only if the documentroot is totaly empty. I seriously
discourage to take any action if it is not. (I have references in BTS for
this statement ;))
> I'm not sure if there is any benefit to something standard like
> /usr/share/<httpd>/defaultdocumentroot. Maybe there is,
I see it as a possibility for us to ship the default pages that come with
a server. Look apache2 and apache that provides an entry page with a few
links. Usually noone modify them but since they are on the way they just
get wiped out. Installing them somewhere else imho gives the user the
possibility to keep them just changing the default documentroot and still
be able to link to them and so on, without too much pain in moving stuff
around (yes i am considering lazyness ;)).
> 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.
I am not sure i understand 100% what you mean here. Why can't we use it as
formal documenroot at install time, given that the user does not ask for a
different documentroot? In case where would you copy/link it?
> > > - 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).
Yes I agree on this but we can start getting ready from now since we are
working on it.
> Wouldn't a tool to handle vhosts be fairly specific to the httpd?
Yes as Daniel pointed out in his mail but i don't see big issue in doing a
small modular script to handle it.
> 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.
Yes they are. This is something that we should discuss between httpd's
maintainers
> 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.
Ok than we agree :-)
> > > 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.
To be hounest i did ask for the simple reason that when we tried to do
that our users were not happy, and that's why in apache we do not perform
any operation in that direction. I think we should work on the /srv
transition and the vhost management tool before we can setup stuff
automatically. At the point will be the user asking us to do something for
him/her and not us forcing something.
Thanks
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: