Script Manager

Ed Quillen

Scripting is an invaluable tool for UNIX systems administrators. We constantly fix complex problems with a script here and a script there to keep everyone happy. When a seemingly insignificant and very hard-to-find script breaks for some odd reason, the whole house of cards can fall. The person who wrote that script may be somewhere in Redmond selling penguin dolls or something, and you have to fix the problem. Collecting the following basic pieces of information about scripts will help you solve most scripting problems:

• What does the script do?

• How is it used? (interactive, batch, or daemon)

• What are the script inputs?

• What are the script ouptputs?

• Which scripts are its parents and which are its children?

• When has this script been used?

The classic way to find these answers is to have a documentation standard in which the author is expected to include information about the script somewhere within the script itself. The problem is that it is not fun to write that comment block and sys admins are not developers. It can be very tempting to move on to the next problem as soon as you get the script working. I know because I have left scripts undocumented in the past.

Script Manager (or SM) is a tool I wrote to try to make scripting more manageable. The tool mainly does this by requiring the collection of basic information about a script before that script is usable. This makes the act of writing a script and jamming it into production a bit more time consuming, but it is well worth the effort.

What is SM?

SM is a Perl program written in eight different Perl modules along with a main program. To allow ftp access to repositories, the libperl modules written by Graham Barr are included as well. SM was developed and tested on both Solaris and Linux but should also work on any flavor of UNIX as long as Perl 5.002 or greater is installed on the system.

SM has the following features:

• Provides a hierarchical structure similar to a directory structure for storing scripts.

• Allows for the detailed definition of shells outside of scripts. This increases the portability of scripts from system to system by removing the shell definition from inside the script itself.

• Tracks script dependencies by recording parent and child script dependencies at execution time.

• Controls the process environment before the script runs, including the working directory, umask, and detailed control over all environment variables.

• Logs all script executions to either a file or a program (such as logger for sending the information to syslog). Current data collected is: start time, stop time, username, uid, complete command string with arguments, parent process, and return code.

• Allows for the storage of documentation along with the script.

• Supports an apropos-like command for searching documentation and script descriptions.

• Improved script browsing due to script descriptions and an indicator showing whether documentation exists for the script in question.

• Can easily manage binary executables.

• Can be used to restrict which users on which hosts are allowed to execute a script.

• Allows for the use of ftp to access central repositories when NFS is not an option.

• Allows for, and in most cases requires, the following information to be kept about scripts entered into SM:

• Time created

• Time modified

• Owner

• Owner uid

• Owner gid

• Shell type -- Which shell (if any) to use and with what options.

• cwd -- Which directory to change to (if any) before running the script.

• umask -- What to set the umask to (if at all).

• Environment modifications -- Details about which environment variables to delete, replace, append to, prepend to, or leave alone.

• Script type -- Whether interactive, scheduled batch, ad hoc batch, or daemon.

• Importance -- Low, medium, or high

• Audit level -- Low, medium, or high

• Author name

• Authored date

How to Install and Configure SM

Installing SM is as simple as running the install.sh script that comes with SM. It will prompt you for a directory to store the SM packages and files and also a directory where the main executable sm should be placed. The SM executable is customized to store the location of your Perl binary and the SM package directory by the install script.

To configure SM, you will need to define at least one, and possibly multiple, repositories that are just UNIX directories or standard ftp URLs for remote access to repository directories. You should also define various shells. Defining shells is not a strict requirement but provides a lot of flexibility because it allows you to attach a generic name of a shell to a script and use that name to set exact shell paths and options. Some of the common shells are configured by default. You can use the list_shells command to see the current list. In addition to repositories and shells, there are a few other options that can be set.

Configuring is done mainly through sm.conf files. The following sm.conf files are read in the order listed:

/etc/sm.conf
/etc/sm.conf.<HOSTNAME>
~/.sm.conf
~/.sm.conf.<HOSTNAME>

and the file pointed to by the SM_CONF_FILE environment variable. To define repositories in the config files, use the following syntax:

repos <repository_name> = <absolute \
                           directory path>
repos <repository_name> = <ftp_url> (
ftp://username:password@hostname/directory)

To define a shell in the config files, use the following syntax:

shell <shell_name> = <shell def>

<shell def> must contain an absolute path to a shell program and the following two macro strings for placing the shell script and arguments, respectively: {file} and {args}. For example:

shell perl_strict=/usr/bin/perl -w {file} {args}

there are config file options:

default_repos=<reposname>       (default: default)
log_file=<filepath or |command>  (default: /var/tmp/sm.log.<USERNAME>)
retain_env_var=<varname>        (keep this env variable during run
                                 if set to wipe all vars)
dont_wipe_env_vars_by_default=0|1 (default:0)
use_runners_umask_by_default=0|1  (default:0)

The following environment variables can be used to configure the SM run:

SM_CONF_FILE -- sm.conf file to use in addition to the defaults. SM_REPOS -- Which defined repository to use (instead of “default”). SM_ REPOS_DEF -- Undefined repository directory to use; overrides SM_REPOS.

Running SM

SM is currently a command-line based program that allows you to do most of the obvious functions that would be needed for traversing a hierarchical structure and creating, deleting, modifying, executing various scripts and levels (level is just the term I use for directories in SM). Figure 1 shows a list of the functions that can be performed by the sm command:

Conclusion

Although SM tackles some of the basics when it comes to script management, there are quite a few features that would make it more useful, such as better reporting functions, more auditing options such as capturing environment variables and STDERR, version control for the scripts, and a menu interface. I hope to have a few of these items implemented by the time you read this article and will be looking for help with the others. Feel free to send me email. Happy scripting!

About the Author

When not working on consulting projects for Sprint Paranet, Ed spends his time with his wife Jill and 3 year old daughter Megan. He can be contacted at ed@quillen.net.