Using the Amd Automounter

How to use the Amd automounter to provide uniform and easily controlled access to all your file servers from anywhere.
/net Maps

A common use for automounter maps is to allow the mounting of any filesystem from any host, often called a net map. This map entry provides a comprehensive and uniform way of accessing all file servers:

/defaults  fs:=/a/${rhost}/root/${rfs}
*       rhost:=${key};type:=host;rfs:=/

This short example packs a lot of punch. First, we define the default fs variable's value to be a pathname that uniquely identifies the remote NFS server and filesystem being mounted. We can do this because the fs variable defines the pathname on the local host where Amd mounts remote hosts' filesystems. This pathname must be unique to avoid conflicts.

Second, the actual map entry's key, an asterisk, is a wild-card entry that matches anything and sets the key variable's value to the value of the name being looked up inside /net. This wild-card key value becomes the remote host's name (rhost). Next, we specify a special Amd mount entry of the type host, and we set the rfs variable to request mounting of all exported filesystems from that remote host (starting with /). The host mount type in Amd works by querying the remote host's rpc.mountd dæmon for the list of all exported filesystems. It then mounts each of them in turn. For example, suppose host foo exports two filesystems named /homes and /proj/X11. If you chdir to /net/foo, Amd mounts foo:/homes in /a/foo/root/home and mounts foo:/proj/X11 in /a/foo/root/proj/X11. An ls in /net/foo conveniently shows these two mounted directories.

One Map to Rule Them All

In large sites with many subgroups (sometimes with partial administrative control over the main group), there often are scenarios in which what you can mount depends on where you are. For efficiency, you may be limited on distributing binaries for different architectures to different subnets. With a single centralized set of Amd maps, it is possible to accommodate local needs:

/defaults  type:=link
lbin  in_network(eng);fs:=/local/${arch}/bin \
      in_network(10.0.1.0/24);fs:=/x/beta/bin

This map uses the in_network function selector. Function selectors evaluate to true or false based on the current system conditions and the parameters passed to these functions. This selector compares whether the current hostname is part of the eng network, often defined in /etc/networks. If so, Amd expands the value of the arch variable to the current running architecture. It also resolves the lbin entry to /local/i386/bin on IA-32 systems, to /local/sparc/bin on SPARC systems and so on. The next location in this map shows that the in_network selector can match against network/netmask pairs. In fact, not only can this selector match using several forms, but it can match against any local interface up and running on your host. This capability offers the benefit of optimizing network routes on multihome hosts.

ISO-9660 Images

Many people keep ISO-9660 CD-ROM images handy, but accessing their content requires burning them onto a CD-ROM or mounting the images on Linux using a special loop driver. The cdfs mount type knows how to mount ISO-9660 CDs. But if you list a filename in the dev parameter and specify the loop mount option, Amd can mount those ISO image files directly. You then can browse them without copying the files out of each ISO image:

/defaults  type:=cdfs;opts:=loop
shrike1  dev:=/iso/rh9/shrike-disc1.iso
shrike2  dev:=/iso/rh9/shrike-disc2.iso
shrike3  dev:=/iso/rh9/shrike-disc3.iso

Do-It-Yourself Maps

Every self-respecting tool should have built-in extensibility mechanisms to accommodate the unexpected. For Amd to mount a given filesystem, it has to know how to mount it ahead of time (read: yours truly hacks the C sources). Using the program type mounts, you can define a custom method for mounting and unmounting any filesystem your native host knows about but which Amd doesn't:

r2  type:=program;dev:=/dev/sda1;\
      mount:="/sbin/dohans dohans ${dev} ${fs}";\
      unmount:="/sbin/undohans undohans ${fs}"

The above example passes the predefined dev parameter, as well as the automatically determined fs parameter to, say, a shell script named dohans that can perform whatever is needed to mount /dev/sda1 as a ReiserFS.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState