Informatics Homepages Web Server

Most users within Informatics are given permission to 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 are bound by the Computing Regulations.

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

  /public/homepages/<user>/web

and

  /public/homepages/<user>/cgi

... 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/ subject to a disk quota, currently 5MB for taught students, 20MB for research students and 50MB for staff. Special cases will be considered, and should be directed towards support.

The Basics

The web server is a slightly tweaked (mainly for the user CGI) version of Apache 2.2.

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

Similarly the CGI program /public/homepages/fred/cgi/myscript will be exposed as http://homepages.inf.ed.ac.uk/cgi/fred/myscript .

Anything you place in /public should be considered as just that, ie "public". Though you can restrict pages via .htaccess files and file permissions, faulty CGI scripts or misconfiguration of any .htaccess files, can render the permissions 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 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.

More detail

One important thing to note, is that - for security reasons - the homepages web server does not have access to any of your networked home directories. This means you cannot put symbolic links in from /public/homepages/fred/web/file.html to /home/fred/somefile.html, or access /home from scripts etc.

Also the utility wget, which is often exploited to download cracks and further exploits to the machine, has been renamed Wget (ie 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 it's new name.

CGIs

Your CGI scripts will run as your userid, and so in theory have read/write/delete access to any of the files that you own. If you write/install a script that can be exploited, then potentially a malicious user could delete all your files.
As your networked home directory eg /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/ (or /public/homepages/fred/cgi/) directory.
CGI's need to be executable, and owned by you, or the server will not run them.
CGI's will not be executed if they are somehow modifiable by other people, eg they are within a group/world writable directory, or the CGI itself is world/group writable.
Unfortunately 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. eg:
```
  Content-type: text/html

  <html>
  ...
  </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 by useful to aid debugging:

  #!/usr/bin/perl

  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

PHP is running in "safe mode", that 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 CGI's above, your home directory eg /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 lines 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:
```
#!/usr/bin/php
<?php
  echo "Content-Type: text/html\n\n";
?>

```
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 any problems:

  <?php
    ini_set("error_reporting", E_ALL);
    ini_set("display_errors", TRUE);
  ?>

SSIs

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 database has been upgraded to prefer 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 an 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 eg in PHP:
```
  <?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.

Problems

Try the general web FAQ. Any techical problems with the homepages service should be reported via the web support form http://www.inf.ed.ac.uk/systems/support/form/.

Author: neilb
Last updated: 2008/07/25 16:20:20

Home : Systems : Web