This one time, at band camp, Steve Langasek said:
> On Mon, Jul 21, 2008 at 01:14:05AM +0100, Stephen Gran wrote:
> > This one time, at band camp, Steve Langasek said:
> > > On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:
> > > > > So you "vote" for an exemption from FSH in this case, as per
> > > > > 9.1.1?
>
> > > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>
> > > > "Therefore, no program should rely on a specific subdirectory
> > > > structure of /srv existing or data necessarily being stored in /srv.
>
> > > I think it's perfectly in keeping with other parts of policy to ship
> > > our webservers with /srv/www as the default webroot, and leave it up
> > > to the administrator to symlink web applications into that root to
> > > enable them (or change the web root, or use aliases, etc). In
> > > particular, Policy 11.5.4 says that web applications should avoid
> > > storing files in the web document root if possible.
>
> > So you think it's a good idea to ignore the the sentence above?
>
> No, I don't think that using it as a default webroot is "rely[ing] on a
> specific subdirectory structure of /srv existing or data necessarily being
> stored in /srv", because the web server can be reconfigured to look
> elsewhere.
If the apache or other httpd debs ship the directory and then set it as
the default webroot, surely that is 'relying' on the directory existing?
Unless you don't think that packages need to ship with sane working
defaults, which strikes me as not the sort of argument you normally make.
/srv/ is, AIUI, the admin's playground to structure as they see fit,
much like /usr/local. I am fairly sure you wouldn't advocate a webroot
of /usr/local/www, so I'm having a hard time seeing why this is this better.
> > I agree that it's a bad idea for applications to store things under the
> > webroot in general, but that's a seperate issue altogether to changing
> > what the default webroot points to. If we could keep the seperate issues
> > seperate for the moment, I think it would be helpful.
>
> If your objection to using /srv/www as the default web root isn't about
> applications storing files there, then why do you object to it? Is it
> because it would be "wildly inappropriate" on your systems?
My objection is because the FHS tells us that we can't rely on a
particular layout of /srv/ - making the webroot be /srv/www is relying on
a particular layout of /srv. This is an obvious contradiction to me,
but I see that you disagree. I'm just not sure how you can reconcile
"we want to ship applications that work out of the box" and "we have no
idea what the directory structure will be on the target system".
I happen to have an incompatible layout on my webservers, so it would
seriously annoy me to have this suddenly be the default, but that's a
personal, rather than a policy, issue.
> > a) applications installing random files under web root - bad
> > b) Changing httpds to ship a web root that either doesn't exist or would
> > be wildly inappropriate on every system I admin - also bad.
>
> Does "wildly inappropriate" mean that shipping such a default would
> incorrectly expose data to the network that wasn't meant to be exposed?
Yes. My webservers tend to use something like
/srv/www/<sitename>/{config,cgi-bin,htdocs,lib,logs,blah,blah}/ as the
normal layout. Exposing /srv/www as a document root would give access to
lots of things that are not public in many cases - we tend to not bother
with .htaccess files since config/ and so on are not under the webroot.
However, as I said, it being wrong for me is personal - the fact that
the FHS tells us that /srv/ is the domain of the local admin to reorder
however they feel like is enough to argue against relying on /srv for
anything packaged.
> > Doing the change you recommend also has the downside of guaranteeing
> > that no web application that has to ship files under the web root can
> > work out of the box. Admittedly these applications are probably silly,
> > but not currently buggy.
>
> Well, I consider that an upside rather than a downside; I don't think
> there's any excuse for a package enabling a web app by default, and would be
> happy to see such packages declared buggy - which I agree could be handled
> separately from /srv/www.
Agreed.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature