Personal Web Space

Web space is available on the www.geos.ed.ac.uk server to create personal home pages (you need to login to the web site for further instructions when you follow this link). This server uses a content management system called 'zope' together with a set of customised web-page editing tools. Information about these editing tools used is here. Any web page can be connected to your 'official' school page here on request to the Administrative Services Officer).

• Personal home pages
• Editing instructions

As well as the "normal" School Web server (which hosts this page, for example) we have another web server which is accessible from the outside world. This server is called xweb.geos.ed.ac.uk

How To Access Your Xweb Pages From Your Windows Desktop

• If you've not applied for web space on xweb ask ITHelp to create it for you.
• Make sure you're logged in with your University username.
• Then left click on the "Start" icon on your menu bar.
• Select "Run...", a small window will open, enter "\\geosweb1.geos.ed.ac.uk\web" (do not include the quotes) at the "Open: " prompt.
• Click "OK" and a new window will open showing you your web space.
• Put your web pages into the "public_html" folder.

How To Access Your Xweb Pages From Your Linux Desktop

• If you've not applied for web space on xweb ask ITHelp to create it for you.
• Log onto a Linux machine in the School, if you user name is "jsmith" then "/web/jsmith" is your xweb space.
• Put your web pages into the "public_html" folder.

How To Access Your Xweb Pages From Your Web Browser

• Your web pages can be found under "http://xweb.geos.ed.ac.uk/~<yourname>/<your web page>", e.g.: http://xweb.geos.ed.ac.uk/~jsmith/index.html.
• Your CGI scripts can be found under "http://xweb.geos.ed.ac.uk/~<yourname>/cgi_bin/<your script name>", e.g.: http://xweb.geos.ed.ac.uk/~jsmith/cgi_bin/helloworld.pl.

Below are more in depth technical notes on xweb

• CGI Problems
• Reporting CGI Problems
• xweb Migration
• What does migration mean to me
• authentication/Password protections
• File Permisions
• Perl Notes

CGI Problems

If you are experiencing problems with your CGI scripts there is reference test scripts at these URLs:

1. http://xweb.geos.ed.ac.uk/~fgibbins/cgi_bin/test.pl
2. http://xweb.geos.ed.ac.uk/~fgibbins/cgi_bin/subdir/test.pl
3. http://xweb.geos.ed.ac.uk/~fgibbins/cgi_bin/test.php?foo=bar
4. https://xweb.geos.ed.ac.uk/~fgibbins/cgi_bin/test.pl

For your information the test script starts:
#!/usr/bin/perl
use lib qw( /opt/perl );
use strict;
use warnings;
use DBI;
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);
...

The PHP Script starts:
#!/usr/local/php5/bin/php-cgi

<?php
phpinfo();
?>

It can't be recommended enough that your scripts should start like this. Many errors will be caught. We are very likely not going to be able to help you unless your scripts start as above.

Your scripts's errors will be reported to your error_<your uun>.log in your logs directory.

Your scripts have write permissions to the cgi_tmp folder. On xweb this can be found in /opt/x_apache/<uun>/. You also have write access to your public_html folder from your CGI scripts although we recommend that you think carefully before doing this.

1. If you have a problem with your CGI scrpt try more verbose logging. Strings (ending in a newline) printed to STDERR will be put in your error log.
2. Try reducing your code by half and half again until the problem disappears, this will quickely tell you where the issues are.
3. Always use strict and warnings.
4. Keep your scripts short and comments things well
5. Put parts of your code in evals, and report error messages, don't just end statements with "|| die ...".
6. Catch eval errors.
7. Use alarms to catch code that might take too long to run. See perldoc -f alarm
8. CGI scripts must be writen in UNIX mode, DOS mode script will not work.
9. Don't assume your home directory will be accessible.
10. The environment that your CGI scripts runs under is very different from the command line. Checking your script on "Unix" is not sufficient a test to check it will work when run under Apache. You must add error checking and catch and deal with any exceptions in your code.

Reporting CGI errors

1. Make sure you've tried everything in the CGI Problems section or you may well just receive an short email referencing you to it.
2. Make sure you tell us where to find the program that's faulty.
3. Be sure to explain any changes.
4. If we don't know what it should look like when it runs without error we can't tell if we've fixed it or not.
5. Are you writing your code as part of some course work? Then please contact your tutor first.
6. The Uni provides many good web scripting/CGI courses.
7. The types of error we are most intereted in are:
   • Database connection timeouts.
   • Security issues.
   • General and complete system failures.
   • Running out of space.
8. The types of problems we are not interested in are:
   • "My scripts have no error checking and they suddenly stopped working.....".
   • "I can't program and I've got to write a CGI script...."
9. We keep daily archives of everyone's scripts. So we can always tell what's changed.

xweb Migration

xweb has been migrated to a new computer with a new operating system. The file space layout has also changed, so has how you access your web files.

