On 16/05/11 15:15, Christoph Anton Mitterer wrote: > Hi. > > First I don't think that FHS is very much tailored on single machines. > Actually having things like /usr, /etc, /var makes it possible to have > some parts (e.g. the packages) on a remote machine bug everything that's > locally required (locks, pid files, config) locally.
Hi, Chris. I'm particularly interested in 'servents' (hosts that are both clients and servers, as in the /export/home example). This is different to the conventional server-only or client-only host that you might be thinking about. What is different, is that the servent needs to mount it's own exported/shared filesystems in the same way as any other client does. > On Mon, 16 May 2011 12:47:41 +0100, Tony Travis<[email protected]> > wrote: >> This man page describes how /export is used under FreeBSD/SunOS: > I personally don't like the idea of having a separate hierarchy for > exported stuff. > IMHO this belongs (at least in many cases) to /srv. I'm not arguing the point, but simply observing that /export is still widely used for this purpose on NFS 'servers' as well as servents. The FHS update is an opportunity to consider how we might recommend network filesystems to be exported/shared and mounted in peer NFS networks. > Especially it's questionable how exported filesystems differ from other > things that are _conceptually_ also "exported", e.g. HTTP data, or take a > SVN or CVS repository. These should likely go to /srv and one can in > principle also mount them as filesystem (e.g. via FUSE in Linux). My point is that if a host mounts, as a client, a filesystem that it also exports as a server then the local mountpoint must (obviously) be different. This was solved long ago in BSD/SunOS by mounting the directories to be served on /export, and using the NFS automounter or static NFS mounts to mount the exported directories on the same target directory on all hosts, including the host serving the filesystem. > I'd say people should either put this in /srv or just make their own > /<something> if they really think they need to,.. e.g. something like > /data/videos, /data/music . Making your own /<something> is not really in the spirit of the FHS ;-) > Actually it might be worth adding a /data hierarchy for this. Whether this > is then exported or not is irrelevant. Interestingly, this is exactly what I have done using "sshfs" and the linux automounter on the WAN. However, you are wrong that it doesn't matter if it is exported or not for the same reason that it matters on the LAN. In my case, I have: host1:/home/data -> /data/host1 Where /data is an auto-mountpoint for all of the hosts in the network. I did consider using /export/data, but these are 'Bio-Linux' systems that assume /home is a directory (as opposed to an auto-mountpoint). http://nebc.nerc.ac.uk/tools/bio-linux/bio-linux-6.0 > The more I consider it, the more I like it (/data). > If you export a whole filesystem this is either: > a) any data > b) something used on another system by some service (e.g. you have your > maildirs from a pop3/imap server) stored on an NFS area. > > For a) I'd prefer having /data instead of /export. > For b) I'd personally tend to use /srv One of the virtues of using /export (or /srv) is that you can do e.g: /export/home /export/data /export/db ... Bye, Tony. _______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
