School of GeoSciences

School of GeoSciences

Web Scripts

Scripts can be run on the web server. This is a powerful mechanism, but it requires care to keep the web servers secure. Only use scripts if there is no better way to achieve your aims, the effort involved may not be justified in many cases. The server arranges for the script to be run as the user who owns the script. This is intended to improve the security of the web server. Additional measures are also taken to protect the web server and the script owner from malicious attack, and from the script author's inevitable mistakes.


Scripts must be placed in: /web/UUN/public_html/cgi-bin (or a subdirectory). Files placed there will not be displayed, but executed - the output is displayed. Scripts will only be executed if the user and group attributes match the UUN for the directory. The script must be executable by the user. In addition both the script and its containing directory must not be writeable by anyone other than the user.
Scripts are not permitted to write to most of the /web/UUN/public_html directory. The one exception is /web/UUN/public_html/dynamic which is writeable. This is a security measure - a hijacked script cannot write another script to get deeper in to the system. For the same reason, PHP scripts are disabled within the dynamic directory.
Scripts can read and write /web/UUN/data which allows data to be stored between runs of scripts, and to share information between them. This directory is not visible on the web, but clearly scripts can expose any or all of its contents as required.
The web server generates access and error logs. These logs are automatically split - if they contain /~UUN, /web/UUN or /home/UUN, they will be sent to the log for UUN. In the case of access logs this is very reliable. Error logs come in a variety of formats, so output can not always be identified. Output sent to stderr is sent to the error logs. (The environment variable SCRIPT_NAME contains an identifiable file name - including its value in error messages is a good idea). You can write directly to the log file directory from your scripts - this should be a last resort.
Files in the log directory with names ending .log will be "rotated". Periodically the files will be renamed by adding .1 to the end. Any previous .1 file will be moved to .2 and so on. The oldest files will be removed.

Writing Scripts

Scripts can be hard to manage on a web server. Here are some suggestions that may help while you are developing them:

  • Keep your scripts short and well commented.
  • Check the logs - there may be a clue there.
  • Try more verbose logging: insert commands to print to STDERR (ending in a newline). Output containing /web/UUN will end up in the log for UUN.
  • Binary chop: to find a problem, try removing half your code, then half again until the problem disappears. This should tell you where the issues are.
  • Your script cannot access your home directory (for technical reasons, the web server sometimes refers to /home/UUN, but this actually points at your /web/UUN).
  • Include error checking and catch and deal with any exceptions in your program.
Perl scripts

A perl script run on a web server should probably start like this:

use strict;
use warnings;
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);

This should ensure that many simple errors are displayed on your browser, rather than disappearing in to the logs (possibly out of your sight).

  • Always use strict and warnings.
  • If you use || die ... always include $ENV{'SCRIPT_NAME'}.
  • Put parts of your code in evals, and report error messages.
  • Catch eval errors.
  • Use alarms to catch code that might take too long to run. See perldoc -f alarm

See man CGI for a basic introduction to using the CGI module.


PHP can be used in .php files, but these are not handled by the same mechanism. They should not normally be placed in the cgi-bin sub-directory.

PHP scripts can be run from within cgi-bin, but only if they initiate PHP directly. To do so they need to begin: #!/usr/bin/php Such files behave differently from the more common embedded scripts.

A useful diagnostic function for PHP is <?php phpinfo(); >


Oracle connections no longer require the TNS_ADMIN environment variable to be set.

Most Oracle scripts require a username and password to access the database. This information should be kept in a separate file which is referred to by the main ones. This separate file can then be kept in a safer directory (such as /web/UUN) so that it is not accidentally published. E.g. in perl a separate script could be called thus:

   my $dbh = do '/web/UUN/';

Script Problems

Some common errors:
bad interpreter:
CGI scripts must be written in UNIX mode, scripts with Windows-style line endings will usually not work.
Error 500
If trying to run your script gives you an error 500, the script has not probably produced a suitable header. If your script works and produces a header at a command line, the next most likely cause is that the script or its directory are writeable by the group or "other". You can change these with: chmod go-w .....
Permission denied
Your script probably is not set as executable. Fix this with chmod u+x .....

Reporting CGI errors

If you have problems with your CGI script, The IT Team may be able to help. Please try to solve the problem yourself first, we do not provide a script debugging service.

  • Check the common problems mentioned above.
  • If the script is part of course work, please contact your tutor.
  • Tell us the exact location of your script.
  • Explain any changes you have made recently, especially if that broke it!
  • If the program runs, tell us what you think is wrong with the output it produces.

It may be appropriate to contact the IT Team first in the following cases:

  • Database connection time-outs.
  • Security issues.
  • General and complete system failures.
  • Running out of space.