The University of Arizona

Resources

Using the CGI server

The CGI server lets you publish pages on the Web with dynamic content. Here's a simple example.

CGI stands for for Common Gateway Interface, a protocol for web servers to run programs (or "scripts"). Scripts can be written in any language as long as the script follows the CGI protocol, though interpreted languages like Perl, Tcl, and Python are popular choices.

The server software is Apache 2.0.54. The server equipment itself is an Intel Pentium 4, with a 2.8 Ghz processor and 1 GB of physical memory, running Fedora Core 4 Linux.

Languages and libraries

The CGI server supports several interpreted languages and libraries for these languages:

The server will support Java "servlets" too someday.

Note that a CGI application can be written in a compiled language such as C, using a command of the form 'cc -o foo.cgi foo.c'. Note however that the CGI server is a 32 bit Linux machine. If you compile such an executable on a machine such as lectura, which is a 64 bit Linux machine, cc will by default create a 64 bit executable. This will not run on the CGI server. To create a 32 bit executable using cc on lectura, you can use the '-m32' option to cc, as in 'cc -m32 -o foo.cgi foo.c'. Alternately, you can run cc on a 32 bit Linux machine to create a 32 bit executable.

The pathnames to the various interpreters is the same as on lectura, or other department Linux machines. For instance the Bourne shell is at /bin/sh and the Perl interpreter is at /usr/bin/perl (or /usr/local/bin/perl).

Installing CGI scripts on the server

Your status as a CS major automatically provides a CGI area:

URL = http://cgi.cs.arizona.edu/people/<username>
directory = /cs/cgi/people/<username>

As the directory is located in http://cgi.cs.arizona.edu/people/ you should be able to access it from most departmental Unix hosts by typing:

cd /cs/cgi/people/<username>

If you use a Windows system, connect through the Samba server:

Windows = My Network Place / Entire Newtork / Microsoft Windows Network / Csc / Samba Server (Samba) / cgi_people / <username>

The pathname to your scripts area should be

/cs/cgi/your_username/public_html

This is similar to how the department's HTTP server is set up. Just as you would edit

/cs/www/people/your_username/foo.html

to publish

http://www.cs.arizona.edu/~your_username/foo.html,

you would edit

/cs/cgi/people/your_username/public_html/foo.cgi

to publish

http://cgi.cs.arizona.edu/~your_username/foo.cgi.

Note that scripts have to go in your public_html directory (or a subdirectory of your public_html directory), and the script's filename has to end with .cgi. You can use /cs/cgi/people/your_username itself to hold files the scripts read or write. The CGI server does not mount other exported filesystems, so filespace on sinagua, salado, or any other NFS server is not available.

Running and debugging CGI scripts

Your CGI scripts run under your own UID and your primary GID, so you can read and write to files you own in /cs/cgi/people/your_username. Note that your scripts have to be owned by you, and the group ownership on them has to be your primary group. Your primary group is the first group in the list returned for you by the 'groups' command on the department Linux machines. Note that the script cannot be group writable, and the directory it is in cannot be group writable. If the directory is a subdirectory of your public_html directory, it will check that the parent directory is also not group writable. The script runs as you. The logic here is that the cgi server will run your script as you, using suexec, only if it can determine that you are the only one that can write to it, and to the directory that it is in.

Whenever the server runs a CGI script it writes records to /cs/cgi/logs/access_log. You can check this file to see what was run, when it was run, the IP address of the client machine that ran it, and whether the script ran successfully or not.

The server software usually returns a cryptic error message if there is something wrong with your script. The server's error log, /cs/cgi/logs/error_log or the servers's suexec log, /cs/cgi/logs/suexec.log may shed more light.

Security

A poorly-written script can compromise the security of your files on the CGI server and could even compromise security on other machines in the department. Lincoln Stein has an excellent discussion of the potential security problems with CGI scripts and how you can reduce those problems.

If nothing else, you must be careful not to trust any input data a user provides to your script. The CGI Programming MetaFAQ has a number of FAQs and pointers to articles on security. For Perl scripts see Lincoln Stein's notes on safe scripting in Perl.


Last updated Monday, 07-Jan-2008 09:32:28 MST, by Phil Kaslo
Send questions about this page to