Installation Manual for 2.1

This article has been retained as a historical document. It is not up-to-date and the formatting may be lacking. Use the information herein with caution.

This deprecated feature should no longer be used, but is still available for reasons of backwards compatibility.

This feature was deprecated in version 2.6. For up-to-date information view Github. 9

See also: History of WeBWorK version control

Satisfying system requirements

WeBWorK requires several software packages to run.

OS vendor package names are supplied. (Feel free to add the package names for additional vendors.)

Perl

WeBWorK requires Perl 5.6 or greater. To use courses with GDBM databases (such as those created by WeBWorK 1), Perl must be compiled with support for libgdbm. Most vendors compile their Perl packages with this support enabled.

Package names: Debian: perl

Apache

WeBWorK requires Apache 1.3. Efforts are underway to make it compatible with Apache 2. WeBWorK requires that the mod_alias module be available. Most vendors compile their Apache packages with the necessary features enabled.

Package names: Debian: apache

mod_perl

WeBWorK is a mod_perl application and requires mod_perl 1.x. If compiling mod_perl from source, use the EVERYTHING=1 flag to enable all mod_perl features. Most vendors compile their mod_perl packages with this setting enabled.

Package names: Debian: libapache-mod-perl

SQL server

While one can continue to use hash-style databases (usually GDBM) to store course data (as was done in WeBWorK 1), we recommend that you use an SQL server to store course data for new courses you create under WeBWorK 2. Using SQL will make your courses faster, especially under heavy loads. A single installation of WeBWorK 2 can support courses using both hash-style databases and SQL databases. Courses using SQL are not compatible with WeBWorK 1. However, course databases can be exported to an XML format if needed.

WeBWorK 2 is primarily tested with MySQL 3. It also works with MySQL 4. With small code changes, it can be made to work with other SQL databases for which there is a Perl DBD:: module. (For example, DBD::sqlite or DBD::Oracle.)

Package names: Debian: mysql-server, mysql-client

LaTeX

WeBWorK requires LaTeX for generating hardcopy output and displaying mathematics graphically. Any standard LaTeX distribution that provides the commands latex and pdflatex should work. We use TeTeX.

Package names: Debian: tetex-bin, tetex-extra

Netpbm

WeBWorK requires Netpbm to convert images among the GIF, PNG, and EPS formats.

Package names: Debian: netpbm

dvipng

WeBWorK uses dvipng to display mathematics graphically. It is only required if you wish to use the images display mode. WeBWorK is initially configured to work with dvipng 1.0 or greater, but can be reconfigured to work with dvipng 0.8 or 0.9. dvipng requires the preview.sty file from the preview-latex package.

Package names: Debian: dvipng, preview-latex-style

TtH

WeBWorK uses TtH to display mathematics as formatted HTML. It is only required if you wish to use the formatted-text display mode.

Package names: Debian: tth

Perl modules

The following Perl modules are required. All are available from CPAN, and many vendors provide packages of these modules. To see if a module is installed on your system, issue the following command, replacing Module with the name of the module: perl -MModule -e 'print "installed!\n"'

To install a module from CPAN, issue the following command as root, replacing Module with the name of the module: # perl -MCPAN -e "install Module"

module	condition	vendor package names
Apache::Request	required	Debian: libapache-request-perl
Data::UUID	required	Debian: not available
DateTime	required	Debian: libdatetime-perl
Date::Format	required	Debian: libtimedate-perl
Date::Parse	required	Debian: libtimedate-perl
GD	required	Debian: libgd-gd2-perl
Mail::Sender	required	Debian: libmail-sender-perl
SOAP::Lite	required(?)	Debian: not available
String::ShellQuote	required	Debian: libstring-shellquote-perl
Time::HiRes	required	Debian: libtime-hires-perl
XML::Parser	required	Debian: libxml-parser-perl
XML::Parser::EasyTree	required	Debian: not available
XML::Writer	required	Debian: libxml-writer-perl
DBI	required if using SQL databases	Debian: libdbi-perl
DBD::mysql	required if using MySQL databases	Debian: libdbd-mysql-perl

Module notes:

• If you run into problems installing Time::HiRes through CPAN, it may help to install it manually (make && make test && make install).

---

Installing a new WeBWorK system

WeBWorK can be installed from a tarball or from CVS. Tarballs are made for each release. They contain the necessary CVS data to update from CVS at a later date. Choose a tarball if you want to only run released versions or do not want to bother setting up CVS.

Installing from a tarball

Tarballs of WeBWorK releases are available from our SourceForge file release page. You will need to download both a webwork tarball and a pg tarball. Make sure that the versions of the tarballs match. You can choose either a GZip or BZip2 archive.

After downloading the tarballs, untar them somewhere (like your home directory): $ tar -xjf webwork-2.1.tar.bz2 $ tar -xjf pg-2.1.tar.bz2

Then, become root and move the directories to the your installation directory. I prefer /opt: # cp -r webwork-2.1 /opt/webwork2 # cp -r pg-2.1 /opt/pg

From now on, we will assume that WeBWorK 2 is installed in /opt/webwork2 and PG is installed in /opt/pg.

Installing from CVS

Installing from CVS allows you more flexibility in selecting versions of the WeBWorK code between or ahead of releases. You have several options, depending on which release tag you select when accessing the CVS repository.

  Released version: By specifying the rel-2-1 tag, you get the same version of the code that you would by downloading the WeBWorK 2.1 tarball. This is the most conservative option. Updating will have no effect -- this code will never change.
  Released version with patches: By specifying the rel-2-1-patches tag, you can stay up to date with the latest bug fixes against the released version of WeBWorK 2. Few, if any, new features are introduced on a patch branch.
  Latest development code: By checking out the latest code (via the HEAD tag), you get the latest development code. Since this code is a work in progress, it is sometimes unstable or broken.

No matter what tag you chose, you can change later.

Before you can install from CVS, follow the instructions in the WeBWorKCVSReadOnly topic to configure anonymous read-only access to our CVS repository. After installing the SSH helper script and configuring the wwcvs alias, use the following commands to check out a working copy of the webwork2 and pg modules:

Released version: wwcvs -d :ext:anoncvs@cvs.webwork.rochester.edu:/webwork/cvs/system checkout -r rel-2-1 webwork2 pg

Released version with patches: wwcvs -d :ext:anoncvs@cvs.webwork.rochester.edu:/webwork/cvs/system checkout -r rel-2-1-patches webwork2 pg

Latest development code: wwcvs -d :ext:anoncvs@cvs.webwork.rochester.edu:/webwork/cvs/system checkout -r HEAD webwork2 pg

After checkout finishes, become root and move the directories to the your installation directory. I prefer /opt: # cp -r webwork2 /opt/webwork2 # cp -r pg /opt/pg

Setting permissions

The PG installation directory and files should be owned by root and not writeable by other users: # cd /opt/pg # chown -R root:root . # chmod -R u+rwX,go+rX .

Most WeBWorK directories and files should also be owned by root and not writeable by other users: # cd /opt/webwork2 # chown -R root:root . # chmod -R u+rwX,go+rX .

Certain data directories need to be writable by the web server. These are DATA, courses, htdocs/tmp, logs, and tmp.

The simplest way to set this up assumes that all WeBWorK administrators have root access. In this case, directories that must be writeable by the web server should be given the group of the web server. In the following examples, it is assumed that the web server's group is www-data.

If you wish to perform administrative tasks such as removing temporary files, creating and editing courses from the command line, managing logs, and so on, you can either add the WeBWorK administrators to the web server's group, or create a new group called wwdata, containing both the WeBWorK administrators and the web server.

If you chose not to create the wwdata group, the WeBWorK data directories should have the group of the web server: # chgrp -R www-data DATA courses htdocs/tmp logs tmp # chmod -R g+w DATA courses htdocs logs tmp # find DATA/ courses/ htdocs/ logs/ tmp/ -type d -a ! -name CVS -exec chmod g+s {} \;

If you chose to create the wwdata group, the WeBWorK directories that must be writable by the web server should have that group: # chgrp -R wwdata DATA courses htdocs/tmp logs tmp # chmod -R g+w DATA courses htdocs logs tmp # find DATA/ courses/ htdocs/ logs/ tmp/ -type d -a ! -name CVS -exec chmod g+s {} \;

---

Upgrading an existing WeBWorK installation

If you already have a WeBWorK system installed on your server, you can upgrade it. This section will cover upgrading your installation to WeBWorK version 2.1.

