Managing NFS and NIS, 2nd Edition - Mike Eisler [74]
Normally you don't want people running applications on hosts that are also NFS servers. However, if you allow this, and if you want users on the NFS server to be able to access the toolbox as /software/toolbox, then you can either create a symbolic link from /software/toolbox to /export/home/toolbox, or use the loopback filesystem in Solaris to accomplish the same thing without the overhead of a symbolic link: mount -F lofs /export/home/toolbox /software/toolbox
Keep growth in mind. Having a single third-party software filesystem may be the most effective (or only) solution immediately, but over the next year you may need to add a second or third filesystem to make room for more tools. To provide adequate performance, you may want to put each filesystem on a different server, distributing the load. If you choose a naming scheme that cannot be extended, you will end up renaming things later on and having to support the "old style" names.
In the third-party tools directory example, you could separate tools into subdirectories grouped by function: /software/tools/epubs for page composition and publishing software, and /software/tools/cae for engineering tools. If either directory grows enough to warrant its own filesystem, you can move the subdirectory to a new server and preserve the existing naming scheme by simply mounting both subdirectories on clients:
Before: single tools depository
# mount toolbox:/export/home/tools /software/tools
After: multiple filesystems
# mount toolbox:/export/home/epubs /software/tools/epubs
# mount backpack:/export/home/case /software/tools/cae
Solving the /usr/local puzzle
Let's assume you have a network with many different kinds of workstations: SPARC workstations, PowerPC-based workstations, Unix PCs, and so on. Of course, each kind of workstation has its own set of executables. The executables may be built from the same source files, but you need a different binary for each machine architecture. How do you arrange the filesystem so that each system has a /usr/local/bin directory (and, by extension, other executable directories) that contains only the executables that are appropriate for its architecture? How do you "hide" the executables that aren't appropriate, so there's no chance that a user will mistakenly try to execute them? This is the /usr/local puzzle: creating an "architecture neutral" executable directory.
Implementing an architecture-neutral /usr/local/bin is probably one of the first challenges posed to the system administrator of a heterogeneous network. Everybody wants the standard set of tools, such as emacs, PostScript filters, mail-pretty printers, and the requisite telephone list utility. Ideally, there should be one bin directory for each architecture, and when a user looks in /usr/local/bin on any machine, he or she should find the proper executables. Hiding the machine architecture is a good job for symbolic links.
One solution is to name the individual binary directories with the machine type as a suffix and then mount the proper one on /usr/local/bin:
On server toolbox:
# cd /export/home/local
# ls
bin.mips bin.sun3 bin.sun4 bin.vax
On client:
# mount toolbox:/export/home/local/bin.`arch` /usr/local/bin
The mount command determines the architecture of the local host and grabs the correct binary directory from the server.
This scheme is sufficient if you only have binaries in your local depository, but most sites add manual pages, source code, and other ASCII files that are shared across client architectures. There is no need to maintain multiple copies of these files. To accommodate a mixture of shared ASCII and binary files, use two mounts of the same filesystem: the first