Re: [Cooker] Cooker filesystem vs FHS 2.3

[Buchan Milne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Claudio Matsuoka wrote:
> On Sat, 21 May 2005, Andreas Hasenack wrote:
> 
> 
>>Em Sïb 21 Mai 2005 17:00, Claudio Matsuoka escreveu:
>>
>>>Maybe it's a good time to do so. Back when they were proposed, /media and
>>>/srv seemed strange enough for us not to like it, but I think they're far
>>>more acceptable now. We gain in standards compliance, and it would make
>>>the Conectiva Linux 10 -> Mandriva Linux 2006 upgrade less harder.
>>
>>/media is weird ;)
> 
> 
> It is. I personally prefer the /floppy, /cdrom like in Solaris (and I
> like to have /mnt clear for temp mounts), but here's what is mandated
> by FHS 2.3, Section 3.11:
> 
> 	/media: Mount point for removeable media
> 
> 	Purpose: This directory contains subdirectories which are
> 	used as mount points for removeable media such as floppy disks,
> 	cdroms and zip disks.
> 
> 	Rationale: Historically there have been a number of other
> 	different places used to mount removeable media such as /cdrom,
> 	/mnt or /mnt/cdrom. Placing the mount points for all removeable
> 	media directly in the root directory would potentially result in
> 	a large number of extra directories in /. Although the use of
> 	subdirectories in /mnt as a mount point has recently been common,
> 	it conflicts with a much older tradition of using /mnt directly
> 	as a temporary mount point.

I personally use /mnt/tmp as a temporary mount point (or, if I don't
have one, /mnt/floppy, since very few systems now actually have floppy
drives ;-)).

But, IMHO this is ridiculous, it's basically:

"Many distributions currently use directories under /mnt/ for removable
media, but now some stubborn UNIX users refuse to make /mnt/tmp (and
SuSE wants their directory layout to become the standard) we'll
introduce /media to confuse everyone currently using Linux"

>>>Let's see if anyone has restrictions. If it is to be done, it's best
>>>to do it earlier because it will possibly affect other subsystems such
>>>as the installer, supermount and maybe file managers.
>>
>>apache comes to mind... Seems impossible to stay with a directory for it for
>>more than 2 years ;)
>>
>>If the LSB standard is now clear enough that these directories should be
>>used, then I vote to go for it.
> 
> 
> Only for small values of "clear enough". Section 3.16 says:
> 
> 	/srv: Data for services provided by this system
> 
> 	Purpose: /srv contains site-specific data which is served
> 	by this system.
> 
> 	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 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.
> 
> 	Distributions must take care not to remove locally placed
> 	files in these directories without administrator permission.
> 
> So the policy regarding /srv is still murky as far as I can see. We could
> either make an empty directory and let the administrator use it as it fits
> best (Debian's approach), physically place some content there (that seems
> to be what the FHS meant to say, but I'd not bet on that), or populate it
> with symlinks.

The way I read it (I was planning on writing a mail on Friday when I
read your wiki page) is that the distributor must provide /srv, but may
not use it at all.

What I would probably do with it is use autofs on it ... maybe we could
provide an autofs map for /srv which mounts (--bind) subdirectories to
the current locations under /var ?

Regards,
Buchan

- --
Buchan Milne                      Senior Support Technician
Obsidian Systems                  http://www.obsidian.co.za
B.Eng          RHCE (803004789010797),LPIC-1 (LPI000074592)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCkaQArJK6UGDSBKcRAp7IAJ9pbd2y3mbXrl50wV2e75oQeaECNgCeLMmu
jI8+1N78hxo2djLVEdXeDH8=
=P6st
-----END PGP SIGNATURE-----