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 Linux.

Languages and libraries

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

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 are 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).

Your CGI directory 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>

You should be able to access your cgi directory 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 Places / Entire Network / Microsoft Windows Network / Csc / Samba Server (Samba) / cgi_people / <username>

Installing CGI scripts

On Linux systems, the pathname of your scripts area is:

/cs/cgi/people/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/public_html/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.

CGI scripts must go in your public_html directory (or a subdirectory of your public_html directory), and their filenames must end with .cgi. You can use /cs/cgi/people/your_username itself to hold additional files the scripts need to read or write. The CGI server does not mount other exported filesystems, so filespace on zuni or any other NFS server is not available.

Running CGI scripts

The CS cgi server uses suexec to make your CGI scripts run "as you", i.e. under your own UID and your primary GID. Therefore your scripts are able to read and write files you own in /cs/cgi/people/your_username.

File permissions

Note that your scripts must 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.

In addition, your script directories must be world-executable (o+x on linux) in order to enable the web-server to find the directory entry for your script. However your scripts do not need to be world readable or executable.

Note also that suexec requires that scripts are not group writable. Your public_html directory and all directories under it which contain scripts must also not be group-writeable.

This is done for security purposes, the logic of this is that the cgi server will not run your script as you, if it cannot ensure that you are the only one who can write to it, and to its directory.

Debugging CGI scripts

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 server'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 Wednesday, 25-Mar-2009 08:19:14 MST, by Shanna Leonard
Send questions about this page to