Specifying Multiple Servers

You can specify more than one server as the resource for one mount point. If you specify more than one server in the server:pathname field, the automounter mounts the file system from the first server that replies to the mount request from the local net or subnet. If no server responds, all of the servers on the list are retried.

Following is the syntax for multiple locations for the same mount point.

key   [mount-options]   server:pathname \
     [mount-options]   server:pathname \
     [mount-options]   server:pathname

The backslash at the end of each line tells the automounter to consider the entire entry as one line, and it makes the entry easier for administrators to read. The last entry line does not have a backslash because it ends the sequence. For example, to mount the OpenWindows executable from three servers, the map entry might look like this:

openwin   -ro   oak:/usr/openwin \
     -ro   ash:/usr/openwin \
     -ro   elm:/usr/openwin

In this entry, each server specifies the same mount-options. You can combine them after the key by using this syntax:

key   [mount-options]\
      server:pathname \
      server:pathname \
      server:pathname

When you use the syntax that combines mount-options for all servers, the entry looks like this:

openwin   -ro\
        oak:/usr/openwin\
        ash:/usr/openwin\
        elm:/usr/openwin

This example works in exactly the same way as the preceding openwin example.

Specifying Multiple Servers with the Same Path

You can shorten the previous example because each of the locations uses the same path. Combine the server names on one line and separate them with commas, using this syntax:

key   [mount-options] server1,server2,server3:pathname

When you use the syntax that combines mount-options for all servers and the names of the servers, the entry looks like this:

openwin   -ro   oak,ash,elm:/usr/openwin

This example works in exactly the same way as the previous two examples.

Specifying Weighting Factors for Each Server

You can specify weighting factors for each server in the list by putting a number in parentheses after the name of the server. Server(0) is most likely to be selected, with progressively higher values decreasing the chance of being selected. If you do not specify a number, the automounter assumes the server to have a (0) weighting, and thus the highest priority.

---

NOTE:  Some older versions of the automounter do not recognize the server-weighting values. When the automounter does not recognize the weighting values, servers with such values are ignored. Consequently, if you want to share automount maps among systems of various release levels, do not use the weighting factors.

---

This is the syntax for weighting factors:

key   [mount-options]\
      server1(n),server2(n),server3(n):pathname

When you use the syntax that combines mount-options for all servers and combines the names of the servers with weighting factors, the entry looks like this:

openwin   -ro\
       oak,ash(1),elm(2):/usr/openwin

In this example, the server oak has the highest priority, (0), the server ash has the second highest priority, and the server elm, the third.

You can use the weighting factor for any list of servers, whether they are on individual lines or are combined on the same line. Just place the weighting factor number in parentheses after the name of the server.

---

NOTE:  Server proximity takes precedence over the weighting value. For example, a server on a local subnet is chosen even if it has a higher weighting value than a server on a different subnet. The weighting value is used to choose between servers that have the same network proximity.

---

Using Map Variables

The automounter provides predefined map variables, similar to environment variables, that you can use in defining paths. In Solaris 2.0 and 2.1, the map variables are ARCH and CPU.

---

NOTE:  The $ARCH variable is obsolete. It uses the output of the /usr/kvm/arch command, which is provided for compatibility. Use the $CPU variable instead.

---

When you include $CPU as part of the path, the map variable returns the name of the system architecture as it would be returned by the uname -p command.

oak% uname -p
sparc
oak%

In this example, the uname -p command returns the architecture sparc.

If you have a server exporting binaries for both SPARC and Intel 486 architectures from /usr/local/bin/sparc and /usr/local/bin/i486, respectively, you can use the $CPU command to create a map entry that mounts the binaries appropriate for each system’s architecture. The entry would look like this:

bin   -ro   server:/usr/local/bin/$CPU

With this entry, the map can be used for clients running all architectures.

The Solaris 2.3 system software and later provide additional predefined map variables, as described in Table 7-2.