What is CGI?

When you type an URL into your web browser, your computer contacts the HTTP server with the URL, and the HTTP server looks at the filename requested by your computer and sends that file back. Your computer then displays the file in the appropriate format. This is what happens when you view web pages. It is also possible to set up the HTTP server so that whenever a file in a certain directory is requested, that file is not sent back, but executed as a program, and whatever that program outputs is sent back for your computer to display. This function is called the Common Gateway Interface, or CGI. The programs themselves are called CGI scripts. Anyone can run their own CGI script by giving it a ".cgi" extension and making it executable.

Script and Program Permissions

For the webserver to execute your CGI program, you must also set the appropriate permissions on the .cgi program file you uploaded. To do this via WSFTP:

1. Use WSFTP to go into your website, into the same directory as the .cgi file you uploaded.
2. Right-click somewhere in the grey area between the Local and Remote windows. A menu should pop up. Select FTP Commands and then select SITE
3. Enter chmod 755 yourfile.cgi, where yourfile.cgi is the name of the .cgi program you uploaded
4. In the bottom windows of WSFTP, you should see the message "Changed"
5. NOTE: Always upload in ASCII mode when you are uploading CGI files.

Perl Scripts

Most CGI scripts are written in "perl", a scripting language ideal for CGI applications. If your script is written in perl, the script must have a ".cgi" extension and must be made executable, as described above, and the first line of the script must be #!/usr/bin/perl

Sendmail

Some CGI programs want to know where Sendmail is located. On our systems, this is /usr/lib/sendmail

cgiwrap

We will not set the SetUID bit on CGI programs, because there's a much safer way to have the same effect: cgiwrap. When a program is executed via cgiwrap, it is executed as if it had been run by you. Thus, it is allowed to read and write files that aren't normally accessible by the webserver. For example, if you'd like a CGI program to write some output to a file that only you can access, you can create a file that only you can read and write, then you'd have the CGI program run under cgiwrap so that only that specific CGI program has access to the file.

cgiwrap will look for CGI programs in your public_html/cgi-bin directory. If you do not have a cgi-bin directory in your public_html directory, create it and place the CGI program there.

Now access the CGI program using an URL like this:
http://www.humboldt1.com/cgi-bin/cgiwrap/USERNAME/PROGRAM.CGI
Where USERNAME is your login name and PROGRAM.CGI is the name of the CGI program.

When running under cgiwrap, the permission on a CGI program can be 700 or 500 instead of the usual 755 we usually describe. For extra security, it's usually a good idea to "chmod" your CGI program to 700 or 500 as described in the section on setting permissions. The output file that your CGI program creates should be chmod-ed to 0600, which allows you and only you to access the file.

PERL Version and CPAN Modules

We currently have version 5.00404 of perl installed, and version 2.56 of CGI.pm We will install any reasonable CPAN module on request. To request that we install a particular CPAN module, please email support@humboldt1.com

Help and Troubleshooting with CGI

http://www.leftfoot.com/freeshells.html

and

http://www.bylur.net/free/

PLEASE NOTE THAT WE ARE NOT AFFILIATED WITH THESE SERVERS NOR CAN WE ENDORSE OR RECOMMEND THEM. They were simply the first results of a search we did on google.com.

If your code is generating Server Errors, it's usually one of two things:

• The code has syntax errors. A syntax error means that there's a typo in the code that makes the program code invalid. Upload the CGI program to your shell account and then run the command perl -c program.cgi (program.cgi should be the name of your CGI program). If there are any syntax errors in the program, they will be listed and you can start fixing the code that way.
• The first thing printed by any CGI program must be a Content-Type header. Usually your CGI program will generate HTML, so make sure that one of the first things your program does is this:
  print "Content-type:text/html\n\n";

Access and Error Logs

If after debugging and uploading your scripts you are still having problems, you may want to check the error logs. Depending on whether you have a user page (one that looks like http://humboldt1.com/~support) or a Virtual Domain (one that looks like http://yourdomain.com), you will access the error logs differently.

If you have a virtual domain, please contact us and we can hook you up with a login name and a password that you can use to FTP into our virtual domain server and get your logs.

If you're trying to get the logs for a user page or a pseudo-domain, FTP to web3.humboldt1.com (NOT www.humboldt1.com!) and log in as weblogs with password weblogs These logfiles are cycled each Monday a few minutes after midnight.

If you only need to see the last few entries of the error and access logs, use one of these links to see it. If you're trying to track down a broken CGI program, be sure to "hit" the CGI program first so there will be an error in the log:

• Access Log - non-SSL Server
• Error Log - non-SSL Server
• Access Log - Secure/SSL Server
• Error Log - Secure/SSL Server

Client IP Addresses

We use a proxying software such that HTTP requests that are directed to www.humboldt1.com are answered transparently by our main webserver, web3.humboldt1.com The only effect this has on web pages is in the webserver's access logs. All hits to our website that come in as www.humboldt1.com show that the IP address of the user that connected is 206.13.45.1 To have your hits show the client's real IP address, follow these steps:

1. Rename the original index.html file to index2.html
2. Make a new index.html file that looks like this:
   <html>
   <META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://web3.humboldt1.com/~username/index2.html">
   <p>
   <a href="http://web3.humboldt1.com/~USERNAME/index2.html">Click Here for our Page</a>
   </p>
   </html>
3. Make sure that any reference in any of your web pages to your index.html or (/~username if you've referenced it that way) are now changed to index2.html (or /~username/index2.html)

Now when someone hits your site as www.humboldt1.com, they'll be transparently redirected to your site as web3.humboldt1.com and their real IP address will be recorded! The Click here link is useful for very old web browsers that don't support META refreshing.