FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-21-2008, 03:22 AM
Joey Hess
 
Default FHS and /var/www

Stephen Gran wrote:
> Please no. The layout of /srv/ is specifically said to be undetermined,
> so we can't actually rely on any paths in /srv/. I think the current
> setup is fairly good, actually - by default simple site layouts work out
> of the box, and don't interfere with more complicated setups that are
> free to use arbitrary hierarchies in /srv.

A problem with not encouraging admins to put their data in /srv by
default is that while backing up /srv is easy, finding the right
directories to back up in /var is harder (especially when they're
non-fhs ones like /var/www).

--
see shy jo
 
Old 07-21-2008, 03:35 AM
Joey Hess
 
Default FHS and /var/www

Ben Finney wrote:
> I'm now in favour of '/srv' being out of bounds for the package
> manager, like '/usr/local'.

The FHS is pretty amusing on this topic:

Distributions must take care not to remove locally placed files in these
directories (/srv/*) without administrator permission. [20]

[20] This is particularly important as these areas will often contain both
files initially installed by the distributor, and those added by
the administrator.

So the FHS allows a package to install files to /srv (with care), but
they cannot be removed when the package is -- so it would be a very
strange package that did so. It also seems to allow packages to
install/remove empty directories in /srv similarly to the way policy
allows in /usr/local.

--
see shy jo
 
Old 07-21-2008, 11:26 AM
Gabor Gombas
 
Default FHS and /var/www

On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:

> 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.

You're not alone with such a setup. /srv is becoming popular exactly
because it does not conflict with the OS.

Quoting the FHS:

"This main purpose of specifying this is so that _users_ may
find the location of the data files for particular service, ..."

Note how it only talks about users, not the operating
system/distribution.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-21-2008, 12:46 PM
William Pitcock
 
Default FHS and /var/www

Hi,

On Mon, 2008-07-21 at 13:26 +0200, Gabor Gombas wrote:
> On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
>
> > 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.
>
> You're not alone with such a setup. /srv is becoming popular exactly
> because it does not conflict with the OS.
>
> Quoting the FHS:
>
> "This main purpose of specifying this is so that _users_ may
> find the location of the data files for particular service, ..."
>
> Note how it only talks about users, not the operating
> system/distribution.
>
> Gabor

I would say that the redhat default of /srv/www/localhost/htdocs might
be a good option.

William
 
Old 07-21-2008, 02:44 PM
Stefano Zacchiroli
 
Default FHS and /var/www

On Sun, Jul 20, 2008 at 11:35:09PM -0400, Joey Hess wrote:
> The FHS is pretty amusing on this topic:

Agreed ...

> Distributions must take care not to remove locally placed files in these
> directories (/srv/*) without administrator permission. [20]
>
> [20] This is particularly important as these areas will often contain both
> files initially installed by the distributor, and those added by
> the administrator.
>
> So the FHS allows a package to install files to /srv (with care), but
> they cannot be removed when the package is -- so it would be a very

... but I've a lighter interpretation of the text you quoted: a package
can for example have a configuration dialog upon removal (or maybe only
upon purging) that ask whether or not to remove stuff placed under /srv.

Cheers.

--
Stefano Zacchiroli -*- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled / All one has to do is hit the
XML stuff is so ... simplistic -- Manoj / right keys at the right time
 
Old 07-21-2008, 03:27 PM
Joey Hess
 
Default FHS and /var/www

Stefano Zacchiroli wrote:
> ... but I've a lighter interpretation of the text you quoted: a package
> can for example have a configuration dialog upon removal (or maybe only
> upon purging) that ask whether or not to remove stuff placed under /srv.

You are correct.

I don't think that we should add any additional restrictions in policy;
the FHS is restrictive enough about what packages can do with /srv.

--
see shy jo
 
Old 07-21-2008, 04:16 PM
Steve Langasek
 
Default FHS and /var/www

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/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-21-2008, 05:32 PM
Stephen Gran
 
Default FHS and /var/www

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 |
-----------------------------------------------------------------
 
Old 07-21-2008, 07:33 PM
Franklin PIAT
 
Default FHS and /var/www

On Mon, 2008-07-21 at 07:46 -0500, William Pitcock wrote:
> On Mon, 2008-07-21 at 13:26 +0200, Gabor Gombas wrote:
> > On Mon, Jul 21, 2008 at 02:55:25AM +0100, Stephen Gran wrote:
> >
> > > 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.
> >
> > You're not alone with such a setup. /srv is becoming popular exactly
> > because it does not conflict with the OS.

Agree.

In a few years from now, many packages will have migrated their stuffs
from /var/lib/* to /srv/$1/localhost/.

At that time, the whole benefit of /srv being a clean location would be
voided.


> I would say that the redhat default of /srv/www/localhost/htdocs might
> be a good option.

BTW, My preferred scheme is more like /srv/localhost/www/htdocs (as it
allows to easily synchronize /srv/localhost/* ).

Franklin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-21-2008, 08:14 PM
Franklin PIAT
 
Default FHS and /var/www

On Mon, 2008-07-21 at 18:32 +0100, Stephen Gran wrote:
> 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 -

It seems that the IT world is divided in two groups of people :
* Those who expects to have network services enabled with some
"reasonable defaults" when they install a package.
* Those who expects to have network services disabled by default
when they install a package.

Can Debian satisfy them both ? Well... why not !

The policy could state that network service's init.d script must check
for a file named "/etc/no-paranoia"[1].
If the doesn't exists, the init.d script should refrain from starting
the network service, unless the file /etc/default/ contains
"PARANOIA=allow-start", to be added manually by paranoid admins.


[1] one is invited to find a better name

> > 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[..]

Even though I don't like the idea of using /srv by default, I must admit
that the name "*/default-site/*" is the best name I've ever seen. It's
more explicit than /var/www, and it make it clear that this is the
default (v)host.

Franklin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 09:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org