A System Administration Log Program Using Tcl/Tk

Scott Tarvainen

Many computer programmers are notorious for poorly documented code, or for not documenting their code at all. This can cause many problems for the person who must maintain or troubleshoot that code. Many system administrators also poorly document the myriad tasks they perform on a daily basis. Michael Ault, in the UNIX System Administrator's Companion (John Wiley & Sons, Inc., 1996), called documentation "the programmer's and system administrator's bane -- a necessary evil that can, and will, save your life."

Proper documentation can be critical in a team situation, such as a help desk environment. Imagine the frustration of a system administrator who has just spent hours troubleshooting an application error only to learn that his fellow administrator received a patch from the software vendor for that same problem and failed to notify the rest of the staff.

These types of problems highlight the need for a system that allows members of a system administration team to share information on a daily basis. Such a system would allow a system administration staff to be apprised of important changes to system/network architecture, software fixes applied to resolve particular problems, and other significant information. To this end, I have adapted a Tcl/Tk database program, tkdb written by Norman Walsh and published in X User Tools by O'Reilly & Associates, to perform just such a function (see Tcl/Tk sidebar for further information about Tcl/Tk). I have enhanced the original tkdb program to allow database records to be deleted and printed. Ialso wrote a Bourne shell front end to the program to control the structure of the Tcl/Tk database and to manipulate database creation and access. The modified tkdb program has been renamed AdminLogDB, and the Bourne shell front-end is called AdminLog.sh.

When creating the AdminLogDB program, I decided that the application should create a new database file on a daily basis. The advantages to a daily log file are two-fold: hard-copy output of the log files for historical purposes can be easily maintained, and online searches for information within the daily database files, using UNIX tools such as grep or egrep, are possible. As with all system log files, disk space limitations must be considered. Because a new database file is created each day, you must monitor system disk space and purge or archive old database files on a regular basis.

The AdminLogDB program was designed with an NFS type of environment in mind, allowing database access from any workstation on a network. Special considerations were made to ensure that concurrent database accesses did not result in database inconsistencies. I resolved this issue by allowing only one user to access the AdminLogDB program at a given time.

The Programs

AdminLog.sh (Listing 1), the Bourne shell front end to the AdminLogDB database program (Listing 2), utilizes the UNIX date command to ensure that a new database is created on a daily basis. Both the AdminLog.sh and AdminLogDB programs reside in the /usr/local/bin directory on our system. This directory is NFS mounted on all workstations on our network, so that local system administration programs can be accessed from any seat. The first line of the AdminLogDB program is the call to the wish interpreter. In this example, wish resides in /usr/local/bin. (This should be modified to reflect the appropriate wish directory for your system. The wish interpreter is further explained in the Tcl/Tk sidebar.)

The subdirectory /usr/local/bin/AdminLogs is created as home to the daily system administrator log database files. The user has the option to open the current day's log, or a previous log (see Figure 1). If the current day's log does not yet exist, it will be created and opened for input. If the log already exists it will simply be opened for input. AdminLogDB databases reside in the /usr/local/bin/AdminLogs directory as flat files with a name of log.DATE, where DATE is in the format of DDMmmYYYY, such as log.10Mar1996.

When a log entry is opened for input, the user is presented with the first record in the Tcl/Tk database for that day. If the database has not been previously accessed that day, the record will obviously be empty. Figure 2 is a sample screen from the Tcl/Tk AdminLogDB program. The program gives you the option to create a new log entry, or to move forward and backward through the daily database entries. You also have the ability to save changes made to the log as well as to delete entries and print the contents of the log. The program also keeps track of which record within the database you are currently accessing. The .prev and .next fields within each database record control whether or not the "Prev" and "Next" buttons within AdminLogDB are accessible. This prevents you from moving past the end of file within the database or prior to the first record (e.g., if you are at the first record in the database, you could not logically move to a previous record, so the "Prev" button should not be accessible. Likewise, if you are at the last record in the database, you should not have access to the "Next" button).

The global variable Changed within AdminLogDB tracks modifications made to the database so that when you exit the AdminLogDB program or print database records, you have the option of first saving the changes to the database. Two temporary files are utilized by the AdminLog.sh and AdminLogDB programs. /usr/local/bin/log.tmp ensures that only one person can access the AdminLogDB database at a time, thus preventing database inconsistencies. /tmp/printfile is a temporary file created when the user wants to print the contents of the database. Database records are read one at a time and appended to the /tmp/printfile file. This /tmp/printfile file is then sent to the system printer. The AdminLogDB program utilizes an exec system call to print the /tmp/printfile to the system default printer using the UNIX lpr command. (This assumes that the default printer lp is set in the /etc/printcap file.) An example of a printed log file is shown in Figure 3.

Conclusion

Maintaining a log of system administrative activities can be a lifesaver. When I first adapted the tkdb program, I intended it to be a stop-gap measure until a more permanent program could be found. However, the adapted tkdb program described in this article has been utilized effectively at this site for more than six months with no replacement in sight. It has proven to be an effective method for sharing information between system administrators and maintaining a record of system changes affecting our network.

Bibliography

Ault, M. R. 1996. UNIX System Administrator's Companion. John Wiley & Sons, Inc. ISBN 0-474-11144-9.

Ousterhout, J. K. 1994. Tcl and the Tk Toolkit. Addison-Wesley Publishing Company, Inc. ISBN 0-201-6337-X.

Welch, B. B. 1995. Practical Programming in Tcl and Tk. Prentice Hall PTR, Prentice-Hall, Inc. ISBN 0-13-182007-9.

Nemeth, Snyder, Seebass, and Hein. 1995. UNIX System Administration Handbook. Prentice-Hall Inc. ISBN 0-13-151051-7.

Mui, L. and V. Quercia. 1994. X User Tools. O'Reilly & Associates, Inc. ISBN 1-56592-019-8.

Johnson, E. F., and K. Reichard. 1994. The UNIX System Administrator's Guide to X. M&T Books, MIS:Press Inc. ISBN 1-55828-347-1.

About the Author

Scott Tarvainen is a computer scientist/system analyst employed by Command Technologies, Inc. He has been assigned on contract with the United States Air Force to Yokota Air Base, Japan for the past two years. Scott has a Bachelor's degree in Computer Science from Michigan Technological University and a Master's degree in Education from Troy State University.