How to Consolidate Project-Related Files Under /ws
Assume you are the administrator of a large software development project. You plan to make all project-related files available under a directory that is called /ws. This directory is to be common across all workstations at the site.
Add an entry for the /ws directory to the site auto_master map, either NIS or NIS+.
/ws auto_ws -nosuid
The auto_ws map determines the contents of the /ws directory.
Add the -nosuid option as a precaution.
This option prevents users from running setuid programs that might exist in any workspaces.
Add entries to the auto_ws map.
The auto_ws map is organized so that each entry describes a subproject. Your first attempt yields a map that resembles the following:
compiler alpha:/export/ws/& windows alpha:/export/ws/& files bravo:/export/ws/& drivers alpha:/export/ws/& man bravo:/export/ws/& tools delta:/export/ws/&
The ampersand (&) at the end of each entry is an abbreviation for the entry key. For instance, the first entry is equivalent to:
compiler alpha:/export/ws/compiler
This first attempt provides a map that appears simple, but it is inadequate. The project organizer decides that the documentation in the man entry should be provided as a subdirectory under each subproject. Also, each subproject requires subdirectories to describe several versions of the software. You must assign each of these subdirectories to an entire disk partition on the server.
Modify the entries in the map as follows:
compiler \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /vers2.0 bravo:/export/ws/&/vers2.0 \ /man bravo:/export/ws/&/man windows \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /man bravo:/export/ws/&/man files \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /vers2.0 bravo:/export/ws/&/vers2.0 \ /vers3.0 bravo:/export/ws/&/vers3.0 \ /man bravo:/export/ws/&/man drivers \ /vers1.0 alpha:/export/ws/&/vers1.0 \ /man bravo:/export/ws/&/man tools \ / delta:/export/ws/&
Although the map now appears to be much larger, it still contains only the five entries. Each entry is larger because it contains multiple mounts. For instance, a reference to /ws/compiler requires three mounts for the vers1.0, vers2.0, and man directories. The backslash at the end of each line informs autofs that the entry is continued onto the next line. Effectively, the entry is one long line, though line breaks and some indenting have been used to make it more readable. The tools directory contains software development tools for all subprojects, so it is not subject to the same subdirectory structure. The tools directory continues to be a single mount.
This arrangement provides the administrator with much flexibility. Software projects are notorious for consuming substantial amounts of disk space. Through the life of the project you might be required to relocate and expand various disk partitions. If these changes are reflected in the auto_ws map, the users do not need to be notified, as the directory hierarchy under /ws is not changed.
Because the servers alpha and bravo view the same autofs map, any users who log in to these computers can find the /ws name space as expected. These users are provided with direct access to local files through loopback mounts instead of NFS mounts.
How to Set Up Different Architectures to Access a Shared Name Space
You need to assemble a shared name space for local executables, and applications, such as spreadsheet applications and word-processing packages. The clients of this name space use several different workstation architectures that require different executable formats. Also, some workstations are running different releases of the operating system.
Create the auto_local map with the nistbladm command.
See the System Administration Guide: Naming and Directory Services (FNS and NIS+).
Choose a single, site-specific name for the shared name space so that files and directories that belong to this space are easily identifiable.
For example, if you choose /usr/local as the name, the path /usr/local/bin is obviously a part of this name space.
For ease of user community recognition, create an autofs indirect map and mount it at /usr/local. Set up the following entry in the NIS+ (or NIS) auto_master map:
/usr/local auto_local -ro
Notice that the -ro mount option implies that clients cannot write to any files or directories.
Export the appropriate directory on the server.
Include a bin entry in the auto_local map.
Your directory structure resembles the following:
bin aa:/export/local/bin
- (Optional)
To serve clients of different architectures, change the entry by adding the autofs CPU variable.
bin aa:/export/local/bin/$CPU
For SPARC clients - Place executables in /export/local/bin/sparc.
For IA clients - Place executables in /export/local/bin/i386.
How to Support Incompatible Client Operating System Versions
Combine the architecture type with a variable that determines the operating system type of the client.
You can combine the autofs OSREL variable with the CPU variable to form a name that determines both CPU type and OS release.
Create the following map entry.
bin aa:/export/local/bin/$CPU$OSREL
For clients running version 5.6 of the operating system, export the following file systems:
For SPARC clients - Export /export/local/bin/sparc5.6.
For IA clients - Place executables in /export/local/bin/i3865.6.
How to Replicate Shared Files Across Several Servers
The best way to share replicated file systems that are read-only is to use failover. See "Client-Side Failover" for a discussion of failover.
Become superuser or assume an equivalent role.
For information about roles, see "Using Privileged Applications" in System Administration Guide: Security Services.
Modify the entry in the autofs maps.
Create the list of all replica servers as a comma-separated list, such as the following:
bin aa,bb,cc,dd:/export/local/bin/$CPU
Autofs chooses the nearest server. If a server has several network interfaces, list each interface. Autofs chooses the nearest interface to the client, avoiding unnecessary routing of NFS traffic.