标签：master imu remember startup ora rdl higher int pass
Autofs is a client-side service that automatically mounts the appropriate file system. When a client attempts to access a file system that is not presently mounted, the autofs file system intercepts the request and calls automountd to mount the requested directory. The automountddaemon locates the directory, mounts it within autofs, and replies. On receiving the reply, autofs allows the waiting request to proceed. Subsequent references to the mount are redirected by the autofs--no further participation is required by automountd until the file system is automatically unmounted by autofs after a period of inactivity.
The components that work together to accomplish automatic mounting are:
The automount command
The autofs file system
The automountd daemon
The automount command, called at system startup time, reads the master map file auto_master to create the initial set of autofs mounts. These autofs mounts are not automatically mounted at startup time. They are points under which file systems are mounted in the future. These points are also known as trigger nodes.
After the autofs mounts are set up, they can trigger file systems to be mounted under them. For example, when autofs receives a request to access a file system that is not currently mounted, autofs calls automountd, which actually mounts the requested file system.
Starting with the Solaris 2.5 release, the automountd daemon is completely independent from the automount command. Because of this separation, it is possible to add, delete, or change map information without first having to stop and start the automountd daemon process.
After initially mounting autofs mounts, the automount command is used to update autofs mounts as necessary, by comparing the list of mounts in the auto_master map with the list of mounted file systems in the mount table file /etc/mnttab (formerly /etc/mtab) and making the appropriate changes. This allows system administrators to change mount information within auto_master and have those changes used by the autofs processes without having to stop and restart the autofs daemon. After the file system is mounted, further access does not require any action from automountd until the file system is automatically unmounted.
Unlike mount, automount does not read the /etc/vfstab file (which is specific to each computer) for a list of file systems to mount. The automount command is controlled within a domain and on computers through the name space or local files.
This is a simplified overview of how autofs works:
The automount daemon automountd starts at boot time from the /etc/init.d/autofs script (see Figure 31-1). This script also runs the automount command, which reads the master map (see "How Autofs Starts the Navigation Process (Master Map)") and installs autofs mount points.
Autofs is a kernel file system that supports automatic mounting and unmounting.
When a request is made to access a file system at an autofs mount point:
Autofs intercepts the request.
Autofs sends a message to the automountd for the requested file system to be mounted.
automountd locates the file system information in a map, creates the trigger nodes, and performs the mount.
Autofs allows the intercepted request to proceed.
Autofs unmounts the file system after a period of inactivity.
Mounts managed through the autofs service should not be manually mounted or unmounted. Even if the operation is successful, the autofs service does not check that the object has been unmounted, resulting in possible inconsistencies. A reboot clears all of the autofs mount points.
Autofs searches a series of maps to navigate its way through the network. Maps are files that contain information such as the password entries of all users on a network or the names of all host computers on a network, that is, network-wide equivalents of UNIX administration files. Maps are available locally or through a network name service like NIS or NIS+. You create maps to meet the needs of your environment using the Solstice System Management Tools. See "Modifying How Autofs Navigates the Network (Modifying Maps)".
The automount command reads the master map at system startup. Each entry in the master map is a direct or indirect map name, its path, and its mount options, as shown in Figure 31-2. The specific order of the entries is not important. automount compares entries in the master map with entries in the mount table to generate a current list.
What the autofs service does when a mount request is triggered depends on how the automounter maps are configured. The mount process is generally the same for all mounts, but the final result changes with the mount point specified and the complexity of the maps. Starting with the Solaris 2.6 release, the mount process has also been changed to include the creation of the trigger nodes.
To help explain the autofs mount process, assume that the following files are installed.
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn -xfn /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws |
When the /share directory is accessed, the autofs service creates a trigger node for /share/ws, which can be seen in /etc/mnttab as an entry that resembles the following entry:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### |
When the /share/ws directory is accessed, the autofs service completes the process with these steps:
Pings the server‘s mount service to see if it‘s alive.
Mounts the requested file system under /share. Now /etc/mnttab file contains the following entries:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### ##### |
When multiple layers are defined in the automounter files, the mount process becomes more complex. If the /etc/auto_shared file from the previous example is expanded to contain:
# share directory map for automounter
#
ws / gumbo:/export/share/ws
/usr gumbo:/export/share/ws/usr
|
The mount process is basically the same as the previous example when the /share/ws mount point is accessed. In addition, a trigger node to the next level (/usr) is created in the /share/ws file system so that the next level can be mounted if it is accessed. In this example, /export/share/ws/usr must exist on the NFS server for the trigger node to be created.
Caution -Do not use the -soft option when specifying hierarchical layers. Refer to "Autofs Unmounting" for an explanation of this limitation.
The unmounting that occurs after a certain amount of idle time is from the bottom up (reverse order of mounting). If one of the directories at a higher level in the hierarchy is busy, only file systems below that directory are unmounted. During the unmounting process, any trigger nodes are removed and then the file system is unmounted. If the file system is busy, the unmount fails and the trigger nodes are reinstalled.
Caution -Do not use the -soft option when specifying hierarchical layers. If the -soft option is used, requests to reinstall the trigger nodes can time out. The failure to reinstall the trigger notes leaves no access to the next level of mounts. The only way to clear this problem is to have the automounter unmount all of the components in the hierarchy, either by waiting for the file systems to be automatically unmounted or by rebooting the system.
In the example of a direct map, which was:
/usr/local -ro /bin ivy:/export/local/sun4 /share ivy:/export/local/share /src ivy:/export/local/src /usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news willow:/var/spool/news |
The mount points /usr/man and /usr/spool/news list more than one location (three for the first, two for the second). This means any of the replicated locations can provide the same service to any user. This procedure makes sense only when you mount a file system that is read-only, as you must have some control over the locations of files you write or modify. You don‘t want to modify files on one server on one occasion and, minutes later, modify the "same" file on another server. The benefit is that the best available server is used automatically without any effort required by the user.
If the file systems are configured as replicas (see "What Is a Replicated File System?"), the clients have the advantage of using failover. Not only is the best server automatically determined, but if that server becomes unavailable, the client automatically uses the next-best server. Failover was first implemented in the Solaris 2.6 release.
An example of a good file system to configure as a replica is man pages. In a large network, more than one server can export the current set of manual pages. Which server you mount them from does not matter, as long as the server is running and exporting its file systems. In the previous example, multiple mount locations are expressed as a list of mount locations in the map entry.
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man |
Here you can mount the man pages from the servers oak, rose, or willow. Which server is best depends on a number of factors including: the number of servers supporting a particular NFS protocol level, the proximity of the server, and weighting.
During the sorting process, a count of the number of servers supporting the NFS version 2 and NFS version 3 protocols is made. Whichever protocol is supported on the most servers becomes the protocol supported by default. This provides the client with the maximum number of servers to depend on.
After the largest subset of servers with the same protocol version is found, that server list is sorted by proximity. Servers on the local subnet are given preference over servers on a remote subnet. The closest server is given preference, which reduces latency and network traffic. Figure 31-3illustrates server proximity.
If several servers supporting the same protocol are on the local subnet, the time to connect to each server is determined and the fastest is used. The sorting can also be influenced by using weighting (see "Autofs and Weighting").
If version 3 servers are more abundant, the sorting process becomes more complex. Normally, servers on the local subnet are given preference over servers on a remote subnet. A version 2 server can complicate matters, as it might be closer than the nearest version 3 server. If there is a version 2 server on the local subnet and the closest version 3 server is on a remote subnet, the version 2 server is given preference. This preference is only checked if there are more version 3 servers than version 2 servers. If there are more version 2 servers, only a version 2 server is selected.
With failover, the sorting is checked once at mount time to select one server from which to mount, and again anytime the mounted server becomes unavailable. Multiple locations are useful in an environment where individual servers might not export their file systems temporarily.
This feature is particularly useful in a large network with many subnets. Autofs chooses the nearest server and therefore confines NFS network traffic to a local network segment. In servers with multiple network interfaces, list the host name associated with each network interface as if it were a separate server. Autofs selects the nearest interface to the client.
You can influence the selection of servers at the same proximity level by adding a weighting value to the autofs map. For example:
/usr/man -ro oak,rose(1),willow(2):/usr/man |
The numbers in parentheses indicate a weighting. Servers without a weighting have a value of zero (most likely to be selected). The higher the weighting value, the lower the chance the server will be selected.
All other server selection factors are more important than weighting. Weighting is only considered when selecting between servers with the same network proximity.
You can create a client-specific variable by prefixing a dollar sign ($) to its name. This helps you to accommodate different architecture types accessing the same file system location. You can also use curly braces to delimit the name of the variable from appended letters or digits. Table 31-4 shows the predefined map variables.
|
Variable |
Meaning |
Derived From |
Example |
|---|---|---|---|
|
Architecture type |
uname -m |
sun4 |
|
|
Processor type |
uname -p |
sparc |
|
|
Host name |
uname -n |
dinky |
|
|
Operating system name |
uname -s |
SunOS |
|
|
Operating system release |
uname -r |
5.4 |
|
|
Operating system version (version of the release) |
uname -v |
FCS1.0 |
You can use variables anywhere in an entry line except as a key. For instance, if you have a file server exporting binaries for SPARC and IA architectures from /usr/local/bin/sparc and /usr/local/bin/x86 respectively, the clients can mount through a map entry like the following:
/usr/local/bin -ro server:/usr/local/bin/$CPU |
Now the same entry for all clients applies to all architectures.
Most applications written for any of the sun4 architectures can run on all sun4 platforms, so the -ARCH variable is hard-coded to sun4 instead of sun4m.
A map entry +mapname used in a file map causes automount to read the specified map as if it were included in the current file. If mapname is not preceded by a slash, autofs treats the map name as a string of characters and uses the name service switch policy to find it. If the path name is an absolute path name, automount checks a local map of that name. If the map name starts with a dash (-), automount consults the appropriate built-in map, such as xfn or hosts.
This name service switch file contains an entry for autofs labeled as automount, which contains the order in which the name services are searched. The following file is an example of a name service switch file:
# # /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the /etc/netconfig # file contains "switch.so" as a nametoaddr library for "inet" transports. # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis |
In this example, the local maps are searched before the NIS maps, so you can have a few entries in your local /etc/auto_home map for the most commonly accessed home directories, and use the switch to fall back to the NIS map for other entries.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny |
After consulting the included map, if no match is found, automount continues scanning the current map. This means you can add more entries after a + entry.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home |
The map included can be a local file (remember, only local files can contain + entries) or a built-in map:
+auto_home_finance # NIS+ map +auto_home_sales # NIS+ map +auto_home_engineering # NIS+ map +/etc/auto_mystuff # local map +auto_home # NIS+ map +-hosts # built-in hosts map |
You cannot use + entries in NIS+ or NIS maps.
You can create an autofs map that will execute some commands to generate the autofs mount points. You could benefit from using an executable autofs map if you need to be able to create the autofs structure from a database or a flat file. The disadvantage to using an executable map is that the map will need to be installed on each host. An executable map cannot be included in either the NIS or the NIS+ name service.
The executable map must have an entry in the auto_master file.
/execute auto_execute |
Here is an example of an executable map:
#!/bin/ksh # # executable map for autofs # case $1 in src) echo ‘-nosuid,hard bee:/export1‘ ;; esac |
For this example to work, the file must be installed as /etc/auto_execute and must have the executable bit set (set permissions to 744). Under these circumstances running the following command:
% ls /execute/src |
causes the /export1 file system from bee to be mounted.
You can modify, delete, or add entries to maps to meet the needs of your environment. As applications and other file systems that users require change their location, the maps must reflect those changes. You can modify autofs maps at any time. Whether your modifications take effect the next time automountd mounts a file system depends on which map you modify and what kind of modification you make.
Booting invokes autofs using the /etc/init.d/autofs script and checks for the master auto_master map (subject to the rules discussed subsequently).
Autofs uses the name service specified in the automount entry of the /etc/nsswitch.conf file. If NIS+ is specified, as opposed to local files or NIS, all map names are used as is. If NIS is selected and autofs cannot find a map that it needs, but finds a map name that contains one or more underscores, the underscores are changed to dots, which allows the old NIS file names to work. Then autofs checks the map again, as shown in Figure 31-4.
The screen activity for this session would look like the following example.
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can‘t match key brent in map auto_home. Reason: no such map in server‘s domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/& |
If "files" is selected as the name service, all maps are assumed to be local files in the /etc directory. Autofs interprets a map name that begins with a slash (/) as local regardless of which name service it uses.
Autofs is a client-side service that automatically mounts the appropriate file system. When a client attempts to access a file system that is not presently mounted, the autofs file system intercepts the request and calls automountd to mount the requested directory. The automountddaemon locates the directory, mounts it within autofs, and replies. On receiving the reply, autofs allows the waiting request to proceed. Subsequent references to the mount are redirected by the autofs--no further participation is required by automountd until the file system is automatically unmounted by autofs after a period of inactivity.
The components that work together to accomplish automatic mounting are:
The automount command
The autofs file system
The automountd daemon
The automount command, called at system startup time, reads the master map file auto_master to create the initial set of autofs mounts. These autofs mounts are not automatically mounted at startup time. They are points under which file systems are mounted in the future. These points are also known as trigger nodes.
After the autofs mounts are set up, they can trigger file systems to be mounted under them. For example, when autofs receives a request to access a file system that is not currently mounted, autofs calls automountd, which actually mounts the requested file system.
Starting with the Solaris 2.5 release, the automountd daemon is completely independent from the automount command. Because of this separation, it is possible to add, delete, or change map information without first having to stop and start the automountd daemon process.
After initially mounting autofs mounts, the automount command is used to update autofs mounts as necessary, by comparing the list of mounts in the auto_master map with the list of mounted file systems in the mount table file /etc/mnttab (formerly /etc/mtab) and making the appropriate changes. This allows system administrators to change mount information within auto_master and have those changes used by the autofs processes without having to stop and restart the autofs daemon. After the file system is mounted, further access does not require any action from automountd until the file system is automatically unmounted.
Unlike mount, automount does not read the /etc/vfstab file (which is specific to each computer) for a list of file systems to mount. The automount command is controlled within a domain and on computers through the name space or local files.
This is a simplified overview of how autofs works:
The automount daemon automountd starts at boot time from the /etc/init.d/autofs script (see Figure 31-1). This script also runs the automount command, which reads the master map (see "How Autofs Starts the Navigation Process (Master Map)") and installs autofs mount points.
Autofs is a kernel file system that supports automatic mounting and unmounting.
When a request is made to access a file system at an autofs mount point:
Autofs intercepts the request.
Autofs sends a message to the automountd for the requested file system to be mounted.
automountd locates the file system information in a map, creates the trigger nodes, and performs the mount.
Autofs allows the intercepted request to proceed.
Autofs unmounts the file system after a period of inactivity.
Note -
Mounts managed through the autofs service should not be manually mounted or unmounted. Even if the operation is successful, the autofs service does not check that the object has been unmounted, resulting in possible inconsistencies. A reboot clears all of the autofs mount points.
Autofs searches a series of maps to navigate its way through the network. Maps are files that contain information such as the password entries of all users on a network or the names of all host computers on a network, that is, network-wide equivalents of UNIX administration files. Maps are available locally or through a network name service like NIS or NIS+. You create maps to meet the needs of your environment using the Solstice System Management Tools. See "Modifying How Autofs Navigates the Network (Modifying Maps)".
The automount command reads the master map at system startup. Each entry in the master map is a direct or indirect map name, its path, and its mount options, as shown in Figure 31-2. The specific order of the entries is not important. automount compares entries in the master map with entries in the mount table to generate a current list.
What the autofs service does when a mount request is triggered depends on how the automounter maps are configured. The mount process is generally the same for all mounts, but the final result changes with the mount point specified and the complexity of the maps. Starting with the Solaris 2.6 release, the mount process has also been changed to include the creation of the trigger nodes.
To help explain the autofs mount process, assume that the following files are installed.
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /xfn -xfn /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws |
When the /share directory is accessed, the autofs service creates a trigger node for /share/ws, which can be seen in /etc/mnttab as an entry that resembles the following entry:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### |
When the /share/ws directory is accessed, the autofs service completes the process with these steps:
Pings the server‘s mount service to see if it‘s alive.
Mounts the requested file system under /share. Now /etc/mnttab file contains the following entries:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### ##### |
When multiple layers are defined in the automounter files, the mount process becomes more complex. If the /etc/auto_shared file from the previous example is expanded to contain:
# share directory map for automounter
#
ws / gumbo:/export/share/ws
/usr gumbo:/export/share/ws/usr
|
The mount process is basically the same as the previous example when the /share/ws mount point is accessed. In addition, a trigger node to the next level (/usr) is created in the /share/ws file system so that the next level can be mounted if it is accessed. In this example, /export/share/ws/usr must exist on the NFS server for the trigger node to be created.
Caution -
Do not use the -soft option when specifying hierarchical layers. Refer to "Autofs Unmounting" for an explanation of this limitation.
The unmounting that occurs after a certain amount of idle time is from the bottom up (reverse order of mounting). If one of the directories at a higher level in the hierarchy is busy, only file systems below that directory are unmounted. During the unmounting process, any trigger nodes are removed and then the file system is unmounted. If the file system is busy, the unmount fails and the trigger nodes are reinstalled.
Caution -
Do not use the -soft option when specifying hierarchical layers. If the -soft option is used, requests to reinstall the trigger nodes can time out. The failure to reinstall the trigger notes leaves no access to the next level of mounts. The only way to clear this problem is to have the automounter unmount all of the components in the hierarchy, either by waiting for the file systems to be automatically unmounted or by rebooting the system.
In the example of a direct map, which was:
/usr/local -ro /bin ivy:/export/local/sun4 /share ivy:/export/local/share /src ivy:/export/local/src /usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news willow:/var/spool/news |
The mount points /usr/man and /usr/spool/news list more than one location (three for the first, two for the second). This means any of the replicated locations can provide the same service to any user. This procedure makes sense only when you mount a file system that is read-only, as you must have some control over the locations of files you write or modify. You don‘t want to modify files on one server on one occasion and, minutes later, modify the "same" file on another server. The benefit is that the best available server is used automatically without any effort required by the user.
If the file systems are configured as replicas (see "What Is a Replicated File System?"), the clients have the advantage of using failover. Not only is the best server automatically determined, but if that server becomes unavailable, the client automatically uses the next-best server. Failover was first implemented in the Solaris 2.6 release.
An example of a good file system to configure as a replica is man pages. In a large network, more than one server can export the current set of manual pages. Which server you mount them from does not matter, as long as the server is running and exporting its file systems. In the previous example, multiple mount locations are expressed as a list of mount locations in the map entry.
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man |
Here you can mount the man pages from the servers oak, rose, or willow. Which server is best depends on a number of factors including: the number of servers supporting a particular NFS protocol level, the proximity of the server, and weighting.
During the sorting process, a count of the number of servers supporting the NFS version 2 and NFS version 3 protocols is made. Whichever protocol is supported on the most servers becomes the protocol supported by default. This provides the client with the maximum number of servers to depend on.
After the largest subset of servers with the same protocol version is found, that server list is sorted by proximity. Servers on the local subnet are given preference over servers on a remote subnet. The closest server is given preference, which reduces latency and network traffic. Figure 31-3illustrates server proximity.
If several servers supporting the same protocol are on the local subnet, the time to connect to each server is determined and the fastest is used. The sorting can also be influenced by using weighting (see "Autofs and Weighting").
If version 3 servers are more abundant, the sorting process becomes more complex. Normally, servers on the local subnet are given preference over servers on a remote subnet. A version 2 server can complicate matters, as it might be closer than the nearest version 3 server. If there is a version 2 server on the local subnet and the closest version 3 server is on a remote subnet, the version 2 server is given preference. This preference is only checked if there are more version 3 servers than version 2 servers. If there are more version 2 servers, only a version 2 server is selected.
With failover, the sorting is checked once at mount time to select one server from which to mount, and again anytime the mounted server becomes unavailable. Multiple locations are useful in an environment where individual servers might not export their file systems temporarily.
This feature is particularly useful in a large network with many subnets. Autofs chooses the nearest server and therefore confines NFS network traffic to a local network segment. In servers with multiple network interfaces, list the host name associated with each network interface as if it were a separate server. Autofs selects the nearest interface to the client.
You can influence the selection of servers at the same proximity level by adding a weighting value to the autofs map. For example:
/usr/man -ro oak,rose(1),willow(2):/usr/man |
The numbers in parentheses indicate a weighting. Servers without a weighting have a value of zero (most likely to be selected). The higher the weighting value, the lower the chance the server will be selected.
Note -
All other server selection factors are more important than weighting. Weighting is only considered when selecting between servers with the same network proximity.
You can create a client-specific variable by prefixing a dollar sign ($) to its name. This helps you to accommodate different architecture types accessing the same file system location. You can also use curly braces to delimit the name of the variable from appended letters or digits. Table 31-4 shows the predefined map variables.
Table 31-4 Predefined Map Variables
|
Variable |
Meaning |
Derived From |
Example |
|---|---|---|---|
|
Architecture type |
uname -m |
sun4 |
|
|
Processor type |
uname -p |
sparc |
|
|
Host name |
uname -n |
dinky |
|
|
Operating system name |
uname -s |
SunOS |
|
|
Operating system release |
uname -r |
5.4 |
|
|
Operating system version (version of the release) |
uname -v |
FCS1.0 |
You can use variables anywhere in an entry line except as a key. For instance, if you have a file server exporting binaries for SPARC and IA architectures from /usr/local/bin/sparc and /usr/local/bin/x86 respectively, the clients can mount through a map entry like the following:
/usr/local/bin -ro server:/usr/local/bin/$CPU |
Now the same entry for all clients applies to all architectures.
Note -
Most applications written for any of the sun4 architectures can run on all sun4 platforms, so the -ARCH variable is hard-coded to sun4 instead of sun4m.
A map entry +mapname used in a file map causes automount to read the specified map as if it were included in the current file. If mapname is not preceded by a slash, autofs treats the map name as a string of characters and uses the name service switch policy to find it. If the path name is an absolute path name, automount checks a local map of that name. If the map name starts with a dash (-), automount consults the appropriate built-in map, such as xfn or hosts.
This name service switch file contains an entry for autofs labeled as automount, which contains the order in which the name services are searched. The following file is an example of a name service switch file:
# # /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the /etc/netconfig # file contains "switch.so" as a nametoaddr library for "inet" transports. # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis |
In this example, the local maps are searched before the NIS maps, so you can have a few entries in your local /etc/auto_home map for the most commonly accessed home directories, and use the switch to fall back to the NIS map for other entries.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny |
After consulting the included map, if no match is found, automount continues scanning the current map. This means you can add more entries after a + entry.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home |
The map included can be a local file (remember, only local files can contain + entries) or a built-in map:
+auto_home_finance # NIS+ map +auto_home_sales # NIS+ map +auto_home_engineering # NIS+ map +/etc/auto_mystuff # local map +auto_home # NIS+ map +-hosts # built-in hosts map |
Note -
You cannot use + entries in NIS+ or NIS maps.
You can create an autofs map that will execute some commands to generate the autofs mount points. You could benefit from using an executable autofs map if you need to be able to create the autofs structure from a database or a flat file. The disadvantage to using an executable map is that the map will need to be installed on each host. An executable map cannot be included in either the NIS or the NIS+ name service.
The executable map must have an entry in the auto_master file.
/execute auto_execute |
Here is an example of an executable map:
#!/bin/ksh # # executable map for autofs # case $1 in src) echo ‘-nosuid,hard bee:/export1‘ ;; esac |
For this example to work, the file must be installed as /etc/auto_execute and must have the executable bit set (set permissions to 744). Under these circumstances running the following command:
% ls /execute/src |
causes the /export1 file system from bee to be mounted.
You can modify, delete, or add entries to maps to meet the needs of your environment. As applications and other file systems that users require change their location, the maps must reflect those changes. You can modify autofs maps at any time. Whether your modifications take effect the next time automountd mounts a file system depends on which map you modify and what kind of modification you make.
Booting invokes autofs using the /etc/init.d/autofs script and checks for the master auto_master map (subject to the rules discussed subsequently).
Autofs uses the name service specified in the automount entry of the /etc/nsswitch.conf file. If NIS+ is specified, as opposed to local files or NIS, all map names are used as is. If NIS is selected and autofs cannot find a map that it needs, but finds a map name that contains one or more underscores, the underscores are changed to dots, which allows the old NIS file names to work. Then autofs checks the map again, as shown in Figure 31-4.
The screen activity for this session would look like the following example.
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can‘t match key brent in map auto_home. Reason: no such map in server‘s domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/& |
If "files" is selected as the name service, all maps are assumed to be local files in the /etc directory. Autofs interprets a map name that begins with a slash (/) as local regardless of which name service it uses.
标签：master imu remember startup ora rdl higher int pass
原文地址：https://www.cnblogs.com/mouseleo/p/9565186.html
