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.
> /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.
> 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.
> > 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.
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?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
