HTML as a Graphical User Interface for Sys Admin Tasks

Charles Bundy

This article is a practical tutorial for developing HyperText Markup Language (HTML)-based GUI UNIX administration tools. I present a simple login audit tool (La Tool), which generates reports for a userid selected from a dropdown scroll list. Details of how to restrict access to these HTML-based tools are outlined with respect to NCSA's httpd v1.3 World Wide Web (WWW) server.

Why use an HTML browser for system administration tasks? Traditional UNIX system administration consisted mostly of editing text files in obscure directories; however, text-only interfaces are inadequate in a modern UNIX environment dominated by graphical user interfaces such as X11. X11 has allowed various workstation manufacturers to build GUIs for sys admin tasks. Unfortunately, X11 programming is cumbersome and not readily portable to non-UNIX systems.

A nonplatform-specific way of presenting and acting upon graphical/textual data across networks would be ideal. Fortunately, a portable GUI solution is available in the form of WWW server/browser technology. A web server not only delivers HTML files, but also can act upon information coming from the browser. Mechanisms for data processing on the server end are described by the common gateway interface (CGI). CGI allows complex administration scripting on the server using any programming language.

HTML and WWW Client/Server Interaction:

The connection between a WWW browser and server is stateless. For each bit of data an HTML document requires, a communication method must be specified. This communication method can be thought of as a server command, with additional hidden information. Getting files from the server requires the get method, while sending information is usually accomplished via the post method. If a CGI program only requires a command-line parameter, data is bundled with the get method. This stateless transaction paradigm requires user authentication to be handled by the server, with implicit acknowledgment by the browser. You have the option of typing in the user name/password once to access a document or CGI binary. Otherwise you would have to type the login ID/password for each element retrieved. The browser keeps authentication information cached until you quit. This is a low level of security, but no worse than an open telnet connection.

HTML is a set of commands that can be embedded in text documents. These embedded commands partition text into logical format and link elements. The characters <, >, and / differentiate HTML commands from regular text. A logical partition beginning for text is specified by <HTML_ELEMENT>. The end of the text partition is specified by </HTML_ELEMENT>. Some HTML elements don't specifically operate on the text in a document. Instead, they are inclusive, such as inserting graphics or specialized format elements, such as paragraph breaks. These elements don't require </HTML_ELEMENT>. Listed below are HTML examples, for inline graphics, for making text bold and italic, for inserting a horizontal bar, and for specifying the end of a paragraph (see also Figure 1).

<IMG SRC="http://www.cs.virginia.edu/~ccb8m/Dgif/latool.gif">
<P>
<B><I>Bold and Italic!!</I></B>
<HR>

This sentence appears directly below the horizontal bar.
Text is displayed without any formatting information.
Without a paragraph break, the next bit of text
would be appended to this rambling monologue.<P>

This is the next sentence, and it starts a new paragraph.

The above commands are good for display purposes, but the most important HTML element is the anchor. With it you can make text or a logical HTML partition point to any Internet host in the world. Here is a bit of text turned into an HTML anchor:

<A HREF="http://www.cs.virginia.edu/~ccb8m">
Charles Bundy's home page.</A>

Anchor elements are important, because they give users local control of data, while supporting global accessibility. If you have httpd authentication set up, "global" refers to machine type, rather than "devious hacker."

The example anchor command requires a hypertext reference parameter (HREF). The HREF parameter is a Uniform Resource Locator or URL. The URL is split into three parts. The first two parts are network related and specify what kind of resource server to contact. If the reference specifies http the browser would use default port number 80 and expect httpd to accept commands. If, instead, the URLspecified ftp, the browser would use port number 21 and expect ftpd to accept commands. Immediately after ://, is the machine address of where to send server commands. The third part of a URL specifies which file to retrieve. The path to this file is relative to the default HTML document directory. My http server uses /http/htdocs as the default HTML document directory. If a ~USERID is specified, httpd goes to that user's home directory and appends a default HTML document subdirectory. If an HTML document/path is not specified, a default file name is used. In the anchor example above, the browser opens a connection to the University of Virginia Computer Science WWW server. It sends a get method to port number 80 requesting that the default file index.html be retrieved from the subdirectory /uf12/home/ccb8m/public_html.

Common Gateway Interface (CGI)

Under most circumstances a browser will send commands that the server directly processes. Most of these commands are "get a file and send it to me." Once the file gets to the browser, either it is displayed or a helper application is called. Web browsers can process HTML and GIF data, but don't have a built-in WordPerfect viewer. Thus, WordPerfect would be called as a "helper application" to display a datastream that is foreign to the browser. The reverse case would be when a browser needed to send something that required complex processing on the server end.

Servers cannot do generic processing. They must pass data to a local program that can act upon the information. The mechanism for passing data to a program and sending the results (usually HTML) back to a browser is defined by the CGI. CGI isn't a programming language, it is simply a definition of how data is to be transferred. Three transfer methods are specified in the HTML 1.0 standard: standard input, environment variables, and command-line parameters. Most CGI binaries use a combination of standard input and environment variables, and La Tool does this as well.

For detailed documentation, tutorials, and examples describing CGI, check http://hoohoo.ncsa.uiuc.edu/cgi.

Example: La Tool

La Tool is a CGI application, written as a C program. La Tool interactively communicates with an administrator via a Web-browser and appropriate server. La Tool receives information which the local server has extracted from an HTML form (submitted by the administrator). La Tool acts on this information by performing some administration function, and then packages the results as HTML documents which are passed to the server for return to the administrator, where they are formated for display by the browser.

La Tool is written in C instead of in an interpreted scripting language, such as perl. Those of you who know perl will probably be asking "Why?" (For an explanation, see perl sidebar.) Suffice to say, I am more comfortable with C than perl.

The source code is broken into four parts, shown in Listings 1 through 4. Listing 6 is the makefile used to create La Tool. Listing 5 is the include file that specifies the size of the log record array, and the GIF logo and background picture URLs. If you hate to type, a source code bundle including latool.gif and chalk.gif is available at:

http://www.cs.virginia.edu/~ccb8m/latool.tar.Z

Development should be kept separate from the production directory (Dadmintool). I advise creating a Dsrc/Dtool subdirectory and extracting/creating the source listings there.

To Process or Not, That Is the Question

Listing 1 contains the main() procedure. main() does some initialization and then gets the environment variable REQUEST_METHOD. REQUEST_METHOD is one of several standard environment variables that the server exports to child processes. If REQUEST_METHOD is set to POST, La Tool will extract the userid from stdin and call check() (Listing 4) to process and return the results. Otherwise, La Tool calls fillitForm() to send an HTML form for a sys admin to select the userid.

This is the standard method of determining whether a script needs to process information or send some sort of input form. Another important thing to note is line 23:

printf("Content-TYPE: text/html\n\n");

The server normally sends this line and a blank line based upon file extensions. That is, if a get method is issued for an index.html file, Content-TYPE is returned as shown above. When a CGI binary is called, the WWW server doesn't make any assumptions about the return content. Thus your CGI program has to explicitly tell the browser that it is sending text containing HTML commands (or a GIF file, etc.).

When the browser issues a post method, La Tool prints out HTML wrapper information and calls check(). check() does all the work of reading the wtmp file and printing out login statistics independent of the HTML interface. Thus, you can use La Tool as a skeleton for any admin code you are using now. Substitute your code for check(), change fillitForm() to suit your input needs, and modify the parsing of stdin. There you have instant HTML GUI, with one caveat. If your fillitForm() needs to send more than one item of information, you will need to break up stdin by watching for ?. Browser return data is of the form:

INPUT_VAR1=INFORMATION?INPUT_VAR2=INFORMATION? ...

The ? separates variable assignment pairs. La Tool only passes one item of information; thus, a typical stdin stream would be:

ut_name=root

User Interface fillitForm() and seluser()

Listing 2 (fillitForm()) contains the code that prints out an HTML input form (see Figure 2). This form was designed for Netscape, but looks the same under Mosaic v2.x. If the La Tool interface doesn't suit your browser, eliminate offending HTML elements.

Input elements are contained within the HTML FORM element. FORM defines the action to be taken for a group of HTML input elements, such as <SELECT>. Input elements have a NAME and usually a default value, unless they are freeform. The following is an example of a freeform text entry box:

<INPUT TYPE="text" NAME="ut_name" SIZE=12>

The user interface presented by La Tool tries to minimize input mistakes by querying the UNIX passwd file and presenting a selection of valid login IDs. The first version of La Tool had a text box in which you typed the login ID.

That version was very unfriendly, because you had to know the exact login ID before running La Tool, but has now been rectified by seluser() (Listing 3). seluser() uses the <SELECT> element to build a dropdown list of valid login IDs.

seluser() builds this list by parsing the /etc/passwd file. There is a drawback La Tool decides upon the input choices for a user. La Tool's idea of what is valid may not contain all possible valid inputs. If you are running NIS, you can't get all the user names from /etc/passwd. In this instance a freeform text box would be better. The local system might not have all user information but the login ID will always be recorded in wtmp.

Because this is a distributed GUI, information about which machine you are querying is presented. The logging file is also displayed, though it might be better to make this a user input. To make sure no one file has more lines than La Tool can handle (specified by NUMREC, see Listing 5), you might prune /var/adm/wtmp on a monthly basis. La Tool could present another <SELECT> list that lets a user pick a particular month/year file to peruse.

Presentation of Results -- check()

Listing 4 contains check(), which does the complex processing for La Tool. Unlike the other routines, which are mostly HTML printf() statements, check() prints out very little HTML. It takes two parameters, a userid and the log file, to process. check() reads in the log file and then starts at the first record. If the record contains a login name that matches the userid parameter, a second search begins. The search starts at the next record and terminates when a matching tty logout record is discovered. The search also terminates if a shutdown record is encountered. Online time is calculated from the start and end records, and this information is printed along with the two records. Online time is added to the accumulated time, which is printed when all the records have been scanned. The unit time is seconds, but hours and minutes are printed using a modulus/unit conversion factor. Any error messages or warnings are printed for display by the browser.

Compiling and Running

If you have all six listings present in Dsrc/Dtool, edit Listing 5, latool.h. Set ACTION_URL to the machine on which latool is installed. I used the IP address, but you can use a domain name like: viper.cs.virginia.edu.

If you have the archive latool.tar.Z, you will have latool.gif and chalk.gif. Put these into your default HTML system directory (or user directory). Now change BACK_URL and LOGO_URL so they point to the proper machine/path. For example, assume httpd is on a local machine called rodan, and the gifs are in the HTML default system directory. The define statements would be:

#define BACK_URL "http://rodan/chalk.gif"
#define LOGO_URL "http://rodan/latool.gif"

If you didn't get the source archive, you can create a background and logo gif using any paint program.

Now type make to create the latool binary. Move latool to the administration directory (Dadmintool). Launch your favorite WWW browser and try to access latool. If you copied the ScriptAlias as described in security setup, the URL for rodan would be:

http://rodan/admin/latool

Conclusion

La Tool is a simple CGI program that does a form of system administration. It demonstrates basic concepts, but doesn't go in depth about various input elements. The following books provide more information about CGI and elements such as radio buttons. n

Further Reading

Murdy, Robert J. Serving the Web. Coriolis Group.

Graham, Ian S. HTML SourceBook. John Wiley & Sons.

About the Author

Charles Bundy received B.S. and M.CS degrees from the University of Virginia. He is currently a programmer/analyst for the Virginia Department of Transportation and has implemented a statewide WWW server program using surplus equipment and Linux OS. He also founded an Internet technology transfer program.