You will need to install the new CPAN module DateTime.pm (see above). You may wish to install it first, before upgrading from the CVS, just to make sure that the install goes smoothly. I had some trouble installing DateTime on Red Hat 9 with perl 5.8.0, but found a <a href="http://www.mail-archive.com/datetime@perl.org/msg04548.html">workaround</a> to help me through it. --Mike

Upgrading using a tarball

Tarballs of WeBWorK releases are available from our SourceForge file release page. You will need to download both a webwork tarball and a pg tarball. Make sure that the versions of the tarballs match. You can choose either GZip or BZip2 archives.

After downloading the tarballs, untar them somewhere (like your home directory): $ tar -xjf webwork-2.1.tar.bz2 $ tar -xjf pg-2.1.tar.bz2

Then, copy the WeBWorK configuration files and courses directory from your current installation. If your courses are stored outside the webwork2 tree, there is no need to copy them. $ cd webwork-2.1 $ cp /opt/webwork2/conf/{global,database}.conf conf $ cp -r /opt/webwork2/courses .

Now you need to compare your configuration files with the new distribution versions. This can be done with the diff command. Make any updates necessary: $ cd conf $ diff database.conf database.conf.dist $ diff global.conf global.conf.dist

Then, become root and replace your current installation: # mv /opt/webwork2 /opt/webwork2.OLD # cp -r webwork-2.1 /opt/webwork2 # mv /opt/pg /opt/pg.OLD # cp -r pg-2.1 /opt/pg

Finally, reset file permissions, using the instructions for Setting permissions above.

Upgrading using CVS

With a few simple commands, you can update your existing WeBWorK system via CVS.

If you did not install from CVS, follow the instructions in the WeBWorKCVSReadOnly topic to download the CVS helper script and set up the wwcvs alias. To update your system to the latest released version, change to your webwork2 installation directory and use the wwcvs command: wwcvs update -d -r rel-2-1

Now you need to compare your configuration files with the new distribution versions. This can be done with the diff command. Make any updates necessary: $ cd conf $ diff database.conf database.conf.dist $ diff global.conf global.conf.dist

Making changes for the new release

Because of changes in WeBWorK's configuration between releases, it may be necessary for you to make changes to your configuration files or existing courses after upgrading. The instructions below cover the changes since the latest version in the 2.0.x series. If you have skipped releases, go back and read the release notes for the releases you have skipped. Follow any upgrade directions sequentially, before reading the section below.

Be sure that you have merged changes from the newest global.conf.dist and database.conf.dist files, as described above.

Take into account the following configuration changes while completing the upgrade process:

• A new database layout, sql_single, has been added to database.conf. It is now the recommended layout for new courses. Existing courses using the sql layout can be converted to use sql_single instead. To use the sql_single layout, a webwork database must br created. See below. See also: DatabaseLayoutManual, CourseAdministrationManual.
• Timezone support has been added. It is controlled by the $siteDefaults{timezone} variable in global.conf.
• There are additional permissions defined in the %permissionLevels hash.
• Two new PG classes, Parser and Value, have been added to the ${pg}{modules} list.

After the update is complete, restart your Apache server and test your installation to make sure everything works.

---

Tracking updates between releases

As we find bugs, we fix them and add them to the rel-2-1-patches branch of CVS. Periodically, we create patchlevel releases from that branch, such as rel-2-1-1, that encompas the changes made since the last release. Each patchlevel release is available as a tarball and from CVS. The -patches branch is only available from CVS.

To update your system to include the latest patches, change to your webwork2 installation directory and use the wwcvs command: cd /opt/webwork2 wwcvs update -d -r rel-2-1-patches

---

Configuring the shell

To make working with WeBWorK easier, there are several changes you can make to your shell environment.

Add the WeBWorK bin directory to your path. This will allow you to run WeBWorK command-line utilities without typing the full path to the utility. If you installed WeBWorK in the default location of /opt/webwork2, add the directory /opt/webwork2/bin to your path.

if your shell is	put this line	in this file
bash	export PATH=$PATH:/opt/webwork2/bin	~/.bashrc
tcsh	setenv PATH $PATH:/opt/webwork2/bin	~/.cshrc

Set the WEBWORK_ROOT environment variable. Some command-line scripts rely on this variable to find other WeBWorK files.

if your shell is	put this line	in this file
bash	export WEBWORK_ROOT=/opt/webwork2	~/.bashrc
tcsh	setenv WEBWORK_ROOT /opt/webwork2	~/.cshrc

---

Checking module dependancies

WeBWorK includes a script called check_modules.pl that verifies that the needed programs and Perl modules are installed on your system. Run this script to make sure you have installed the required programs and Perl modules.

---

Configuring WeBWorK

Making copies of the distribution configuration files

Before configuring the system, you must make local copies of the global.conf and database.conf configuration files, located in /opt/webwork2/conf/: $ cd /opt/webwok2/conf $ cp global.conf.dist global.conf $ cp database.conf.dist database.conf

Global configuration

Most WW configuration is done in the file /opt/webwork2/conf/global.conf. This file provides system-wide configuration settings, and defaults for course settings. Any setting in this file can be overridden in the course.conf file for a particular course.

There are several options that must be set for WW to work with your system. The rest of the file consists of customization options.

Seed variables

These are the main configuration variables of WeBWorK. The are used by the Apache configuration and by the system itself. Many other settings rely on these variables:

variable	description
$webwork_url	The URL associated with the WeBWorK handler. Usually /webwork2.
$pg_root	The path to the PG directory. Usually /opt/pg.
$webwork_htdocs_url	The URL of static WeBWorK hypertext files. Usually /webwork2_files.
$webwork_htdocs_dir	The path to the static WeBWorK hypertext files. Usually $webwork_dir/htdocs.
$webwork_courses_url	The URL of the courses directory. Usually /webwork2_course_files.
$webwork_courses_dir	The path to the courses directory. Usually $webwork_dir/courses.

Paths to external programs

To avoid executing malicious code, WW calls external programs using full path names.

variable	description
$externalPrograms{mkdir}	Path to mkdir binary. Usually /bin/mkdir.
$externalPrograms{mysql}	Path to mysql binary. Usually /usr/bin/mysql or /usr/local/bin/mysql.
$externalPrograms{latex}	Path to latex binary. Usually /usr/bin/latex or /usr/local/bin/latex.
$externalPrograms{pdflatex}	Path to pdflatex binary. Usually /usr/bin/pdflatex or /usr/local/bin/pdflatex.
$externalPrograms{dvipng}	Path to dvipng binary. Usually /usr/bin/dvipng or /usr/local/bin/dvipng.
$externalPrograms{tth}	Path to tth binary. Usually /usr/bin/tth or /usr/local/bin/tth.

Mail settings

WW sends mail in three instances. The PG system sends mail to report answers to questionnaires and free-response problems. The mail merge module is used to send mail to course participants, i.e. to report scores. The feedback module allows participants to send mail to course instructors.

To send mail, WW needs the address of an SMTP server. When connecting to the SMTP server, it must also send an email address representing the sender of the email.

variable	description
$mail{smtpServer}	The address of an SMTP server. If the local machine is running an SMTP server (as is likely), use localhost.
$mail{smtpSender}	The address to send when connecting to the SMTP server. This has nothing to do with the From address on the mail message.

Database configuration

The database configuration is controlled by the dbLayout hash. Several versions of this hash are defined in the configuration file database.conf, which is incorporated into global.conf using the include function.

For an important introduction to database layouts, please read the DatabaseLayoutManual.

Each database layout is defined in database.conf as an element of the %dbLayouts hash. The layouts currently defined are as follows:

layout	description
gdbm	The gdbm database layout maps all course data tables to GDBM database files in the course directory. It is suitable for courses created with WeBWorK 1 and courses which must be backwards compatible with WeBWorK 1. GDBM databases are less scalable than SQL databases, so this layout should not be used for courses that don't require backwards compatibility.
sql	The sql database layout maps all course data tables to tables in an SQL database. Courses using this layout cannot be used with WeBWorK 1. Each course that uses this layout will have a separate SQL database.
sql_single	The sql_single database is similar to the sql layout in that it maps all course data tables to tables in an SQL database. However, this layout allows multiple courses to share a single database, streamlining course creation and deletion and making database access more efficient.

To select a database layout, use the following syntax, replacing layoutName with the name of a layout from the table above: $dbLayoutName = "layoutName"; *dbLayout = $dbLayouts{$dbLayoutName};

Which database layout you chose for the global default (i.e. set in global.conf) depends on what database backend your courses will usually use. Courses with a different database layout will require a different layout to be selected in that course's course.conf file.

sql_single is the recommended database layout for courses created under WeBWorK 2.1. Existing sql courses can be converted to use this layout. See the CourseAdministrationManual for details.

