The SICE cgi server allows the running of arbitrary programs (eg. perl, python, scheme, bash, etc). In order to use the SICE cgi server you must have an account on any of the SICE Unified Linux systems. By default, all SICE faculty and graduate students will be automatically given an account on these systems. Furthermore, many undergraduate student and non-SICE students taking SICE 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 SICE faculty, staff, or student and don't have an account, you can submit a service request.
The SICE server cgi.soic.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 SICE 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:
SICEGraduate Students, Faculty, and Staff - If you are a current SICE 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:
These troubleshooting tips apply only to CGI scripts and not PHP. See the PHP page for more information about running PHP scripts.
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.soic.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.soic.indiana.edu. Once you are logged in there you may find it helpful to tailthe 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.
Here are a couple sample scripts that you may want to use to verify that things are working properly. You should be able to just copy these into your cgi-pub directory with a name like test.cgi, make it executable, and have them work.
Sample bash cgi Script
Sample perl cgi Script