This one time, at band camp, Steve Langasek said:
> On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> > > > 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.
>
> Actually, I think the sane default for a package that serves content to the
> network is to not serve any at all, so it's more relying on the directory
> *not* existing. But as you've shown, this is not a safe assumption either.
In a certain sense I agree that network services should do nothing by
default, but that is largely not been the 'Debian way' up to now -
if you install a new network service, it usually starts up and does
something by default. Admittedly, we're getting better, but I am a
little leery of pushing too far, when we can pretty easily ship a safe
and secure default default httpd install that works out of the box for
simple setups (as, say, we do now).
> > /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.
>
> /usr/local/www is explicitly forbidden by the FHS. So is /var/www. In the
> case of /srv/www, we're not forbidden to use it as a default, we're only
> forbidden to put content there by default.
/var/www is not actually explicitly forbidden, just implicitly forbidden.
It seems the relevant bit is the bit you quoted, which just says that
we shouldn't be placing new top level directories under /var unless they
have a system wide implication. In my view, a coordinated place to put
web apps meets that criteria for Debian, so the only thing we're missing
is a mail to the FHS list saying Debian would like to use that spot for
this purpose.[0]
> > 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".
>
> The process for deploying content under apache with the current settings is
> "copy it to /var/www". If we used /srv/www as a default, the process would
> be "mkdir -p /srv/www && ..." I don't think that's a hugely significant
> difference.
The crucial difference is that the process is actually 'ship
/var/www/<package>/file in the deb. Relying on that in /srv seems much
riskier, since the admin is free to already have something in place with
the same pathname that the install has now just overwritten.
> > > 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.
>
> Well, I think the possibility of running afoul of incompatible local
> configurations is a pretty good reason not to use /srv/www as a default, so
> I think that's absolutely a policy issue.
OK, fair enough. I just wanted to make it clear that I think this
issue is more important than some random paths I happen to have chosen
to serve content from, and didn't want to make it a personal discussion.
> Would the suggested /srv/www/localhost/htdocs as a default work for you?
> Apparently this is widely deployed on other distros, and seems to be
> entirely compatible with what you're doing. I think the chances are pretty
> slim that this directory exists *and* contains content that isn't meant to
> be served. Or, if "localhost" might imply content that's only meant to be
> served to the local host, then maybe /srv/www/default-site/htdocs?
Something like /srv/www/default-site/htdocs is certainly more appealing
(at least from point of view - it certainly fits with the tree structure
I currently have). I still don't think that shipping any files in /srv
in a deb is a good idea, for reasons I think I've outlined clearly
enough before. If we can't ship it in the deb, then I'm not sure we
should be setting it as the default document root either.
Maybe it would help me if we backed up a step:
I understand the dislike of /var/www WRT the FHS. However, it is a fairly
'safe' place for packaged distros to put files and directories. Does the
complexity of the move to /srv (must never overwrite local files, even
if they exist with the same path as in the .deb, can't remove files on
package remove, since it's entirely likely the admin has changed them,
etc) win us that much over leaving it where it is? I personally don't
see it as a net gain, but I'm willing to be convinced. I personally
think it would be simpler to send the mail to the FHS list announcing
that we plan to keep shipping things there, and ask them to add a
footnote that some distros might use that directory.[1]
[0] As this discussion is showing, 'a mail to the mailing list' is never
quite that simple.
[1] See [0]
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature