A Web-Based Helpdesk

Ron Shalhoup

One of the major challenges of system administration, organizing and handling user requests, becomes much more manageable by establishing policies for acquiring assistance at your site and implementing a tool to prioritize and track user requests. A Web-based tool for tracking and managing user requests is an ideal solution because the vast majority of workstations have a browser from which the database may be accessed. A Web-based solution also provides simple implementation with its inherent cross-platform support.

The Web helpdesk described here accepts user requests through email messages and automatically stores them as HTML-formatted files. The user requests progress through a life cycle of unassigned, assigned, and closed. The Web helpdesk allows administrators to view, prioritize, and assign unassigned user requests; view, reassign, close, or append comments to assigned user requests; and finally view or reopen closed user requests. At each stage of the user request life cycle, the status of the request is updated in the file's header data and a mail message is automatically issued to both the assigned engineer and the user who generated the request.

The Web helpdesk system consists of 5-6 Perl scripts and 3-4 HTML files, depending on the pieces you decide to implement. This system was developed on a Solaris server running NCSA's httpd Web server (version 1.5.2). Porting to other systems is definitely possible. However, the discussion that follows assumes you're running the mentioned configuration.

Configuration

First, install the Web helpdesk system into the document root directory of your Web server. The tool's sources can be retrieved from http://www.captech.com. Once installed you will find a top-level helpdesk directory containing html files, a scripts subdirectory containing the required Perl scripts, and a data subdirectory used as a repository for all user requests. You will need to create a file called .engineers in the data subdirectory that contains the mail IDs of any administrators to which user requests can be assigned. Each administrator's mail ID should be placed on a line of its own in the file.

Next, configure your Web server to treat the script's subdirectory as a cgi-bin directory. To do this, add the following line (or a variation based on your actual placement of the file) to the srm.conf file in the Web server's conf directory.

ScriptAlias /helpdesk/scripts/ \
/usr/local/etc/httpd/htdocs/helpdesk/scripts/

This line instructs the Web server to execute the files contained in the scripts subdirectory rather than simply displaying their contents. The helpdesk's scripts require Perl to be installed on your system and the cgi-lib.pl library to be installed in the Perl lib directory. This library provides a mechanism for developing CGI scripts in Perl. If your Perl distribution did not contain cgi-lib.pl, it can be retrieved from http://www.bio.cam.ac.uk/cgi-lib.

Each of the helpdesk's scripts include the hd-lib.pl (available at www.samag.com) library script. This script contains variables and subroutines common to all of the other Perl scripts. Several of the variables contained here can be customized for your site. One such variable, $MAILER, assigns the program to be used by the helpdesk for mail delivery. The default setting is /usr/bin/mailx. Other mail programs may be used but must have a command-line interface that uses the -s subject and -c cclist switches.

The Web helpdesk receives incoming requests through email messages. The following line must be added to the system's mail alias file to allow this to work

helpdesk: "|/usr/local/etc/httpd/htdocs/helpdesk/scripts/mail2hd.pl"

This line instructs the mail system to pipe all mail destined for helpdesk to the mail-handling script.

Incoming Requests and the Helpdesk Database

The mail-handling script, mail2hd.pl (available at www.samag.com), reads the incoming mail message line-by-line searching for the subject line and sender's address while saving the message contents. This information is used to create an HTML-formatted file that is stored in the data subdirectory. The helpdesk system uses the filesystem for its database with dot-separated data fields stored within the name of the files. Therefore, filenames are critical to the operation of the system. Files are initially named with the following format

<SUBJECT>.<SENDERS_ADDRESS>.<REQUEST_ID>.<DATE>.html

When new mail messages are received, the subject line may contain characters that are meaningful to the operating system and consequently interfere with the operation of the tool. The mail-handling script either removes or transforms such characters prior to making the subject line part of the filename. Likewise, non-local email addresses contain dots (.) which are used as field separators. The script substitutes two underscores (__) for any dots in the sender's address. By making the substitution string distinguishable and something unlikely to appear in an email address, other scripts that require this address can easily transform the string back to its original form in order to successfully reply to the user who submitted the request.

The script uses the .count.txt file, stored in the data directory, to obtain a unique ID for the user request. This one-line file contains a number initially set to zero and incremented upon each invocation of the script. The date field that appears in the filename is obtained through a Perl subroutine.

Displaying the Helpdesk Forms

The top-level helpdesk directory contains the HTML files used to display the initial helpdesk screen. When accessing the helpdesk, the index.html file (available at www.samag.com) is loaded by default. index.html displays a frame-based document that contains a menu in a sidebar frame and the subsystem that allows you to view and assign unassigned user requests in the main frame Figure 1. The HTML file, frame_menu.html (available at www.samag.com), is the document that displays the menu in the sidebar frame. From the menu, the user can easily move between the various subsystems of the helpdesk that are presented in the main frame.

The script used to view and assign unassigned user requests is hd-assign.pl (available at www.samag.com). This script both presents a form to the user and processes the form once it is submitted. It knows to process the form data depending upon whether the CGI variable CALLTRACK has been set. When the script is first called, none of the CGI variables contain values. The script presents the user with a table of unassigned user requests obtained from a listing of the data directory. The script determines the state of the user request (unassigned, assigned, or closed) by the number of fields present in the filename. Unassigned user requests are of the form

<SUBJECT>.<SENDERS_ADDRESS>.<REQUEST_ID>.<DATE>.html

The script uses the fields from the filename to display in the table. Within the table, the subject field has a link to the actual user request file. The operator can view the contents of the user request file by accessing this link. Each table entry also has a radio button associated with it so that it can be selected. The form allows the operator to assign a priority to the user request and has input fields for entering keywords, comments, and any parties who should be copied on the mail messages generated during the life cycle of the user request. To assign a request to an engineer, the operator selects one of the unassigned user requests by clicking on the radio button, chooses an engineer to assign to the user request from the engineer pick list, enters data into the other optional fields, and submits the form by clicking on the ASSIGN button. This action places values in the CGI variables and re-executes the script. Assuming one of the user requests was selected, thereby setting the CALLTRACK variable, the form is processed. If the operator submits the form without selecting a user request, the values of the other fields are remembered and once again presented to the user when the form is redrawn. No other processing takes place in this situation.

When the operator assigns a user request to an engineer, several events take place. First, the values contained in the input fields are gathered. The script then opens the file that contains the user request and inserts the pertinent data from the input fields into the text. This data appears as header information in the file and are updated upon each action taken throughout the user request's life cycle. Figure 2 shows the contents of an example user request file that has been assigned to an engineer. The revised text is then saved to a new file whose name is of the form:

<SUBJECT>.<SENDERS_ADDRESS>.<REQUEST_ID>.<DATE>.<ENGINEER>.html

After successfully creating the new file, the script removes the old file from the system. By adding the new field <ENGINEER> to the filename, the user request will no longer appear in the unassigned user request table and will now only appear in the assigned/open user request table.

The script also issues a mail message containing the updated text of the user request to the assigned engineer, the request initiator, and any parties listed in the CCLIST variable. The initiator now knows which engineer is working on his or her request and the engineer receives notification of his or her new task.

The other scripts that manipulate user requests, hd-open.pl and hd-close.pl, are functionally similar to the hd-assign.pl script. The hd-open.pl script (available at www.samag.com) presents a table of open user requests to the operator. The form provides a pick list for the operator to view the open requests assigned to a particular engineer or all engineers. The form also provides the operator with the ability to close, reassign, or append comments to an open user request. If the operator selects a request and closes it, the script gathers any comments entered by the operator and inserts them into a new user request file. The new file is named with the format

<SUBJECT>.<SENDERS_ADDRESS>.<REQUEST_ID>.<DATE>.<ENGINEER>.<CLOSER>.html

After successfully creating the new file, the script removes the old file from the system. By adding the new field <CLOSER> to the filename, the user request will no longer appear in the assigned/open user request table and will now only appear in the closed user request table. The operator also has the ability to reassign the user request. To do this, the operator selects a request and an engineer to whom the user request will be assigned and submits the form. The script replaces the <ENGINEER> field in the filename with the ID of the new engineer. The request remains in the assigned/open user request table, but now appears in the new engineer's queue as well. One final option provided by the form allows the operator to add comments to the user request file without making any changes to the status of the user request. This is done by selecting a user request, adding comments in the provided space, selecting the Append option, and submitting the form. In each of the above scenarios, the script updates any pertinent header information within the user request, appends any entered comments to the user request file, and informs each of the interested parties of the action via email.

The hd-close.pl (available at www.samag.com) script provides the user with the ability to view and reopen closed user requests. The script displays a table of all closed user requests. The operator may reopen a user request by selecting a closed request and submitting the form. When this occurs, the script removes the <ENGINEER> and <CLOSER> fields from the filename of the request file. The filename is now in its original format. However, the contents of the file maintain any comments added during the request's life cycle, and the header information is updated with the latest action.

Access and Security

If you are concerned about securing the helpdesk system, you can restrict access through the mechanisms provided by the Web server. When I compiled the NCSA httpd version 1.5.2 Web server, I configured it to use NIS passwords for its access method. This reduces the added administration of an additional password file and allows the users to use their familiar system passwords. With this method you are still required to create an .htaccess file in the directory for which you are restricting access. Figure 3 displays a sample .htaccess file that uses the NIS password map for authentication. By authenticating users before providing access to the system, the system is informed of who requested access and uses this information to set the default value in the engineer pick list to the operator if he or she is listed in the .engineers file.

Additional Capabilities

To get the most from the helpdesk system I recommend adding search capabilities. By creating an additional form that uses a search utility such as grep, an operator could search the user request files for a particular string. With some creativity, the search could be limited to search only particular fields in the request's header information such as "Subject Keywords." One other possibility for adding search capabilities is to attach a search engine such as Excite to the database. Once in place, the data could automatically be indexed by a cron job. Either of these solutions can easily be added to the sidebar menu for fast access. Adding search capabilities to the tool makes it easy to track user requests and provides a convenient mechanism for finding solutions to common problems. This is especially useful for entry-level administrators.

Another suggestion for improving the functionality of the tool is to add a form from which users can submit requests. This can be customized so that users know what information to submit and are required to supply critical information. Users may prefer this method since all they need to do is fill in the blanks and submit the form. This method is also useful if there is an operator who assigns user requests to engineers. By requesting the right information, the dispatcher will have the information required to match the request to the skill sets and abilities of engineers.

Conclusion

The helpdesk system has worked very well in production at several sites since last summer. One of its best attributes is its accessibility. CGI scripts and the Web provide a means to quickly develop robust applications that can be run from nearly every workstation. The Web helpdesk system is a good example of how Web technology can be used to provide a simple solution to a common problem.

About the Author

Ron Shalhoup, M.A., has worked in the computer industry for the past eight years both as a software developer and as a Systems and Network Administrator. Ron currently works for Diba, Inc., a leading provider for the Information Appliance marketplace. He can be reached at: ron@diba.com.