We've gently eased into the summer months (or
winter doldrums for our Southern readers) with a two-month discussion
of the automounter and its configuration. By now we hope that you can
build maps, install and customize them to your heart's content, and
perhaps you've justified the need to change every single
client configuration to reach administrative harmonic convergence.
Then again, if you're like the 99 percent of our readers who inhabit the real
world (we're convinced there are some 'bots who digest each month's
offering) you've run into some last little detail separating
automounted bliss from true nirvana.

In order to enable you with powers to perform the more spiritual
acts of system management -- those that actually elicit kind words from
impressed users -- we'll take this third pass through the automounter
and NFS. We'll start by getting stopped, looking at the various ways
the automounter can get stuck, and what you can do to repair the
situations. From automounters that don't work we'll move on to those
that work too well, giving root-enabled users access to home
directories and mail spools of unsuspecting users. We'll introduce NFS
authentication to get you started on the path to a solution and take a
peek at WebNFS, Sun's filesystem for the Internet. Our final section
deals with auto-sharing and automounting removable media like CD-ROMs.
Armed with a four-corner offensive arsenal of expert tricks, you should
be prepared for anything the NFS-ready masses throw your way.

Tracing the mystery: Debugging mount attempts

Any system with hidden moving parts is bound to break. Create some
complex automounter maps and you're likely to find unexpected behavior
or get unintended filesystem mounts showing up in less than desirable
places. The automounter has two debugging flags: -T and
-v, enabling request tracing and verbose mount requests,
respectively. When the -v flag is supplied on the
automountd command line, each request is sent to syslog. With a single
-T on the command line, you'll get significant information
about the inner workings of the automounter:

	MOUNT REQUEST: name=/var/mail map=auto.direct
	opts=ro,intr,nosuid path=/var/mail
  		PUSH /etc/auto.direct
  		POP /etc/auto.direct
  		mapname = auto.direct, key = /var/mail
     			(nfs,nfs) / 	-rw,intr,nosuid,actimeo=0	sunrise:/var/mail 
  		nfsmount: sunrise:/var/mail /var/mail rw,intr,nosuid,actimeo=0
  		ping sunrise OK
  		mount sunrise:/var/mail /var/mail (rw,intr,nosuid,actimeo=0)
  		mount sunrise:/var/mail OK
	MOUNT REPLY    : status=0

Supply a double trace flag (-T -T) and you get detail
targeted at those with source code.

Killing the automounter and restarting it with a plethora of flags
isn't conducive to rapid problem solving or user satisfaction. If you
have a variety of volumes mounted, it may be hard to kill the
automounter gracefully and have it start up again without side
effects. Fortunately, there's a back door into setting the debug
options. When the automounter sees a lookup request for a file name
starting with an equal sign (=), it parses the name to see if it
matches one of the following settings:

	=v	Toggle -v on/off
	=0	Turn off all tracing
	=1	Set -T (simple trace)
	=2	Set -T -T (advanced trace)

This trick only works for indirect mount points, where the
automounter would match the file name component to a map key.

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine