Bryan, I think you managed to drop the cc, I don't think Chris is cc'ed.
>> 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.
>
> Is it so hard to broaden the definition of /var then?
IMHO the definition doesn't get any broader anyway. In the case where you
have a large volume of data in /var/www, you most likely have a database
supporting that data in /var/lib/mysql, and you would have planned ahead
for this and created a large /var, or partitioned it better to allow quota
use etc.
There is a distinction between the types of data we have in /var though.
We have data that could be used by multiple pieces of software (/var/www
by any web server, /var/spool/mail by different MTAs), then we have data
that is specific to the software (/var/spool/postfix, /var/spool/imap,
/var/lib/urpmi, /var/lib/mysql etc etc).
>
>> The structure under /srv has been left undefined, with
>> some suggestions as a non-normative rationale.
>
> Being that the structure under /srv is left undefined we still end up
> with the same mess. /srv/database/postgresql or /srv/postgresql or
> /src/disk1/postgresql....
Yes, I see no advantage to just moving most of /var into /srv.
>
> This does not solve a problem: /srv will still be a mess from distro to
> distro. Or, even worse, some distros may ignore /srv sticking to the
> previous LSB/FHS (undefined) waiting for clarification or changes in
> future versions of the FHS. So we'll end up with both /var /home /srv
> depending on the flavor of linux.
And symlink mess between them, some symlinks in /var pointing to /srv/X,
some symlinks in /var/lib pointing to /srv/Y etc.
>
>> 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.
IMHO, scripts don't belong in /var (for samba we place supporting scripts
in shell and perl in /usr/share/samba or /usr/share/samba3 which is IMHO a
more sane location), but neither do they belong in some other location. We
use /var/lib/samba for other non-user-specific data that should be
available by default, so we have /var/lib/samba/printers for Windows
printer drivers, /var/lib/samba/profiles for user profiles (which
shouldn't really be in $HOME) and /var/lib/samba/netlogon for login
scripts etc. I don't see the sense in placing this all in /srv.
On existing servers, this will only mean more headaches for admins who
must either symlink everything (and rpm doesn't deal well with changing a
filesystem entry from a symlink to a directory and vice-versa so the admin
has more headaches ahead with this method) or repartitioning (since / is
likely too small to hold /srv too) or remounting /var/ (or some directory
below it) under /src (which will likely require a reboot or at least
dropping to single).
And I don't see any benefit in this.
> 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."
>
> This assumes data is arranged and stored in seprate places based off of
> services. rsync, cvs, ftp, and www can easily share the same target
> data.
>
>> 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.
>
> Then please keep it out of / . If this is just to be a dumping ground
> for apps to leave their default junk we don't need to clutter up / with
> another dir do we? /var seems to have always been the ugly stepchild of
> unwanted crap... I'm fine with adding more to it... ;)
My issue is that I really don't like typing extra keys unless really
necessary. One of the nice things about linux used to be that you could
hit two keys per directory level and get quite far. Now I am going to have
to type:
/sb[TAB]/ifco[TAB] instead of /s[TAB]/ifco[TAB].
Please don't pollute / any more (one of the reasons I hate Windows is
polluted root directories due to lack of structure by most users ...).
>
>>
>>> 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.
Well, /mnt/cdrom is normally temporary, as is /mnt/floppy. And again, this
is increasing the tpying I have to do (even in a graphical file manager
like Konqueror typing is quite a bit faster to get to a directory you know
the location of) if /mnt is retained and /media added.
If someone really wants a "scratch" mount area, they can make /mnt/tmp or
similar (this is what I do, usually for loopback mounts).
However, /media is a lot more descriptive than /mnt, but then it looks
quite out of place in /, being the longest directory name now ....
BTW, we mostly have non-system data in /home/{users,groups,projects,cvs},
but we are quite small ...
Regards,
Buchan
