Notes on Instructional Use of Cubist

Obsoleted by this page. is a host running the Apache httpd web server. It is available for instructional use for UW CSE majors courses. This document gives some background on how the machine is configured that is intended to be useful to instruction teams for courses that use it for student CGI and/or database development, and to a lesser degree to the students themselves.

Installed Software

Operating System
Linux 2.6, based upon Fedora 13.
Web Server
Apache 2.2, with many of the vanilla modules, augmented with mod_ssl (for HTTPS service) and mod_php (version 5.3). For authentication, both mod_csecookie (for CSENetID) and mod_pubcookie (for UWNetID). See HTTP server info. Also, suexec support.
Application Software
The most commonly-used language for CGI coding on Cubist is perl (we run 5.10.0); a variety of of third-party modules are installed, such as DBI, DBD::Pg, and DBD::mysql. Also available are python, ruby, and PHP (5.2).
Database Servers
Cubist is currently running PostgreSQL 8.4. Details of using that are collected in PostgreSQL for Instructional Use on Cubist. We support PHP bindings to PostgreSQL.
We also run MySQL 5.1. Details of using that are collected in About the MySQL Service on Cubist. We support PHP bindings to MySQL.
For connectivity to Microsoft SQL Server, we offer FreeTDS, a set of libraries that know how to "talk" the TDS protocol shared by Microsoft SQL Server and various Sybase offerings. There are PHP bindings to Sybase. See Talking to Microsoft SQL Server from Unix
Version Control
Cubist offers HTTPS access to Apache Subversion source code repositories. Please see Apache Subversion for Instructional Use on Cubist for details.

Configuration Information

Apache httpd

The documentroot is set to /www/htdocs/.

The userdir is set to www. That means that users' web content is sought in ~/www/.

We use the suexec mechanism for user CGI execution, which means that scripts execute under the user ID of the owner of the file. CGI scripts are sought in the users' web directories. Currently, executable files with filename extensions of .cgi, .cl, .lsp, .lisp, and .pl are treated as CGI scripts.

File System

User home directories are in /www/homes/. The Apache userdir directive has the value www, and the value of DirectoryIndex is index.html index.htm index.shtml index.php, all of which adds up to that fact that users' web content is sought in the directory /www/homes/<user>/www/, corresponding to a URL of<user>/ for any file in that directory named index.html, index.htm, index.shtml (parsed for server-side-includes), or index.php (parsed for PHP commands).

Very few standard file systems are exported to Cubist. Notably missing are any of the file systems from the /homes/ hierarchy. This poverty of imports is by design: we worry that flaws in suexec CGI scripts written by CGI novices could be leveraged into attacks against exported files owned by the CGI authors. That's why we create home directories in the local /www/homes/ tree.

cubist:/www/homes/ is itself exported to all the IWS machines where students have their Unix instructional accounts. See /homes/cubist/.

The directory /www/htdocs/projects/ is exported as /projects/instr/cubist/. Per-quarter subdirectories are created there as needed (e.g. 09sp/) and per-course subdirectories of the per-quarter directories are created as needed and are owned by and writable by the associated course group (e.g. /projects/instr/cubist/09sp/cse403/ will be writable by the cse403 group.

Log Files

Log files on Cubist are located in the same place and managed much the same way as on other CSE web servers; therefore, the document About Log Files is useful.

The error log is a handy tool for debugging CGI scripts. Often, the information printed to the error log when a script generates a server error is all you need to determine where things went awry. Note that anything a CGI script prints to its standard error is captured in the error log, regardless the script continue to successful execution. Perl coders, for example, might use code like this to help with debugging:

  print STDERR "$0: got this far\n";

There is a Error Log Filter CGI script that helps users find the errors that apply to their own resources. It does this by requiring authentication, then using the value of the REMOTE_USER environment variable (which is set to the authenticated username) to filter the error log to only those lines reporting errors for URLs starting with /~<user>/. This script is linked from the error document that users see when they get a server error.


webmaint at
Last modified 10/26/13 at 01:10PM PDT.