You are here

Informatics homepages web service

Printer-friendly versionPrinter-friendly version

Most Informatics users can publish personal web pages and most are also allowed CGI script access - 1st and 2nd year undergraduates being the notable exception. Users are responsible for anything that they publish, and they are bound by the Computing Regulations.

If you have permission for either (or both) of these, then you will find the corresponding directories:




... visible in the DICE filesystem, where <user> is your DICE username. For the rest of this document we will take user 'fred' as an example of <user>.

The disk space in /public/homepages/ is subject to a disk quota - currently 5MB for taught students, 20MB for research students and 50MB for staff. Requests for more space should be sent to computing support.

The basics

The web server is Apache 2.2. It has been slightly tweaked, mainly for the user CGI feature.

In early August 2017, homepages is due to be updated to SL7 and Apache 2.4. See homepages-upgrade

The file /public/homepages/fred/web/index.html will be visible on the web as the URL http: //

Similarly the CGI program /public/homepages/fred/cgi/myscript will be accessible as http: //

Anything in /public should be considered public. Page access can be restricted (using .htaccess files and file permissions) but misconfiguration or a faulty CGI script can render these restrictions meaningless. You also have to consider that for the apache server to be able to serve your pages to the outside world, it must be able to read them, so they need to be world readable within the filesystem.

Currently the apache server supports Server Side Includes (mod_include) and PHP (mod_php5). Files ending in .shtml and .html are parsed with mod_include, and files ending in .phtml and .php are parsed with mod_php.

The people pages under are automatically generated from data held in the school database. If you wish to have a 'Personal Page' link to your homepages appear beside your telephone and room number details on your contact page then please use the Webmark self service form.

More detail

One important thing to note is that - for security reasons - it is recommended that you do not try have have the homepages web server access files outside of your /public area. Indeed, the /home path has been deliberately disabled for this reason.

Also, the utility wget, which is often exploited to download cracks and further exploits to the machine, has been renamed Wget (with a capital "W"). This should lessen the chance of it being abused, but still allows you to use it as you know the name to call it with. This may change again if we discover it being exploited via its new name.


  • The homepages web server runs with mostly the same set of software packages that you'd find on a standard DICE desktop, although an exact match of software and versions is not guaranteed.
  • Your CGI scripts will run as your userid. In theory they have read/write/delete access to any of the files that you own. If you write and install a script that can be exploited, then potentially a malicious user could delete all your files. However it does not obtain your AFS credentials, so by default any AFS space should be safe.
  • As your networked home directory (e.g. /home/fred/) is not available to the web server, you cannot write scripts that take some form of input and write data back to your /home/ home directory, only your /public/homepages/fred/{web,cgi,data}/ directories.
  • CGIs need to be executable, and be owned by your user ID, or the server will not run them.
  • CGIs will not be executed if they are somehow modifiable by other people, e.g. they are within a group/world-writable directory, or the CGI itself is world/group-writable.
  • You do not have access to the apache logs. If you have problems with your CGI and it produces errors, you cannot access the apache logs to see any output it may have produced. The usual trick to debug CGI problems is to run the CGI from the command line (cd to your CGI area and do ./scriptname) and make sure it produces the correct header and output on the standard output. For example:
      Content-type: text/html

    Note the blank line between the Content-type line and the first HTML tag.

  • If your CGI is written in perl, then the following may be useful to aid debugging:
      use CGI::Carp qw(fatalsToBrowser set_message);
      BEGIN {
           sub handle_errors {
               my $msg = shift;
               print '<h1>An error occurred</h1>';
               print '<p>The following error occurred in your CGI:';
               print '<pre>'.$msg.'</pre>';
           set_message( \&handle_errors );


  • PHP is running in "safe mode". This does sanity checking on ownership of files, and will only allow you to access files you own and that exist in the /public/homepages/ branch of the filesystem.
  • As for CGIs above, your home directory (e.g. /home/fred/) is not available for input or output to PHP scripts.
  • If you want .html files to be parsed by PHP, then you need to add the following line to a .htaccess file (you may need to create this file) in your homepages area:
      AddHandler php5-script .html 
  • Alternatively you can run your PHP as a CGI. This way there is no "safe mode" and your PHP will run as you, the same way other CGIs do, so accessing files is a bit more predictable. To turn your .php (or .html) file into something suitable for running as a CGI then add the following to the beginning of the file:
      echo "Content-Type: text/html\n\n";
    <!-- rest of the original file here -->

    and move it into your homepages/<username>/cgi/ area, remembering to make it executable.

  • The following lines at the beginning of your PHP may help you debug problems:
        ini_set("error_reporting", E_ALL);
        ini_set("display_errors", TRUE);


  • Your personal web pages have the apache directive:
     Options IncludesNOEXEC

    So you will not be able to execute scripts or commands from SSI.

Accessing pgteach.inf

  • The pgteach.inf (and pgresearch.inf) database prefers SSL kerberised connections. If you try to use this in your CGI, it will be unable to connect to your DB. You need to fallback to using plain username and password authentication over a non-SSL connection. See the above link on how to obtain a plain password, and then use something like the following to force a non-SSL connection, for example in PHP:
        $dbconn = pg_connect ("host=$server dbname=$db user=$username password=$password sslmode=disable")

    Other languages should have a similar way of forcing a non-SSL connection.


Try the general web FAQ. Any technical problems with the homepages service should be reported via the Support form.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic