Article Listing 1 Sidebar apr2007.tar

SortingHat -- Which Server Do You Belong In?

John Spurgeon and Ed Schaefer

We are responsible for administering several servers distributed around the world. Each server is configured more or less the same way. However, a variety of attributes are unique to a particular server: nodename, IP address, default router, etc.

We developed a utility called changeident (Spurgeon & Schaefer, 2004) to facilitate the configuration of many server-specific parameters. The modules that comprise changeident typically update or replace existing files using variables and hard-coded logic. For example, changing the nodename of a server involves commands like "echo $new_nodename > /etc/nodename".

Some files, such as users' crontab files, are too complex for this approach. Instead, we use a Korn Shell script called SortingHat (see the sidebar "What's in a Name?"). SortingHat replaces existing files with copies of files that are preconfigured for specific servers.

The Directory Structure

The SortingHat script (Listing 1) makes use of several directories to manage and organize files:

SORTINGHAT_DIR=/opt/SortingHat
SERVERS_DIR=$SORTINGHAT_DIR/servers
DEFAULT_DIR=$SORTINGHAT_DIR/default
BACKUP_DIR=$SORTINGHAT_DIR/backup
CURRENT_DIR=$SORTINGHAT_DIR/current
The "servers" directory contains several subdirectories. The name of a subdirectory is the hostname of a server. And each of these subdirectories may contain more subdirectories and files. For example, a copy of the hosts.equiv file for a server named pongo would be located at:

/opt/SortingHat/servers/pongo/etc/hosts.equiv
The default directory may contain files to be installed if a file doesn't exist on a specific server in the "servers" directory.

The backup directory is used to store backup copies of files that have been replaced. Multiple backup copies are maintained in the event a file is backed up more than once.

The current directory is a holding area that contains a copy of the file that will be installed when the -r option is used.

The Options

The best way to explain SortingHat is to describe the script's options and then use them in an example. SortingHat expects one argument -- a full path to the file being acted upon -- which we call the current file. Nothing exciting happens unless the options are used:

    -f -- Simply find the file.

    -l -- List the contents of the file.

    -b -- Back up the file in the server's directory under the SortingHat directory. The backup option only works in conjunction with the find option

    -r -- Replace the current file with the file that exists in the server's directory in the SortingHat directory. If that file does not exist, use the file that exists in SortingHat's default directory.

    -h -- Override the current hostname. If the -h option isn't used, SortingHat uses the contents of the /etc/nodename file to set the hostname.

We're concerned that in our Solaris environment, an external command might require a reboot to take effect. If you find this unacceptable, consider using the Unix hostname or uname command.

The Example

Assume that our test file is /tmp/testfile and our server is named pongo. Executing the command SortingHat -fb /tmp/testfile delivers this output: 

/opt/SortingHat/bin/SortingHat...
File: /tmp/testfile
Searching for /opt/SortingHat/servers/pongo/tmp/testfile
Found /opt/SortingHat/servers/pongo/tmp/testfile
Current copy: /opt/SortingHat/current/tmp/testfile
Backup copy: /opt/SortingHat/backup/tmp/testfile
A copy of the current /tmp/testfile is created in SortingHat's current directory. The tmp directory is also created if it doesn't already exist.

Also, a backup copy of the test file is also created in SortingHat's backup directory. The file name is actually a soft link:

testfile -> /opt/SortingHat/backup/tmp/testfile.070206.142827.19389
The actual file name is a combination of file name, date, time, and process id. The next time SortingHat backs up /tmp/testfile the soft link points to a new file leaving the older file alone.

SortingHat isn't of much use unless you replace something. Executing the command SortingHat -fbr /tmp/testfile delivers this output: 

/opt/SortingHat/bin/SortingHat...
File: /tmp/testfile
Searching for /opt/SortingHat/servers/pongo/tmp/testfile
Found /opt/SortingHat/servers/pongo/tmp/testfile
Current copy: /opt/SortingHat/current/tmp/testfile
Backup copy: /opt/SortingHat/backup/tmp/testfile
Replaced /tmp/testfile
Since the SortingHat directory contains a /tmp/testfile for pongo, this file replaces the original /tmp/testfile. If pongo doesn't have a tmp/testfile, the default is used, and the command's output looks like this:

File: /tmp/testfile
Searching for /opt/SortingHat/servers/pongo/tmp/testfile
Searching for /opt/SortingHat/default/tmp/testfile
Found /opt/SortingHat/default/tmp/testfile
Current copy: /opt/SortingHat/current/tmp/testfile
Backup copy: /opt/SortingHat/backup/tmp/testfile
Replaced /tmp/testfile
Finally, if SortingHat tries to replace a file that has no object in the SortingHat's server directory or in the default directory, nothing happens.

Also SortingHat doesn't check file permissions. In our environment, other maintenance scripts such as changeident use Sortinghat -- called almost exclusively by root or other maintenance accounts.

What's in the Tarball

Extracting the tarball creates the Sortinghat directory structure including the testfile example. The tarball was created using relative pathnames. If you change SortingHat's location to something other than the opt directory, don't forget to change the script's SORTINGHAT_DIR shell variable. The tarball can be found on the Sys Admin Web site: 

http://www.sysadminmag.com/code
In our environment, the SortingHat script resides in the /opt/SortingHat/bin directory, and that path is included in our PATH variable.

References

Spurgeon, John and Ed Schaefer. 2004. "Managing System Identity with changeident." Sys Admin. 13(1):22-29.

John Spurgeon is a software developer and systems administrator for Intel's Factory Information Control Systems, IFICS, in Hillsboro, Oregon. He is currently preparing to ride a single-speed bicycle in Race Across America in 2007.

Ed Schaefer is a frequent contributor to Sys Admin. He is a software developer and DBA for Intel's Factory Information Control Systems, IFICS, in Hillsboro, Oregon. Ed also hosts the monthly Shell Corner column on UnixReview.com. He can be reached at: shellcorner@comcast.net.