[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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

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

Attachment: signature.asc
Description: Digital signature

Reply to: