Requests for files that end in .cgi or .php are forwarded to a dedicated CGI server for execution. All non-PHP CGI scripts must end in .cgi in order to clearly differentiate between files intended for execution and those intended for download.

Ensure the following criteria are met in order to prepare CGI scripts for execution on the contributed webserver:

1. The script must end in .cgi or .php.
2. Non-PHP scripts must have a she-bang invocation (e.g. #!/usr/bin/perl or #!/usr/bin/ruby) at the start of the file).
3. The script must have execute permissions.
4. The script must have AFS ACLs allowing it to be read by system:anyuser.

• perl (/usr/bin/perl)
• php (/usr/bin/php4 or /usr/bin/php5)
• python (/usr/bin/python)
• ruby (/usr/bin/ruby)

Check here for up-to-date information on the versions and modules installed. Due to security and resource concerns, extensions such as mod_perl, mod_php, jsp, servlets, etc. are not supported. You are welcome to attempt running compiled binary programs (e.g. C programs); however, we cannot guarantee that the architecture (presently 64-bit x86) of our CGI server will remain the same, or that the dependencies for your program will be installed on the machine. We are willing to install "off-the-shelf" perl modules from CPAN (ask gripe@club.cc.cmu.edu), but we likely won't do the same for arbitrary system libraries.

You have a real UNIX account on the CGI server, and your CGIs run under that UID. This helps to identify troublesome scripts and segregates each user's scripts from the others. It is used almost exclusively for the operation of suexec and is likely not the same as your Andrew UID, nor is it guaranteed to remain the same.

We do have resource limits in place to prevent CGIs from swamping the server. While somewhat conservative, these limits should be acceptable for nearly all CGI scripts you may want to run. If you encounter problems caused by these limits and have legitimate reasons to be exceeding them, please 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, nor can they read private files. If you desire this ability, see the documentation for that, but don't just give write access to system:anyuser on any directory. Spammers have actually been observed exploiting such directories and creating link farms.

We are not able to make server transfer logs available to users; however, CGI error logs useful for debugging CGI scripts are accessible via the My Contrib interface.

Known Issues with CGI Forwarding

Requests for CGI scripts are forwarded by the front-end webserver to a dedicated CGI server. We have implemented this to be as transparent as possible, but this may have several unintuitive and possibly inconvenient results. Those we are aware of are listed below:

• The environment variable REMOTE_ADDR is incorrect. It will always report the address of the 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 address of the actual client.

Most people who encounter problems running CGIs are met with a 500 Internal Server Error warning. If this happens to you, check for the following:

1. Have you followed all of the necessary preparation steps?
2. Does the first line (#!/usr/bin/foo) have a DOS linebreak at the end of the line? If so, the script will fail to execute. In practical terms, this means you need to ensure that your scripts are saved with UNIX-style linebreaks.
3. Try running the CGI manually from the command line on an Andrew linux machine. Assuming you aren't using features available only on our webserver, if the andrew linux machine can't run the script, neither can our webserver. This is a good way to check for syntax errors.