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-20-2008, 06:15 PM
"Carl Fürstenberg"
 
Default FHS and /var/www

On Sun, Jul 20, 2008 at 19:58, Stephen Gran <sgran@debian.org> wrote:
> 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.
>
> [...]
>
> Distributions must take care not to remove locally placed files in these
> directories without administrator permission."
>
>
> I don't think there's any excemption needed. The FHS already makes it
> essentially impossible for distributors to place anything under /srv.
> Not putting anything there means it's a fairly daft idea to have a
> webroot pointing there and expect anything to work out of the box.

I was refering to the use of /var/www, which isn't FHS valid, and no
excemption is made in the policy about that.

--
/Carl Fürstenberg <azatoth@gmail.com>
 
Old 07-20-2008, 06:36 PM
Stephen Gran
 
Default FHS and /var/www

This one time, at band camp, Carl Fürstenberg said:
> On Sun, Jul 20, 2008 at 19:58, Stephen Gran <sgran@debian.org> wrote:
> >
> > I don't think there's any excemption needed. The FHS already makes it
> > essentially impossible for distributors to place anything under /srv.
> > Not putting anything there means it's a fairly daft idea to have a
> > webroot pointing there and expect anything to work out of the box.
>
> I was refering to the use of /var/www, which isn't FHS valid, and no
> excemption is made in the policy about that.

The FHS is not an exhaustive list of every directory on the system, so
I'm not convinced that introducing a new directory needs an excemption
either. We don't currently have an excemption for /etc/default, for
example.

But to short circuit this, I vote for leaving it alone, and not changing
anything in policy.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 07-20-2008, 06:56 PM
Steve Langasek
 
Default FHS and /var/www

On Sun, Jul 20, 2008 at 07:36:33PM +0100, Stephen Gran wrote:

> > I was refering to the use of /var/www, which isn't FHS valid, and no
> > excemption is made in the policy about that.

> The FHS is not an exhaustive list of every directory on the system, so
> I'm not convinced that introducing a new directory needs an excemption
> either. We don't currently have an excemption for /etc/default, for
> example.

"Applications must generally not add directories to the top level of /var.
Such directories should only be added if they have some system-wide
implication, and in consultation with the FHS mailing list."

FHS 2.3, Chapter 5.

--
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-20-2008, 07:09 PM
Steve Langasek
 
Default FHS and /var/www

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.

> [...]

> Distributions must take care not to remove locally placed files in these
> directories without administrator permission."

> I don't think there's any excemption needed. The FHS already makes it
> essentially impossible for distributors to place anything under /srv.
> Not putting anything there means it's a fairly daft idea to have a
> webroot pointing there and expect anything to work out of the box.

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.

--
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-20-2008, 09:24 PM
Ben Finney
 
Default FHS and /var/www

Edward Allcutt <edward@allcutt.me.uk> writes:

> <quote>
> Purpose
>
> /srv contains site-specific data which is served by this system.
> </quote>
>
> To me "site-specific" implies "not installed by the package manager".
> I believe it's quite reasonable for apache, CVS, etc. to set up a
> default location under /var so long as the local administrator can
> configure them to use whichsoever path is preferred according to local
> policy.

I find this convincing, in combination with the rest of this thread.

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

--
“He that would make his own liberty secure must guard even his |
` enemy from oppression.” —Thomas Paine |
_o__) |
Ben Finney


--
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:02 AM
Brendan
 
Default FHS and /var/www

On Sunday 20 July 2008, Steve Langasek wrote:
> On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote:

> 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

I think that this is a terrible idea. Leave well-enough alone.


--
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:14 AM
Stephen Gran
 
Default FHS and /var/www

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

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.

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.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 07-21-2008, 01:19 AM
Steve Langasek
 
Default FHS and /var/www

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.

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

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

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

--
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, 01:55 AM
Stephen Gran
 
Default FHS and /var/www

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 |
-----------------------------------------------------------------
 
Old 07-21-2008, 03:17 AM
Joey Hess
 
Default FHS and /var/www

Tollef Fog Heen wrote:
> You can't know the structure of /srv, see the FHS rationale:
>
> The methodology used to name subdirectories of /srv is unspecified
> as there is currently no consensus on how this should be done. One
> method for structuring data under /srv is by protocol, eg. ftp,
> rsync, www, and cvs. On large systems it can be useful to structure
> /srv by administrative context, such as /srv/physics/www,
> /srv/compsci/cvs, etc. This setup will differ from host to
> host. Therefore, no program should rely on a specific subdirectory
> structure of /srv existing or data necessarily being stored in
> /srv. However /srv should always exist on FHS compliant systems and
> should be used as the default location for such data.
>
> As long as the structure is unspecified, it is just about impossible
> to me to have a sane default pointing to anywhere in /srv (except
> directly at /srv itself) as that directory might very well not exist.
> I would argue shipping a /srv/www is a bug if the site does not use
> that layout.

Hmm, my reading of this has been that programs should default to using a
directory in /srv (it says "should be used as the default location for
such data"), but have to allow being configured to use any other
directory in or out of /srv for thier data. Also that if program A is
looking for program B's data, it cannot just assume that it's in some
default location in /srv.

So, for example, some of the tftp daemons in Debian have been configured
to default to using /srv/tftpboot; they still have to be configurable to
use other paths like /var/lib/tftpboot or /srv/intranet/tftpboot. And a
program like the new di-netboot-assistant can't assume that /srv/tftpboot
is the right place to dump files -- but it could ask with that as a
default.

I think that there's room for Debian to establish distro-wide policies
for the *default* directories in /srv, as a suppliment to the FHS.

--
see shy jo
 

Thread Tools




All times are GMT. The time now is 07:54 AM.

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