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:

  /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/ 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 now running Apache 2.4 (see homepages-upgrade for more detail). It has been slightly tweaked, mainly for the user CGI feature.

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 accessible as http: //homepages.inf.ed.ac.uk/cgi/fred/myscript.

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 5.6. Files ending in .shtml and .html are parsed with mod_include, and files ending in .phtml and .php are parsed as PHP.

The people pages under http://www.inf.ed.ac.uk/people/ 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.

CGIs

  • 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
    
      <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 be 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 run as a CGI. This means any PHP scripts have the same local file level access as the owner of the file (but not AFS files, as they do not get the necessary AFS credentials). Because of this, PHP scripts will not be executed if they are somehow modifiable by someone else, eg if they are group or world writeable, or if the directory they are contained within are group or world writeable.

    The base PHP on a DICE SL7 machine is 5.4 and the binary is located at /usr/bin/php. However on the homepages service, we are running the 5.6 Software Collection version of php - http://computing.help.inf.ed.ac.uk/scl - which is rooted in /opt/rh/rh-php56/root/, and may not been available on all machines.

  • 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 
    
  • The following lines at the beginning of your PHP may help you debug 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 (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:
      <?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 technical problems with the homepages service should be reported via the Support form.

Last reviewed: 
28/11/2017

System Status

Home dirs (AFS)
Network
Mail
Other services
Scheduled downtime

Choose a topic