I'm not subcribed to the list, so apologies for the broken
threading...
> Bryan Whitehead wrote:
>
> My opinion is /srv is kinda lame idea to begin with. Where we put
> our data for services seems to be a personal preference.
>
One reason the proposal came up for /srv is that the fhs is commonly
asked by sysadmins for guidance as to where they should put data for
services. On linux at least, /var/www and /home/www is common, though
neither seem to fit into the definitions for those areas.
> In other words, this change looks like they want to enforce a
> certain way of locating / arranging data for various services. I say
> leave this out... this pulls us away from how other UNIX's deal with
> this problem: allow the SA to choose his own scheme.
The structure under /srv has been left undefined, with
some suggestions as a non-normative rationale.
> Also the description seems pretty stupid, "/srv - data generated by
> users for the services the system offers". Can't this also mean data
> in /home? if the system offers samba as a service should the data
> now go in /srv ? What about nfs exported home directories do they
> belong in /srv now?
No, the rationale states that data of interest to a specific user
should go in that user's home directory. Here is the full text of the rationale:
"This main purpose of specifying this is so that users may find the
location of the data files for particular service, and so that
services which require a single tree for readonly data, writable data
and scripts (such as cgi scripts) can be reasonably placed. Data that
is only of interest to a specific user should go in that users home
directory.
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 these locations."
> The intention of unifying the location of where data is kept is a
> semi-good idea for those who need a decision made for them, but it
> will be largly ignored by shops who already have a scheme in place
> and don't want to have thier linux machines differ from their
> Solaris/AIX/IRIX machines.
Yup, we don't have FHS police :-) Admins do make local changes. In
this case its more about setting up defaults for applications/packages
to place or access their data.
> The /media entry doesn't bother me... but I'd rather see them
> redefine /mnt to be what most use it for anyway: exactly what they
> propose /media does. I can already visualize my inbox filling up for
> the mdk10 upgrade, "/mnt/cdrom is GONE!!! please FIX!!!!"
At the moment on linux we have /mnt/cdrom, /cdrom and /media/cdrom
used. The main objection to /mnt/cdrom has been the older unix
tradition of using /mnt as a temporary mount kind of scratch area.
Though I do wonder how much this really matters these days.
Chris
--
[EMAIL PROTECTED]
IBM OzLabs Linux Development Group
Canberra, Australia