If you have WW 1 courses that you'd like to use under WW 2, set the database layout to "gdbm". This way, the WW 2 will be able to read the WW 1 course databases even though those courses do not have a course.conf file. Even with this setup, new courses should still use "sql_single", unless you need them to be usable under WW 1.

Please note: support for GDBM databases are provided only for backwards compatability with courses used under WeBWorK 1 and will be dropped in a future version of WeBWorK 2 (as will all non-SQL database support).

Configration for the 'gdbm' database layout

There is no mandatory configuration for this layout, but there are two parameters that can be changed if necessary:

The globalUserID parameter given for the set and problem tables denotes the ID of the user that the GlobalTableEmulator will use to store data for the set and problem tables. This is set to "global_user" by default, but can be overridden on a course-by-course basis to the ID of the professor who is most likely to be involved in creating new problem sets. Sets which have not been assigned will only be visible to this user when logging into WeBWorK 1.x.

In database.conf, the globalUserID is set in the %gdbmGlobalTableParams hash: my %gdbmGlobalTableParams = ( globalUserID => "global_user", );

Use the following code to override this value in a course's course.conf file: $dbLayout{set}->{params}->{globalUserID} = $dbLayout{problem}->{params}->{globalUserID} = "some_user";

The psvnLength parameter denotes the number of digits in a problem set version number. This is set to =5= by default. If you have an extremely large number of students or problem sets in a course, you can increase this value.

In database.conf, the psvnLength is set in the %gdbmUserSpecificTableParams hash: my %gdbmUserSpecificTableParams = ( psvnLength => 5, );

Use the following code to override this value in a course's course.conf file: $dbLayout{set_user}->{params}->{psvnLength} = $dbLayout{problem_user}->{params}->{psvnLength} = 5;

Configration for the 'sql' database layout

The SQL database layout uses an SQL database server to store the tables of the WeBWorK database. The SQL driver uses two SQL accounts, a read only and a read-write account. The read-only account must have SELECT access, and the read-write account needs SELECT, INSERT, UPDATE, and DELETE access. When courses are created, the required permissions are assigned to the read-only and read-write SQL accounts.

The names and passwords of these accounts are given as parameters to each table in the layout.

param	description
usernameRO	the name of the read-only account
usernameRW	the name of the read-write account
passwordRO	the password for the read-only account
passwordRW	the password for the read-write account

Don't confuse the accounts above with the accounts of the users of a course. These are accounts on the database server itself, which allow WeBWorK to talk to the database server.

By default, the name of the read-only account is "webworkRead", and the name of the read-write account is "webworkWrite". There are no passwords by default. We recommend that you set passwords for these accounts in database.conf. However, we do not recommended that you use only passwords to secure database access. Most RDBMSs allow IP-based authorization as well. As the system administrator, it is your responsibility to secure database access.

You do not have to add these accounts to your SQL server in advance, nor create any databases. The course administration tools will do that whenever a course is created.

In database.conf, usernameRO, usernameRW, passwordRO, and passwordRW, and debug are set in the %sqlParams hash: my %sqlParams = ( usernameRO => "webworkRead", passwordRO => "", usernameRW => "webworkWrite", passwordRW => "", debug => 0, );

Other parameters that can be given are as follows:

param	description
tableOverride	an alternate name to use when referrring to the table (used when a table name is a resereved word)
fieldOverride	a hash mapping WeBWorK field names to alternate names to use when referring to those fields (used when one or more field names are reserved words)

These should be set for a specific table, not for all tables in the %sqlParams hash.

Configration for the 'sql_single' database layout

The sql_single database layout accepts all the same configuration parameters as the sql layout, above. It uses the same %sqlParams hash to set usernames and passwords. However, there is some additional configuration necessary.

In addition, the variable $sqlSingleDBISource is used to populate the source attribute for each table. It is a DBI source speicifications and controls the type of database that is used, the name of the database, and the how to connect. By default, the MySQL driver is used and the database is named webwork. For more information about DBI source speicifications, refer to: the Perl DBI documentation.

Since sql_single uses a single database for all courses using the layout, it does not create databases when courses are created. Instead, you must create a single database. Create the database using the your database server's command console. Then grant the users listed for usernameRO and usernameRW the following permissions for that database.

