/Share - a heterogenous /usr/local ---------------------------------- Sharing local stuff across multiple versions of UNIX. Luke Mewburn Telstra CPR Project Date: 961112 Introduction ------------ Disclaimer: everyone has their own ideas on this. This worked for us. `/share' is a concept developed and implemented by myself at the Cable Plant Records (CPR) Project, Telstra, with input/ideas from David Burren and Simon Burge . Many installations use NFS to share `local stuff' across multiple UNIX machines. Often, there are multiple architectures and/or UNIX flavours in use as well. This should be taken into account when laying out your filesystems. The following requirements were determined through experimentation and experience: - no loopback mounts (with local NFS mounts or lofs) - support for shared architecture independant directories - minimal NFS mounts - no symlink ``farms'' The Solution: `/share' ---------------------- Server: One directory tree is setup: /share (or /export/share if you please). '/usr/local' is be symbolically linked to /share/arch/`osarchrel`. Clients: Two directories are mounted: server:/share /share server:/share/arch/`osarchrel` /usr/local /share is architecture independant. Anything in the top level is assumed to be shareable by any of the operating systems. Typical contents include: - manual pages - perl5 - ghostscript fonts - config files - GNU info files Example contents of /share: arch/ netbsd.i386/ solaris.sun4/ ultrix.risc/ etc/ ghostscript/ info/ man/ perl5/ /share/arch/`osarchrel` is architecture dependant. Each client sees the contents of this as /usr/local. There is a symbolic link from /share/arch/`osarchrel` to /share. Each subdirectory that exists at the top level of /usr/local that is architecture independant is symbolically linked from share/foo to foo (e.g., /usr/local/man -> share/man -> /share/man). Example contents of /share/arch/`osarchrel`: X11R6/ bin/ X11 -> ../X11R6/bin etc -> share/etc info -> share/info lib/ X11 -> ../X11R6/lib/X11 libexec/ man -> share/man sbin/ share -> /share If multiple combinations of operating systems can share the same directory under /share/arch (e.g., Sparc machines return different machine architecture id's but can share binaries), then a symbolic link from /share/arch/`osarchrel` -> /share/arch/`os.arch` could be made. osarchrel --------- For various reasons, it is sensible for an installation to come up with a standard nomenclature for distinguishing between various architectures. At CPR, the following mappings are currently used: ultrix.mips DECstations running ULTRIX 4.x sunos.sun4 Sparcs running Solaris 2.x sunos4.sun4 Sparcs running Solaris 1.x netbsd.pmax DECstations running NetBSD This worked at the time, but a more scalable approach is to use the output of `uname -s`, `uname -m`, and `uname -r` concatenated together with tildes (`~'). A group classification could be used if desired. For example, if `solaris.sun4' was the group for Solaris 2.x SPARCs, the the following pathnames could be symbolic links to /share/arch/solaris.sun4: /share/arch/SunOS~sun4d~5.5 (SS1000, Solaris 2.5) /share/arch/SunOS~sun4m~5.5 (SS20, Solaris 2.5) /share/arch/SunOS~sun4u~5.5.1 (Ultra 2, Solaris 2.5.1) [Note: originally periods (`.') were used as the delimiters, but this makes it difficult to perform accurate substring matching, as the period is often used in the output of uname. Tilde was chosen because it's not likely to be used] Advantages of `/share' ---------------------- There is only one tree to update at the implementation: /share. Architecture dependant stuff is kept in architecture specific location - /usr/local. Architecture independant stuff is not replacated unnecessarily. Loopback NFS mounts are avoided to prevent deadlocks on client or server shutdown. More information ---------------- Further information can be found in: http://www.cs.rmit.edu.au/~lukem/talks/sage-au-9611/ An example share.eg.tar.gz showing the layout of the tree can be found there, along with these notes.