In order to prepare a CGI script for execution on www.contrib, ensure the following:

• The script must end in .cgi
  • Giving in to the common convention, scripts ending in .php will automatically be run as PHP scripts
• The script (unless it is PHP) must have a she-bang invocation (e.g., #!/usr/bin/perl or #!/usr/bin/ruby) at the top
• The script (including PHP scripts!) must have execute permission (e.g., chmod +x [file].cgi or chmod 755 [file].cgi)
• The script must have AFS ACLs allowing it to be read by system:anyuser

Types of Scripts Supported
Among others, we have perl (/usr/bin/perl), php (/usr/bin/php4), python (/usr/bin/python), and ruby (/usr/bin/ruby) installed. Check here for up-to-date information on the versions of these languages installed. Due to security and resource concerns, such extensions as mod_perl, mod_php, jsp, servlets, etc. are not supported at present. You are also welcome to attempt running compiled, binary programs (i.e., C programs). However, we cannot guarantee that the architecture of our CGI server (presently i386) will remain the same, nor that all the libraries which your program may require are installed. We are amenable to installing "off-the-shelf" perl modules from CPAN (whine to gripe@club.cc.cmu.edu), but we likely won't do the same for arbitrary system libraries.

Technical Notes
You have a real UNIX account (in /etc/passwd) on the CGI server, and your CGIs run under that UID. This helps identify troublesome scripts and segregates one user's scripts from another's. This UID is used almost exclusively for the operation of suexec and is likely not the same as your andrew UID, nor is it even guaranteed to always remain the same.

We do have resource limits in place to prevent CGIs from swamping the entire server. While cautious, these limits should be more than sufficient for nearly all CGIs. If you encounter problems that are likely being caused by these limits and are doing something reasonably legitimate, contact us.

Unless you have enabled CGI AFS-write support and are using it correctly, CGI programs cannot create or write to files in AFS (i.e., your andrew home directory), nor can they read private files. If you desire this ability, see the documentation for that, but please, don't just give write access to system:anyuser on any directory. Spammers have actually been observed exploiting such directories and creating link farms.

Due to the sheer complexity doing so would entail, we are not able to make server transfer logs available. We may make the error log available somehow to simplify debugging of CGIs (the author appreciates the pain of not being able to see error logs all too well!), but for now, this is a manual procedure.

Known issues with CGI forwarding
As described, requests for CGI scripts are forwarded by a front-end webserver to a dedicated CGI server. We have implemented this to be as transparent as possible, but this may have several unintuitive (even, inconvenient) results. Those we are aware of are documented here. If you discover others, please let us know.

• The environment variable REMOTE_ADDR is incorrect.

  The environment variable REMOTE_ADDR (accessed in perl, for instance, as $ENV{'REMOTE_ADDR'}) will always contain the address of our front-end webserver that forwarded the request. If you want to use a script that cares about the address of the client, use the variable HTTP_X_FORWARDED_FOR instead. This will always contain the IP of the actual client.

  Note that for efficiency, our webservers do not perform reverse DNS lookups, so REMOTE_HOST will always be empty.

Debugging CGI problems
Most people who encounter problems running CGIs initially are greeted with a 500 Internal Server Error warning. If this happens to you, try the following checklist:

• Have you followed all the necessary preparation steps? Does the script end in .cgi or .php (if PHP), does it have the #! invocation at the top (unless PHP), is it executable, and is it readable?
• Does the first #! line have a DOS (e.g., a \r) linebreak at the end of the line? That will cause the script to fail to execute. In practical terms, this means that you either shouldn't edit your script in windows or should at least ensure it's saved with UNIX-style linebreaks. Many file transfer clients allow you to select a type (ASCII, binary, or auto) when uploading, and if given this option you should choose ASCII.
• Try running the CGI manually directly from the commandline from an andrew linux machine. Assuming you aren't using features available only on our webserver, if you can't run it on an andrew linux machine, our webserver certainly can't either. This is a good way, for instance, to check for syntax errors.

Back to contributed webserver documentation table of contents

Back to documentation table of contents