You are here

Informatics homepages web service

Printer-friendly versionPrinter-friendly version

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/ is 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 accessible 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.

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 ask the Informatics HR office IF-4.36 (infhr@inf.ed.ac.uk) if you are a member of staff, or contact the Graduate School if PGR.

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 (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 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 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. However it does not obtain your AFS credentials, so by default any AFS space should be safe.
  • 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,cgi,data}/ directories.
  • CGIs need to be executable, and owned by you, or the server will not run them.
  • CGIs 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 CGIs 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";
    ?>
    <!-- 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 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 (and pgresearch.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 Support form.

System Status

Home dirs (AFS)
Network
Mail
Other services
Scheduled downtime

Choose a topic