FHS and /var/www
 

FHS 2.3 specifies in
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
to use /srv for "Data for services provided by this system", for
example /srv/www for web root.
In the policy, the section
9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
specifies that FHS 2.3 is mandatory, except for some exception, and
the use of /var/www isn't included in that list.

Should we force all httpd:s to use /srv/www instead of /var/www, or
should an exception to the policy be added? Per
http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
support for /srv/www, but it's still defaulting to /var/www.

--
/Carl Fürstenberg <azatoth@gmail.com>

FHS and /var/www
 

On Sun, Jul 20, 2008 at 01:43:12AM +0200, Carl Fürstenberg wrote:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> specifies that FHS 2.3 is mandatory, except for some exception, and
> the use of /var/www isn't included in that list.
>
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added? Per
> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> support for /srv/www, but it's still defaulting to /var/www.
>
Personally, I would be against such a change.

On some systems, I NFS mount parts of /srv (or all of it). Such is not
the case for /var. That is, people know better than NFS mount /var.
That guarantee does not exist, since by nature /srv should mountable by
NFS (e.g., for a web cluster, or something like that).

Regards,

-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

FHS and /var/www
 

"Carl Fürstenberg" <azatoth@gmail.com> writes:

> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added?

I think there's no hardship if we support the FHS location, so an
exception shouldn't be made.

What do you mean by "force all [HTTP servers] to use /srv/www instead
of /var/www"? Why do you think that's desirable?

Conformance with the FHS would seem to require only that such files
must be addressible under the '/srv/www' location. I don't see support
for the "instead of /var/www" part of your question.

We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
that is, make '/srv/www/foo' the canonical location but allow a long
transition period where '/var/www/foo' is permitted as a symlink to
'/srv/www/foo'.

> Per http://wiki.debian.org/Apache2LennyGoals it states that apache2
> has support for /srv/www, but it's still defaulting to /var/www.

This could be dealt with as per above, along with the usual package
maintainer role of negotiating the Debian-specific change into the
upstream package.

--
“Always do right. This will gratify some people, and astonish |
` the rest.� —Mark Twain |
_o__) |
Ben Finney


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

FHS and /var/www
 

]] Ben Finney

| We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
| that is, make '/srv/www/foo' the canonical location but allow a long
| transition period where '/var/www/foo' is permitted as a symlink to
| '/srv/www/foo'.

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.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

FHS and /var/www
 

On Sun, Jul 20, 2008 at 08:58, Tollef Fog Heen <tfheen@err.no> wrote:
> ]] Ben Finney
>
> | We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
> | that is, make '/srv/www/foo' the canonical location but allow a long
> | transition period where '/var/www/foo' is permitted as a symlink to
> | '/srv/www/foo'.
>
> 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.
>
> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>

I just noticed in section 10.5 that /var/www should be used, so I have
filed an bug against the policy that 10.5 contradicts 9.1.


--
/Carl Fürstenberg <azatoth@gmail.com>

FHS and /var/www
 

Le Sun, Jul 20, 2008 at 01:43:12AM +0200, Carl Fürstenberg a écrit :
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> specifies that FHS 2.3 is mandatory, except for some exception, and
> the use of /var/www isn't included in that list.
>
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added? Per
> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> support for /srv/www, but it's still defaulting to /var/www.

Hi Carl,

I think that there is an confusion between where the web servers that
are packaged for Debian should look for the sites to serve, and where
the sites packaged for Debian should install their files.

Be it /var/www or /srv/www, nothing guarantees that a package shipping a
file in these directories will not conflict with local data, similarly
to /usr/local: the local administrator may have already placed a file
with as similar name, which would make the package uninstallable. In
contrary, the local administrator is not supposed to add anything that
does not come from a package in /usr/share nor /usr/lib.

For this reason, packages containing websites should use paths such as
/usr/lib/cgi-bin and /usr/share/package for their files.

Of course, this complexifies the task for the packager, as the http
daemons will not look by default in /usr/share/package. Definitely, some
code factorisation for registering the files and reload the
configuration would be most welcome. Maybe it could be some kind of goal
for Lenny+1?

Have a nice day,

--
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan


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

FHS and /var/www
 

This one time, at band camp, Carl Fürstenberg said:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> specifies that FHS 2.3 is mandatory, except for some exception, and
> the use of /var/www isn't included in that list.
>
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added? Per
> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> support for /srv/www, but it's still defaulting to /var/www.

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.

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

FHS and /var/www
 

On Sun, Jul 20, 2008 at 16:34, Stephen Gran <sgran@debian.org> wrote:
> This one time, at band camp, Carl Fürstenberg said:
>> FHS 2.3 specifies in
>> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
>> to use /srv for "Data for services provided by this system", for
>> example /srv/www for web root.
>> In the policy, the section
>> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
>> specifies that FHS 2.3 is mandatory, except for some exception, and
>> the use of /var/www isn't included in that list.
>>
>> Should we force all httpd:s to use /srv/www instead of /var/www, or
>> should an exception to the policy be added? Per
>> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
>> support for /srv/www, but it's still defaulting to /var/www.
>
> 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.
>
> Cheers,
>
>

So you "vote" for an exemption from FSH in this case, as per 9.1.1?


--
/Carl Fürstenberg <azatoth@gmail.com>

FHS and /var/www
 

This one time, at band camp, Carl Fürstenberg said:
> On Sun, Jul 20, 2008 at 16:34, Stephen Gran <sgran@debian.org> wrote:
> > This one time, at band camp, Carl Fürstenberg said:
> >> FHS 2.3 specifies in
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> >> to use /srv for "Data for services provided by this system", for
> >> example /srv/www for web root. In the policy, the section
> >> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> >> specifies that FHS 2.3 is mandatory, except for some exception, and
> >> the use of /var/www isn't included in that list.
> >>
> >> Should we force all httpd:s to use /srv/www instead of /var/www, or
> >> should an exception to the policy be added? Per
> >> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> >> support for /srv/www, but it's still defaulting to /var/www.
> >
> > 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.
>
> 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.
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

FHS and /var/www
 

On Sun, Jul 20, 2008 at 07:32:33PM +0200, Carl Fürstenberg wrote:
> On Sun, Jul 20, 2008 at 16:34, Stephen Gran <sgran@debian.org> wrote:
> > This one time, at band camp, Carl Fürstenberg said:
> >> FHS 2.3 specifies in
> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> >> to use /srv for "Data for services provided by this system", for
> >> example /srv/www for web root.
> >> In the policy, the section
> >> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> >> specifies that FHS 2.3 is mandatory, except for some exception, and
> >> the use of /var/www isn't included in that list.
> >>
> >> Should we force all httpd:s to use /srv/www instead of /var/www, or
> >> should an exception to the policy be added? Per
> >> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> >> support for /srv/www, but it's still defaulting to /var/www.
> >
> > 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.
> >
> > Cheers,
> >
> >
>
> So you "vote" for an exemption from FSH in this case, as per 9.1.1?
I believe he's claiming that there is no exemption needed, and I agree.

Quoting from the URL you provided:

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

The footnote implying that distributions MAY install files under /srv is
very far from a SHOULD. I think by far the easiest way for Debian to
"take care not to remove locally placed files" is to never but things
there in the first place.