Before 2007 any files put into your www directory in your home space (or your M: drive if using Windows), or any links to documents outside your www directory would be served to the world. This included any CGI or PHP scripts (if you don't know what a CGI or PHP script is just ignore those sections).

This has now changed. Your files are now kept on a separate machine is kept apart from the rest of the School's servers. Each user has a seperate directory in which CGI and PHP scripts can be run called cgi_bin.

Apart from one exception all user's existing www folders in their home directories are now symlinks to the new server. Old www folders have been renamed www-old, please check them and remove them at your leasure.

If you have an existing www folder then it should by now have been changed to a symlink to /web/<your user name>.

I.e. Joe Smith logs on with uun jsmith1 and had a www folder in their home directory, this is now a www symlink, which for MS Windows users looks no different. Linux users will note that the terminal uses a different colour for the www symlink (if they have color [sic] turned on, see dircolors.1 ). His /home/jsmith1/www symlink redirects to /web/jsmith1/ inside which is a public_html directory. It's inside his public_html directory that web pages are published from.

If jsmith1 didn't have a www symlink then he could create one by logging onto his Linux account and issuing this command:

ln -s /web/jsmith1 /home/jsmith/www

ln -s /web/jsmith1/public_html /home/jsmith/www

What does migration mean to me

• Your web pages now live on a separate machine than your home directory files, so to share documents they must exist on the remote machine not just linked to from your home space outside the www folder.

  Because xweb is a front line server and is a target for hackers we have to be careful that it's not too tightly integrated into our systems. So although you have access to it from your desktop it may not have access to the same files you have access to. This will affect you if you try to serve files from /geos for example.

  In the current xweb instance access to /home is provided although we recommend you do not lay sym-links on the filesystem on xweb that point to it as the next release of xweb on SL5 will not have this functionality.

  The /geos should not work on xweb.

• Scripts in your public_html directory will no longer work. Scripts must be run from the cgi_bin directory.
• The old Xweb ran Fedora Core 1 (with Perl 5.8.3-16, Bash 2.05b-34 and Apache 2.0.51-1.10) the new web server runs RedHat EL4 (with Perl 5.8.5-36, Bash 3.0-19.3 and Apache 2.0.52-28).
• Actually logging onto the new web server is resticted to CO's
• From 1^st Sep 2007 security will be tightened to stop CGI scripts calling external binaries.
• If you don't have existing web space you'll have to ask a CO to create some for you.
• Space is limited, if you are running an undergraduate course or other temporary work please let us know when we can delete accounts.

Site Authors

Some people use xweb for web sites under domains outside geos.ed.ac.uk, e.g. foo.bar.org. Because your files have moved access to your pages via windows has had to change, the notes below give details for each site's WebMaster as to how to connect now.

FSF or EPFS

Geophysical Equipment Facility

Miombo

Authentication and Access Control

AuthUserFile /opt/x_apache/fgibbins/public_html/sec/.htpasswd
AuthName "This is fgibibns's protected pages, please enter your credentials"
AuthType Basic
Require user fgibbins

So if I had a directory called "sec" in my "public_html" directory that had a password file in it (called .htpasswd) then the directory that I put this .htaccess file in would be protected with those secrets.

In other words:

1. Take this template, edit my user name for yours.
2. Put it in the directory you want protecting.
3. Put your secrets in the .htpasswd file

Note that the path in the file starts "/opt/x_apache" not "/web/fgibbins", or in your case "/web/<your uun>". You may access your files from say "/web/<your uun>" but the server that's processing these files thinks they are under "/opt/x_apache" and this file contains instructions for the server.

So while the path in the file may look unfamiliar please make sure you put the file itself under "/web/<your uun>/...".

Generating the Secrets for your .htpasswd file

On our linux systems there is a command (htpasswd(1)) which manages your .htpasswd file. See "man htpasswd" for complete instructions on how to use it. Here is an example of using the htpasswd command to create the password file I mention above using SHA encryption (the -s does this):

htpasswd -s -c /web/fgibbins/public_html/sec/.htpasswd fgibbins

Please note that this command uses the path the linux system knows i.e. "/web/fgibbins/...." not the path the web server uses, i.e. '/opt/x_apache/fgibbins/...'
Confusing the two is a sure fire way to confusion

Protecting your files with EASE a.k.a. Cosign

It's also possible to use Cosign:

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{SERVER_NAME}/~fgibbins/sec/$1 [L,R]
AuthType Cosign
AuthName "Restricted Files"
Require user fgibbins

File Permisions

If you're not used to Unix file permisions then trying to get your web page up on xweb can seem fustrating. Getting the balance between having security tight enough not to have our web site hacked into and loose enough to be easily used is difficult.

One of the first things that can hinder your web site is your umask. Your public_html directory has the SGID bit set. This means that all files written are owned by the group apache. If your umask restricts the group from reading (or in the case of scripts or directories executing) the files then they won't be read by apache and therefore won't be seen on the web site.

For working on the web site a umask of 0027 will do.

For scripts apache needs to be able to execute the files. Permisions of "750" will work best. This can be set with the chmod command.

The file permission are set after the file contents are copies to the web site. This means that if you run out of room on your web site volunme then the correct permissions will not be set. After asking for your volunme to be extended copying the file over again WILL NOT WORK. Copying a file over agsin just replaces its contents, it doesn't change it's owner. Delete the file before copying it over.

Perl Notes

All our linux systems have extra perl modules installed in /opt/perl to use them please make sure that you have this line at the top of your perl script:

use lib qw( /opt/perl );

Or if you'd like to experiment with the cutting edge Mod_Perl distribution:

use lib qw( /opt/perl /opt/mod_perl/i386-linux-thread-multi /opt/mod_perl/x86_64-linux-thread-multi );