username	permissions
$sqlParams{usernameRO} (usually webworkRead)	SELECT
$sqlParams{usernameRW} (usually webworkWrite)	SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP

For example, under MySQL: $ mysql -u root -p mysql Password: '''***''' > CREATE DATABASE webwork; > GRANT SELECT ON webwork.* TO webworkRead@localhost IDENTIFIED BY 'passwordRO'; > GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP ON webwork.* TO webworkWrite@localhost IDENTIFIED BY 'passwordRW'; > exit Bye $

Replace passwordRO and passwordRW with the passwords you have set in the %sqlParams hash.

Constants.pm

Some configuration settings are stored in the file /opt/webwork2/lib/WeBWorK/Constants.pm.

ImageGenerator settings

The $WeBWorK::PG::ImageGenerator::DvipngArgs variable specifies the arguments to use when calling dvipng. dvipng version 1.0 and later require a different set of arguments than versions 0.9 and earlier:

version	arguments
< 1.0	-x4000.5 -bgTransparent -Q6 -mode toshiba -D180
>= 1.0	-bgTransparent -D120 -q -depth

Image conversion utilities

WeBWorK uses several support utilities -- gif2eps, gif2png, and png2eps -- for converting images. These scripts can be found in the directory /opt/webwork2/bin.

These scripts make use of several of the Netpbm tools, and therefore need to be told where to find them. Each script defines a variable called NETPBM, which is initially set to /usr/local/bin. If your netpbm tools were not installed to /usr/local/bin, change the value of this variable to reflect their actual location.

To determine where netpbm is installed, search for the program giftopnm, one of the programs that makes up the netpbm package. The directory that contains that file (for example /usr/bin or /usr/local/netpbm/bin) is the location you're looking for.

---

Configuring Apache

WeBWorK is nothing without mod_perl. To test your mod_perl installation, enable the following stanza in your Apache config file (usually httpd.conf or apache.conf): <Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from .yourschool.edu </Location>

Then restart Apache: apachectl graceful

Visit http://yourserver.yourschool.edu/server-info. You should see an entry in the list of active modules for mod_perl.

Once mod_perl is working, Apache must be configured to handle requests for WeBWorK. Apache provides access to WeBWorK through three URL locations:

• The location that is handled by the Apache::WeBWorK module, usually /webwork2.
• The location of system-wide resources, usually /webwork2_files.
• The location of course-specific resources, usually /webwork2_course_files.

WeBWorK ships with an Apache config file that you can include in your main Apache config file. The file is named webwork.apache-config.dist and located in the conf directory. First, copy the file to webwork.apache-config: $ cd /opt/webwok2/conf $ cp webwork.apache-config.dist webwork.apache-config

Then, edit the copy to set the $webwork_dir variable to the path of the directory containing the WeBWorK installation. This is usually /opt/webwork2. This value is used to read the WeBWorK configuration file and get the rest of the configuration data.

Further down in the file, you may want to customize the directives used to define the association between Apache and WeBWorK. Specifically, you may need to add the following to the <ocation> and <Directory> stanzas, to permit access: Order allow,deny Allow from all

After configuring webwork.apache-config, append the following line to your Apache configuration file: Include /opt/webwork2/conf/webwork.apache-config

If you are upgrading from a previous version of WeBWorK which did not use the webwork.apache-config file, you will need to remove the WeBWorK-related directives from your Apache configuration.

Then restart Apache and test your configuration:

• Test the /webwork2 location by visiting http://yourserver.yourschool.edu/webwork2. You should see the WeBWorK home page, with no courses listed.
• Test the /webwork2_files location by visiting http://yourserver.yourschool.edu/webwork2_files. You should see the "WeBWorK Placeholder Page".
• You cannot test the /webwork2_course_files location until you have created a course.

---

Creating courses

Please read the CourseAdministrationManual for information about creating courses.

---

-- Main.SamHathaway - 07 Jul 2004
-- Main.SamHathaway - 15 Jul 2004
-- Main.SamHathaway - 21 Jul 2004
-- Main.SamHathaway - 24 Aug 2004
-- Main.SamHathaway - 25 Aug 2004
-- Main.SamHathaway - 11 Sep 2004
-- Main.SamHathaway - 13 Sep 2004
-- Main.SamHathaway - 17 Sep 2004
-- Main.MichaelGage - 12 Feb 2005
-- Main.SamHathaway - 11 Jul 2005