Automated System Administrator's Pager

David Dykes

Many system administrators are familiar with pagers. These inexpensive electronic leashes allow users to reach you anytime, anywhere for better or worse. Most often it is for worse, because when your users resort to paging you, something has usually gone awry.

One way to leverage this wireless technology, and perhaps remove some of the tension from being paged, is by enabling the systems themselves to page the administrator. Not only does this allow the administrator to receive system messages without being tethered to a console, but it may allow for more proactive responses to warnings rather than corrective responses to user complaints. For example, it would be preferable to have a daemon page you with a low disk space warning than a user page you complaining that he or she can't save a file.

Fortunately, today's alphanumeric (alpha) pagers are inexpensive and use a standardized protocol that make this functionality relatively straightforward and cheap to implement. In this article, I propose ASAP (Automated System Administrator's Pager) as a possible means of adding this connectivity. The article covers how ASAP works, the specifics of implementation, and some potential applications of this connectivity. Some specific OS-dependent examples are given in the context of a UNIX environment, but the real core of this system should be generalizable to almost any operating system.

How does it work?

ASAP is simply a couple of scripts that act as a gateway from Internet mail (i.e., SMTP) to an alpha pager. The first script, asap.pl, is a Perl script that parses SMTP (Simple Mail Transfer Protocol) message headers and then creates (or appends to) a "TAP friendly" spool file (see sidebar on The TAP Protocol). This spool file takes as its name the telephone number of the carrier to whom the message should be sent and is placed in /var/spool/asap. The Kermit script, asap.scr, may then be called to deliver any pending pages in the spool file(s). Care must be taken to avoid a race condition between the writing and reading of the spool files (see sidebar "Off to the Races"). The scripts asap.pl and asap.scr are given as Listing 1 and Listing 2, respectively.

As mentioned above, the spool files are named after the telephone number of the provider's modem pool. Note that any alphanumeric pager can be uniquely identified by two numbers: the PIN of the pager and the provider's modem telephone number. ASAP knows where to send the pages by looking up these identifiers in a table that maps email addresses to these tuples. Consequently, a flat file database is maintained to associate incoming email with the correct numbers. An entry in this table might look like:

#email recipient   PIN        Phone number
pagedave           5551234    18005555678

Implementation

With the brief overview given above, we can track a page sent via ASAP. Incoming email is piped into the standard input of the asap.pl script. One quick and dirty way to feed asap.pl incoming email is by way of a mail alias. In a UNIX environment, this may be accomplished by adding a line similar to the following to the mail subsystem's aliases file:

pagedave:"| /usr/local/bin/asap.pl"

This line will direct email sent to the alias pagedave to the ASAP script. Note that if the alias is a preexisting user, this line will direct mail away from the user's usual mail client, and instead direct it exclusively to the user's pager.

The Perl script parses this message for the sender, the addressee, and the subject. Once the script has found what it is looking for, it then looks up the addressee in the pin.tab file. This file provides the script with the PIN/phone number tuple described above. The output of asap.pl is a file named after the provider's phone number that contains the following three fields separated by newlines: the pager PIN, the message to send, and a checksum. An additional newline separates messages within the same spool file. You may find it ugly to use a number as a queue filename, but this nomenclature allows for some easy scripting later on and, more importantly, by definition precludes filename conflicts.

Currently, ASAP just sends a message that informs the recipient of the sender and the subject of the email. The program could be easily modified to include a timestamp or part of the message body.

At this point, there may be multiple spool files awaiting transmittal to pagers. This is work for the asap.scr Kermit script (The ksh script used to call Kermit is given as Listing 3). The asap.scr script calls the provider's modem pool and attempts to send all of the pages it has for that provider. asap.scr then terminates to be invoked again on any remaining spool files.

Applications

The design goals of ASAP were platform independence and scalability. Because of the ubiquity of ASAP's messaging protocol (SMTP) and the wide availability of Perl and Kermit, ASAP should be easily ported to nearly any platform. The generality of the scripts also should allow the package to scale well to larger environments.

As mentioned above, one application for the system administrator would be to automatically forward system messages and warnings to an alpha pager. At the Biomolecular Computing Resource at Emory, we have scripts that forward warnings of low disk and swap space, as well as some security alerts. Another application for this scalable package is to enable group messaging. Any system that can send email to multiple recipients can now page en masse. This could be useful for paging a team, such as an on-call medical staff.

Lastly, the pager messages could be fed by intelligent agents surfing the Net for information relevant to the user. For example, I like to receive certain stock quotes at the market's close and be kept abreast of weather in the Atlanta area. When intelligent agents are combined with ASAP, you can tap the vast information resources of the Internet wherever and whenever.

What Just Happened?

This article demonstrated a method for implementing an Internet mail to alphanumeric pager gateway using Perl and Kermit. It was suggested that the generality of this approach makes it suitable for a variety of environments and purposes.

About the Author

Dave graduated with a B.S. in Computer Science from the Georgia Institute of Technology in 1992. Since that time he has been working for the Biomolecular Computing Resource at Emory University in Atlanta. While at Emory, Dave has been working on an M.B.A. at Emory's Goitzueta Business School. He hopes to complete this degree in May of 1996, at which time he will be looking for a job as a Management/IT consultant. Potential employers and readers with questions about this article can email (but not page) Dave at dave@bimcore.emory.edu.