| Now that we know how to do it, let's move on and build some maps. We also talked about removing the redundant user mounts, so we'll take this opportunity to move them all onto one machine, still in /export/home, but now under the control of Autofs. We'll use neon for this task. While we are moving things around, we'll also NFS-mount the manual pages onto every machine from oxygen. This allows us to free up some space on all the local disks if we wish. Table 18.9 shows the original location, along with the name of the map we will create and its type. Table 18.9. Our MapsOriginal Location | Map Name | Map Type |
|---|
/usr/share/man | auto_man | Direct | /export/home | auto_home | Indirect | /data/remote_files/log | auto_data | Indirect | /data/remote_files/general | auto_data | Indirect | /data/remote_files/admin | auto_data | Indirect |
We'll create them all on one machine first, using lithium again. This will allow us to test most of the functionality of Autofs, although we'll also need to copy the maps to other machines to test the access control settings. We need to make sure that home directories are shared correctly from neon now, and that the NFS daemons have all been started. We don't need to make any changes to helium, though, because everything is already correctly shared from it. The Master Map After using the information provided in the table above and incorporating the predefined hosts map, we've created the following master map: lithium# cat /etc/auto_master # # Master map for automounter # /net -hosts -nosuid,nobrowse /data auto_data /home auto_home /- auto_man lithium# We've added the "nosuid" and "nobrowse" options to /net, to add a little more security. We've also included options within some of the maps themselves, as we'll see below. Let's now work through the remaining maps, creating each one in turn. The Direct Map The first one we'll look at is auto_man, which is shown below: lithium# cat /etc/auto_man /usr/share/man -ro,soft oxygen:/usr/share/man lithium# This allows access to the online manual pages and is very similar to the examples we have already seen. We've included options for it, too. The access will be read-only, and the "soft" option will allow the request to continue without an error. This is generally OK for read-only filesystems, but it's always recommended to use the "hard" mount option for read-write filesystems. The Indirect Maps Next we have the auto_home and auto_data maps, both of which are indirect-type maps: lithium# cat /etc/auto_home testuser neon:/export/home/testuser sysadmin neon:/export/home/sysadmin msmith neon:/export/home/msmith jgreen neon:/export/home/jgreen lithium# This again is quite simple and similar to the previous example. It takes each of the user directories from /export/home on neon and mounts them onto /home on the client. Now let's look at the auto_data file. Here we have added options that reflect the access control we would like applied. We can see that entries for general and admin only refer to three machines, so there is an argument for leaving them as standard NFS mounts, rather than pass the details onto every machine; we've simply done it this way for completeness: lithium# cat /etc/auto_data log -ro helium:/data/remote_files/log general -rw=lithium:boron helium:/data/remote_files/general admin -ro=nitrogen helium:/data/remote_files/admin lithium# | 
