Hack58.Keep Filesystems Handy, but Out of Your Way

Hack 58. Keep Filesystems Handy, but Out of Your Way

Use the amd automounter, and some handy defaults, to maintain mounted resources without doing without your own local resources.

The amd automounter isn't the most ubiquitous production service I've ever seen, but it can certainly be a valuable tool for administrators in the setup of their own desktop machines. Why? Because it gives you the power to be able to easily and conveniently access any NFS share in your environment, and the default settings for amd put all of them under their own directory, out of the way, without you having to do much more than simply start the service.

Here's an example of how useful this can be. I work in an environment in which the /usr/local directories on our production machines are mounted from a central NFS server. This is great, because if we need to build software for our servers that isn't supplied by the distribution vendor, we can just build it from source in that tree, and all of the servers can access it as soon as it's built. However, occasionally we receive support tickets saying that something is acting strangely or isn't working. Most times, the issue is environmental: the user is getting at the wrong binary because /usr/local is not in her PATH, or something simple like that. Sometimes, though, the problem is ours, and we need to troubleshoot it.

The most convenient way to do that is just to mount the shared /usr/local to our desktops and use it in place of our own. For me, however, this is suboptimal, because I like to use my system's /usr/local to test new software. So I need another way to mount the shared /usr/local without conflicting with my own /usr/local. This is where amd comes in, as it allows me to get at all of the shares I need, on the fly, without interfering with my local setup.

Here's an example of how this works. I know that the server that serves up the /usr/local partition is named fs, and I know that the file mounted as /usr/local on the clients is actually called /linux/local on the server. With a properly configured amd, I just run the following command to mount the shared directory:

 $ cd /net/fs/linux/local  

There I am, ready to test whatever needs to be tested, having done next to no configuration whatsoever!

The funny thing is, I've run into lots of administrators who don't use amd and didn't know that it performed this particular function. This is because the amd mount configuration is a little bit cryptic. To understand it, let's take a look at how amd is configured. Soon you'll be mounting remote shares with ease.

6.4.1. amd Configuration in a Nutshell

The main amd configuration file is almost always /etc/amd.conf. This file sets up default behaviors for the daemon and defines other configuration files that are authoritative for each configured mount point. Here's a quick look at a totally untouched configuration file, as supplied with the Fedora Core 4 am-utils package, which supplies the amd automounter:

 [ global ] normalize_hostnames = no print_pid = yes pid_file = /var/run/amd.pid restart_mounts = yes auto_dir = /.automount #log_file = /var/log/amd log_file = syslog log_options = all #debug_options = all plock = no selectors_on_default = yes print_version = no # set map_type to "nis" for NIS maps, or comment it out to search for all # types map_type = file search_path = /etc browsable_dirs = yes show_statfs_entries = no fully_qualified_hosts = no cache_duration = 300 # DEFINE AN AMD MOUNT POINT [ /net ] map_name = amd.net map_type = file 

The options in the [global] section specify behaviors of the daemon itself and rarely need changing. You'll notice that search_path is set to /etc, which means it will look for mount maps under the /etc directory. You'll also see that auto_dir is set to /.automount. This is where amd will mount the directories you request. Since amd cannot perform mounts "in-place," directly under the mount point you define, it actually performs all mounts under the auto_dir directory, and then returns a symlink to that directory in response to the incoming mount requests. We'll explore that more after we look at the configuration for the [/net] mount point.

From looking at the above configuration file, we can tell that the file that tells amd how to mount things under /net is amd.net. Since the search_path option in the [global] section is set to /etc, it'll really be looking for /etc/amd.net at startup time. Here are the contents of that file:

 /defaults fs:=${autodir}/${rhost}/root/${rfs};opts:=nosuid,nodev * rhost:=${key};type:=host;rfs:=/ 

Eyes glazing over? Well, then let's translate this into English. The first entry is /defaults, which is there to define the symlink that gets returned in response to requests for directories under [/net] in amd.conf. Here's a quick tour of the variables being used here:

• ${autodir} gets its value from the auto_dir setting in amd.conf, which in this case will be /.automount.

• ${rhost} is the name of the remote file server, which in our example is fs. It is followed closely by /root, which is really just a placeholder for / on the remote host.

• ${rfs} is the actual path under the / directory on the remote host that gets mounted.

Also note that fs: on the /defaults line specifies the local location where the remote filesystem is to be mounted. It's not the name of our remote file server.

In reality, there are a couple of other variables in play behind the scenes that help resolve the values of these variables, but this is enough to discern what's going on with our automounter. You should now be able to figure out what was really happening in our simple cd command earlier in this hack.

Because of the configuration settings in amd.conf and amd.net, when I ran the cd command earlier, I was actually requesting a mount of fs:/linux/local under the directory /net/fs/linux/local.amd, behind my back, replaced that directory with a symlink to /.automount/fs/root/linux/local, and that's where I really wound up. Running pwd with no options will say you're in /net/fs/linux/local, but there's a quick way to tell where you really are, taking symlinks into account. Look at the output from these two pwd commands:

 $ pwd /net/fs/linux/local $ pwd -P /.automount/root/fs/linux/local 

TheP option reveals your true location.

So, now that we have some clue as to how the amd.net /defaults entry works, we need to figure out exactly why our wonderful hack works. After all, we haven't yet told amd to explicitly mount anything!

Here's the entry in /etc/amd.net that makes this functionality possible:

 * rhost:=${key};type:=host;rfs:=/ 

The * wildcard entry says to attempt to mount any requested directory, rather than specifying one explicitly. When you request a mount, the part of the path after /net defines the host and path to mount. If amd is able to perform the mount, it is served up to the user on the client host. The rfs=/ bit means that amd should request whatever directory is requested from the server under the root directory of that server. So, if we set rfs=/mnt and then request /linux/local, the request will be for fs:/mnt/linux/local.