The Luddy cgi server allows the running of arbitrary programs (eg. perl, python, scheme, bash, etc). In order to use the cgi server you must have an account on any of the Luddy Unified Linux systems. By default, all Luddy faculty and graduate students will be automatically given an account on these systems. Furthermore, many undergraduate student and non-Luddy students taking Luddy classes will also be given accounts as needed for various projects and classes. You can check the status of your account per the KB article How do I get detailed information about my Linux accounts? If you are Luddy faculty, staff, or student and don't have an account, you can submit a service request.

The Luddy server cgi.luddy.indiana.edu is used for cgi program support. This server runs an apache server with suEXEC Support. What this means is that your cgi programs will run under your account and not as the normal apache user. As a result, your scripts will have the full permissions (and limitations) of your account.

This server also supports the running of PHP scripts so see the PHP page for more information.

In order to set up your account for cgi use, you have 2 options:

• Using make-cgi - Anyone with an account on the Luddy systems can log in (via ssh) and run the make-cgi script. In most cases, you will need to answer 'yes' to all the questions this script asks in order for everything to work properly. This script will set up a directory /u/username/cgi-pub and you will need to place your cgi (or php) programs in that directory. Once that is done, you can access them via the web using a URL like the following:
  • https://cgi.luddy.indiana.edu/~username/somescript.cgi
• Luddy Graduate Students, Faculty, and Staff - If you are a current Luddy graduate student, faculty, or staff member you can create CGI hosting and have it be your default homepage listing by visiting the Homepage Mangement System. Just select the option to Create a homepage, and then select CGI/PHP Hosting. This web page will set up a directory /u/username/cgi-pub and you will need to place your cgi (or php) programs in that directory. Once that is done, you can access them via the web using a URL like the following:
  • https://homes.luddy.indiana.edu/username/somescript.cgi

There are several ways you can limit access to content hosted on cgi.luddy.indiana.edu. This section describes two examples limiting access to the IU network and via authenticated user.

A common technique is to use a .htaccess file to limit access to a particular domain. For example, you could create the following .htaccess file in a directory to limit access to hosts in the indiana.edu and iu.edu domains:

.htaccess

However, there is a problem with this. Unfortunately, much of the IU DHCP network space does not have IP addresses registered in DNS. As a result, many systems you will want to give access to will not have IPs that resolve to indiana.edu or iu.edu hosts so the above mechanism will fail. Here is an example that will instead limit access by IP address, limiting to the IPs within the IU network (including the IU VPN):

.htaccess

You can also combine the "Require ip" and "Require host" lines in the same .htaccess file to build the host access list you want.

Limit Access by Authenticated User

We have the mod_auth_cas module installed on the server which means you can easily limit access to your pages to only authenticated IU users or to specific IU users. For example, here is a .htaccess file that limits access to any authenticated IU user:

.htaccess

You can also limit access to a list of users with something like:

You can list as many require user lines as needed to list all the users needing access.

If you need access to the IU username of the authenticated user in your code, you can access that via the $_SERVER["REMOTE_USER"] environment variable. For example, here is an example php code snippet that prints the username of the authenticated user:

PHP Example

You are authenticated as CAS user <?php print($_SERVER["REMOTE_USER"]); ?>

There are a number of things that can go wrong when setting up your cgi scripts. Here are some common pitfalls you are likely to run into:

• Use the CGI/PHP Verification Tool - We have an On-Line Verification Tool that you can use to check your URL. It will report many common errors and give you tips on how to fix them. It is not capable of detecting all possible problems, but is definitely the first place to start.
• Program Coding Errors - You must make sure that your program doesn't contain errors. You should at least verify that the program runs without obvious errors when run from the command prompt. In order to test your script in the same environment as it is run via the web, you will need to ssh into the cgi server, cgi.luddy.indiana.edu and run it there. If you run it on some other system (like silo or tank) you may get different versions of things like python and perl.
• Improper Headers- Your cgi program must output the proper headers for the content you are generating and these headers must be the first thing your program prints. For example, if you are generating simple HTML content, the first thing your program outputs may look like the following:

Note that the Content-type: line must be followed by a blank line.

• Script Not Executable - Your cgi programs must be executables (ie. have the xpermission bit set). You can make sure this is set with something like:

• Script Writeable by Others- Your cgi programs must not be writeable by anyone else. Allowing group or world write permissions would meant that other people could edit your scripts and run anything they was as you which would open up all kinds of security issues. You can assume that your script is not writeable by other with:

Permissions Problems - The permissions on your cgi scripts only need to be set so they are executable by you since they will be run as your username. However, the full path leading up to the script must be searchable by the apache server. The easiest way to do this is to make sure the /u/username/cgi-pub directory (and any sub-directories you create there) are world searchable. This can be done in a number of different ways but one simple way is as follows:

Owner/Group Problems - Your cgi scripts must be owned by you and the group must be your default group.

suEXEC Violations - The apache suEXEC Security Modelplaces constraints on your programs so you should confirm that you are meeting all the specified constraints. You can look for suEXEC errors in the suexec.log file on the cgi server as follows:

In this example, the grep for your username (and you need to replace username with your actual username) is done so you only see your errors and not the errors from every user of the system.

Incorrect Script Naming- By default, scripts must end with .cgi filename extension. If you want to have a cgi file without the .cgi extension, you can do this by creating a .htaccess file in the directory containing the script that contains something like this:

In this example, you would replace somefile with the name of your cgi script.

Missing #! Script Header- If you are writing scripts (such as perl, python, bash, etc) you have to use the #! line to specify the program used to run the script. This must be the very first line of the script and you must make sure that there are no spaces before the line. For example, if you are writing a bash script, this line would be:

DOS format #! line - Unfortunately, there are text file differences between Windows and Linux that can cause problems if you are creating your scripts in Windows (eg. using Notepad) and copying them to the CGI server. If your script is failing, try to just run it from the command line and see if you get an error like this:

If you see that error (with nothing before the colon), then that almost always means that the .cgi file is a DOS mode text file. You can easily fix the problem using the dos2unix utility like this:

If All Else Fails - In many cases, if you are getting server errors you can determine the cause of the problem by looking at the apache error logs. In order to view the error log output you will first need to ssh to the cgi server, cgi.luddy.indiana.edu. Once you are logged in there you may find it helpful to tail the error log while you access your page looking for errors. For example:

In this example, the grep for your username (and you need to replace usernamewith your actual username) is done so you only see your errors and not the errors from every user of the system.

Please note that not all errors you may want to see will have your username in them. In order to see all possible errors, you can remove the grep of your username. Just keep in mind that this then means you will see all the errors from all users so it may be verbose.

Not all possible errors will show up in this log file but you should see errors related to a majority of the mistakes you are likely to make. Also see the section above about suEXEC errors and the associated suexec.log file where suEXEC errors will appear.