UUCP + Pager = Automated Warning System
Carlos Francisco Gomez One year ago, while trying to implement UUCP for the first time in my new position as system administrator for a secure network, I toyed with the idea of using the modem to call my pager. I had already begun writing scripts to monitor my system's overall state, and liked the idea of the computer telling me when it had a problem. Internal UNIX Newsgroups at my job did not provide me a solution for this. Lately, I have found that the implementation is quite simple. This article presents a list of benefits, a few caveats, my implementation, observed performance data, and conclusions. Benefits 1. An automated paging system could be linked to any custom monitoring script to inform the administrator when there may be a problem, allowing him or her the potential to resolve an issue before users notice it. 2. Existing automated paging system products, expensive and possibly requiring additional hardware, would no longer be necessary. 3. The pager could be used in reverse, to inform the administrator that everything is okay. In this approach, not receiving a page around a certain time would signal that there might be a problem. This would be especially useful for troublesome modems, which can be periodically "tested" using this method. 4. The pager could be used to inform the administrator of the progress of automated test suites, placing a call when different stages of the test have been completed. I have already done this in the case of a five-hour automated test suite -- I was able to go home and have the pager update me as to the progress, telling me when the suite had finished. 5. The pager could be part of a built-in request service, in which users requested an action, service, or problem resolution from the administrator without ever knowing the administrator's pager number or needing a phone. Caveats 1. UUCP, as implemented, wants to connect to another UUCP machine. A pager service "looks" like a dead machine, since it does not begin a UUCP session. Therefore, there is no real way to guarantee that the page has been successfully placed. 2. A fully integrated implementation would involve a "uupager" binary executable that interacts with the modem to place a message. This, however, becomes an issue to be solved by OS vendors in release XX. Currently, this tool is available only from third-party sources. 3. If not carefully implemented, the pager could break otherwise stable UUCP configurations. 4. In this implementation, information can be transmitted only in the form of a unique numeric code that stands for a specific problem. Requirements for alphanumeric paging services also become subject to solutions from third-party sources. Implementation For my implementation, a Sparc 2 (Sun OS 4.1.2) is attached to an AT&T 7400B Data Module via /dev/ttyb, which supports the Hayes Modem Protocol. According to the Sun Microsystems manual, this UUCP implementation "is based on the version distributed with AT&T's System V Release 3, which in turn is based on Honey-DanBer UUCP. It also has some elements based from BSD 4.3, as well as some Sun modifications." The target pager is a standard Motorola Bravo Express numeric pager. The paging service has a standard interaction in which a person telephones the pager number, waits to hear three beeps, and dials then his/her own number, followed by a "#" sign. Three UUCP configuration files have to be modified. Figure 1, Figure 2, and Figure 3 are excerpts from these files, showing standard Hayes device configurations and their "pager equivalents." Listing 1, uupager, is the paging script that actually executes a call. A copy of this script was placed in the /usr/bin directory. Observed Performance Data In order to test the reliability of the system I made five test entries in the /etc/uucp/Systems file, as shown in Figure 4. Then I wrote a simple loop script that would call these "machines" in succession, once every two minutes, for a total of 30 calls in one hour. This script is shown in Listing 2. Table 1 shows the observed results. Conclusions While the performance was far from perfect, I was very happy with the results. Overall, I was successfull in placing a page over 50 percent of the time, as shown in the Totals in Table 1. Since there are many variables beyond my control, the uupager script takes this into account and tries multiple times to place the call. I leave it to more experienced system administrators to create an improved and possibly binary solution.
About the Author
Carlos Francisco Gomez is a Sun-based UNIX Systems Administrator in pursuit of a Master's degree in Architecture (Technology, CAD) at UCLA. He can be reached at cfg@netcom.com.
|