How our automounter replacement works

February 20, 2008

As I've mentioned in passing, at one point we got so irritated with peculiar automounter issues that we wrote our own replacement that does what we want. It turned out to be fairly simple, because what we want is just to keep each system's mounted NFS filesystems in sync with a master list.

Since this is basically diff, you could clearly do this in a shell script. I opted to write the core of the system in Python so that it would be easier to handle an existing mount changing as well as mounts appearing and disappearing.

(Also, at a certain point you are actually writing a program instead of just a shell script, and the Bourne shell is not a great programming language. Your successors will thank you for writing in something clearer.)

The core Python program reads the master list and mount -t nfs's output and spits out shell commands to reconcile the system's state. For new mounts it mkdir's the mount point if necessary and does the NFS mount; for now-dead mounts it does a umount -f and then rmdirs the mount point if it is one of our special hierarchies. If an NFS mount changes parameters, we unmount the filesystem and then mount it again; while we might be able to do some changes with mount -o remount,..., there are some that we can't do that way (for example, changing the source of a mount point).

The core program is wrapped in a shell script that finds the right configuration file and feeds the program's output to a shell, shows it to the sysadmins, or both, depending on options. The shell script is then run from cron every ten minutes or so, and it gets run during boot to get all the NFS mounts set up.

(The shell script also checks local and global flag files that tell it to do nothing, so that we can manually manipulate NFS mounts without having our actions undone in the next ten minutes. You want this feature, trust me.)

Error handling is simple. If an umount or a mount fails, there's no need to do anything special; the next time the script runs, it will notice that things are not in sync and try to fix them.

Written on 20 February 2008.
« Coding paralysis
The irritation of single-instance applications »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Feb 20 01:00:57 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.