Here are some hints from our web server administrators on how to make sure your CGI script works properly on our server environment.

But first… check out some of the CGI scripts that Internode provides for use on your website.

Page Counter

The Internode Page Counter is easily included on your web pages, and counts visitors to your website.

If you add a counter to your page, the counter begins with a zero count. Here’s the essential HTML required to place a counter in a page:

<img src="/cgi/nph-count?width=6&link=/username/pagename.html" alt="">

Other attributes can be added to improve the layout of a counter image. For example:

<img src="/cgi/nph-count?width=10&link=/username/pagename.html" alt="[Page hit counter]" height="20" width="90" />

Note: substitute /username/pagename.html above with your username and the name of the page you wish to count the hits (visits) of.

E-Mail Submission Form (UNIX Business Web Hosting Only)

The email submission form allows a user to fill in a form on your web page and have the results automatically mailed to you (i.e., a feedback form or even a product order form). For basic information on how to use this CGI script see http://www.yourdomain.com.au/cgi/mail (substitute yourdomain with your company's web address)

This feature is only available for UNIX hosted corporate webspace customers. This feature is not available for Windows webserver customers or "www.users.on.net".

Further general information

Users of Internode have the ability to run their own programs written in the programming language Perl, written as cgi scripts to be run in their web space. When a CGI script is executed, it is run as the user ID we allocate to you on our web server for your virtual hosting facilities.

The idea is that databases or other files you have can be made readable and writeable only by your user ID, and then only CGI scripts and the user FTP-ing in can access and modify the files.

Permissions can be set by the user with the FTP command site chmod permissions file, where permissions is a standard permissions number line 755. The first digit is permissions for the user, the second permissions for the group, and the last permissions for everyone else. Each digit is composed from numbers representing different permissions, 4 for read access, 2 for write access, and 1 for execute access. So 7 is full access, 0 is no access, 4 is read only, 6 is read and write but no execute access.

The CGI script itself can be made read/write/execute only by the user themselves if it contains sensitive information. This is permission 700.

The most common CGI mistakes:

• Not setting permissions to execute access. (See above).
• Incorrect file name. CGI scripts must either finish in .cgi or .pl, or be in a directory called cgi-bin at the top level of a virtual server.
• Not meeting the security requirements of the setuid-root program called to make CGI scripts run under the UID appropriate for the virtual server. This is almost always because the CGI script or the directory the CGI script is in is writeable by others.
• Incorrect Perl executable path. The first line should be #!/usr/bin/perl. Usually a problem with those coming from NT Systems.
• Uploading the file in binary mode. The file should be uploaded in ASCII mode to avoid end of line interpretation issues. Unix uses Line Feed, Macs use Carriage Return, DOS and VMS use Carriage Return followed by a Line Feed.
• Not printing a Content-Type header. CGI scripts must print a Content-Type header followed by a blank line. The Perl documentation for the standard CGI module has examples of doing this. The quick way out in Perl is print "Content-Type: text/html ";

Errors are logged to the virtual server's error log file. If using Perl's standard CGI module, the following lines include the standard CGI module, then include some intercept code to take any compilation errors and format them in HTML so the user can easily determine the problem.

use CGI;
use CGI::Carp qw(fatalsToBrowser);

Also of note is that /cgi/ on all virtual servers is mapped to /web/cgi/, so that clients can use our standard CGI scripts referenced as in their own virtual server..

As a general note, we provide this facility for experienced and competent Perl programmers. We are unable to provide free programming advice if you are unfamiliar with this language. Instead, we strongly suggest you engage the services of an experienced Perl programmer.

If you import non-trivial Perl packages into our server from somewhere else and you're not familiar with Perl, you should (again) be prepared to engage the services of a Perl consultant to help you.