Useful Information for Second Year Traders Project

Department of Computing	Imperial College London
Useful Information for Second Year Traders Project (updated May 2008)

General information about the database server
Information about using CGI
Information on using Perl for CGI
Information on using Ruby for CGI
Information on using PHP
Information on using JSP or Java Servlets

General information about the database server

Our database server runs Postgres v7.3.4, and is located on a machine called db, running on port 5432.
You can login to db using the default lab login - username lab and password lab, and have readonly access to several databases, including the films database which several of the examples below use.
For read/write database access, enabling you to create tables, insert data etc, each DoC user has a Personal Postgres account and database on db -- you were sent an autogenerated email containing information about this when you joined DoC. If you've lost this, email help@doc and ask for your personal postgres password to be reset.
In addition, each group doing the Trader project is now automatically given a Group Postgres account and database. Once your group has been created, you should receive two emails from CSG - the first about /vol/project, and the second about how to use the Group database.

So, for the Traders project, we suggest that you use the Group Postgres account and database for the finished versions, and possibly do experimental development using your own Personal Postgres.

Information about using CGI

CGI scripts can be written in any language you like: We recommend the Perl language - Duncan White gives a short lecture course each December covering Perl, you can find the notes here: http://www.doc.ic.ac.uk/~dcw/perl2008/.

However, the webserver supports many other scripting languages: PHP5, Ruby and even Python.

When debugging CGI scripts, whatever language they're written in, check the log files: For CGI scripts in your home directory (i.e. URLs of the form http://www.doc.ic.ac.uk/~username/whatnot) or in your group project directory (i.e. URLs of the form http://www.doc.ic.ac.uk/project/2007/261/g072612NN/whatnot) you should check /vol/wwwhomeslogs/server-suexec.log and the end of /vol/wwwhomeslogs/wwwhomes.doc.ic.ac.uk/error.log (or ....uk/ssl_error.log if you're using https).

Note that group project CGI scripts are run by the webserver's suexec feature as a special per-group "user" called g07261NN_webuser.

Here are some typical errors:

Permissions are one of the easiest mistakes to make - obvious things like making your home directory, or public_html directory, or the CGI script itself, not readable by other (the web server!).
Alternatively, having permissions too lax can be a problem - especially as suexec is particularly paranoid. Making a CGI script in your public_html writable to the group or other, or having the group ownership of the CGI script different from your primary group, will cause suexec to log an error in the suexec_log file and fail. Getting familiar with umask and chmod will help you here.
Not having a valid Unix #! (shebang) line at the top of the script is also a good way of getting lots of lovely errors.
Editing a CGI script on Windows (and thus using Windows line endings, not Unix) can completely confuse the Perl/Ruby/PHP interpreter and cause the dread "Internal server error" message. Don't do this. But if you do, use dos2unix.
Finally, CGI scripts must output standard CGI headers and run to completion without blowing up. If they fail to produce standard headers properly flushed, the web server generates a generic 500 Internal Server Error: Premature end of script headers.
Simple things like syntax checking your CGI scripts (and modules) before running them (eg. perl -cw script) will save you a lot of pain. You can even run CGI scripts from the Unix command line, if necessary setting some environment variables to represent a web form data block.

Information on using Perl for CGI

Use:

#!/usr/bin/perl

...as your shebang line.

The webserver is currently running Ubuntu 7.04 Linux (same as the lab) and has Perl 5.8.8 (ditto) installed.

Including:

use CGI::Carp qw(fatalsToBrowser);

...at the head of your script converts most of the 500 Internal Server Error messages into something more useful. As stated above, you really should syntax check your perl scripts with perl -cw before running them as a CGI though.

If you still get a 500 after use CGI::Carp, then you are doing something which the webserver doesn't like. Check the suexec_log and error_log files mentioned above.

We commend to you the liberal use and understanding of the perldoc command for looking up Perl documentation. Just as a quick note, you can get information on the Postgres driver for DBI by typing:

perldoc DBD::Pg

...at a Linux prompt.

An example Perl CGI using DBI to connect to our database server and retrieve and display films is available at http://www.doc.ic.ac.uk/~dcw/filmeg.cgi

The source code of this example is here: http://www.doc.ic.ac.uk/~dcw/filmeg-cgi.txt and the source code of a tiny useful db module it uses is here: http://www.doc.ic.ac.uk/~dcw/filmdb.pm

Information on using Ruby for CGI

Use:

#!/usr/bin/ruby

...as your shebang line. The postgres and cgi classes are available for use, amongst many others.

We have recoded the above Perl CGI example in Ruby using the postgres class to connect to our database server - look at: http://www.doc.ic.ac.uk/~mwj/traderfaq/filmeg-rb.cgi

The source code of this example is here: http://www.doc.ic.ac.uk/~mwj/traderfaq/filmeg-rb.txt and the source code of a tiny useful db module it uses is here: http://www.doc.ic.ac.uk/~mwj/traderfaq/db-rb.txt

Information on using PHP

We are running PHP v5.2.1 on the web server.

Since PHP returns its errors to the displayed webpage, debugging PHP isn't an awkward proposition. Occasionally PHP warnings pop up at inappropriate moments. It's obviously preferable to rewrite your scripting to avoid or fix the conditions leading to those warnings, but if it really is impossible to do so, or the warning is clearly bogus, then prefixing the PHP call with @ should make it act quiet.

PHP is accessible for CGI scripts, but mod_php is not supported. Use:

#!/usr/bin/php

...as your shebang line.

The PHP online manual at http://www.php.net/ is useful, and contains all the necessary information relating to database connectivity.

We have recoded the above films example in PHP at: http://www.doc.ic.ac.uk/~dcw/filmeg.php.

The source code of this example is here: http://www.doc.ic.ac.uk/~dcw/filmeg-php.txt.

Information on using JSP or Java Servlets

We have recently built a personal Tomcat system enabling you to start tomcat on a lab machine with the configuration completely under your control. This is documented under several Q&A pages:

To bring all this information together, our Films example can be written as this JSP page. To run this with Personal Tomcat:

mktomcat6 ~/film-context
cd ~/film-context
cp /vol/www/csg/java/jdbc/Postgres.jsp webapps/ROOT/index.jsp
tomcat6 start
Point a web browser at: http://localhost:59999/index.jsp and the usual table of films will appear, generated by the Java Postgres JSP page.
tomcat6 stop.

Official information on Tomcat can be found at http://tomcat.apache.org/