In this section we have grouped together a series of frequently asked questions regarding web sites on the OUCS web server. If you cannot find the answer to your question here, please send your question to us via the Help Pages and Form.
We do not currently offer a PHP scripting service on this server. If you need PHP for your work please see NSMS who do provide this as a paid for service.
Information collected in web logs is purely for system related reasons. No specific details of an individual's use of computer systems are not made publically available. However, some server owners do allow third parties access to this information. OUCS has no control over this practice.
All the OUCS web servers record information on which files are accessed, when and by whom. This last item consists of the IP name and number of the computer you are using to access the web, together with your user name on that system (if available). IP naming schemes used for computers can allow an individual users identity to be determined.
It is sometimes necessary to restrict access to part or all of your website because subsections may still be in development or because you only want people using machines with an Oxford IP address seeing your pages. You may want to restrict access to specific users by setting usernames and passwords if you are running a specific course for instance. All these scenarios can be catered for, by following the instructions below.
Every browser accessing the web has an IP (Internet Protocol) name (e.g.
rabbit.oucs.ox.ac.uk) and a number (e.g.
1.32.180). Both can be used to restrict access to your pages. It is
important to realise that you protect a directory and its subdirectories, not
individual pages. To do this you have to create a file called
.htaccess which contains an access control list (ACL). This file
should be placed in the directory which you wish to protect.
For instance to protect a subdirectory called 'papers' so that it can
only be accessed by machines in the Oxford domain you need to add the
.htaccess file to that subdirectory. It should contain the
Order deny,allow deny from all allow from .ox.ac.uk
This works in two steps. First it prevents access for anyone but then allows access to the directory to machines in the oxford domain. You can further refine this statement by changing the Allow from line to read:
Only machines visiting from the oucs.ox.ac.uk domain will be allowed to see the directory pages. You can specify more domains by adding further 'allow from' statements to the file. Instead of using the IP name you could use the IP number to get the same result.
It is also possible to protect Web directories by username/password combinations. In order to set this up you should follow these steps if you using the OUCS web server (if you are using a different server contact that system's sysadmin):
- Log in to the Linux system
linux.ox.ac.ukusing your Oxford username and password
- Create a file containing usernames and encrypted passwords:
% htpasswd -c /web/users/$USER/cgi/myusers.passwd fred Adding user fred New password: rubbish (not echoed) Re-type new password: rubbish (not echoed)
- Make sure that the file which holds the passwords is
world-readable. For example:
% chmod a+r /web/users/$USER/cgi/myusers.passwd
AuthType Basic AuthName my-private-webpages AuthUserFile /web/users/aragog.oucs.ox.ac.uk/6/e/fred/cgi/myusers.passwd require valid-userAuthName can be anything meaningful to the people that need to supply a username and password (note that a value is required). If the name contains spaces, it must be given in quotes. Using the above example, when the username is requested the browser will display "Please enter username for my-private-webpages at users.ox.ac.uk"AuthUserFile is the location of the file you created in step . This file is actually held on the web server. Therefore you need to give it a path name which is meaningful to the web server:
- Make sure that
.htaccesshas got world read access:% chmod a+r .htaccess
- If you want to authenticate by both username/password and
client host address, you can use the Satisfy directive in
.htaccessto specify whether access is allowed if either test is passed, or if both must be passed (the default).
<META http-equiv="refresh" content="0;url=http://www.my-new-site.com/">
This site has moved. If you do not get redirected to our new site,
click <a href="http://www.my-new-site.com">here</a>.
This redirects the browser to the error page you created above, which in turns redirects the browser to your new site. You have to include /~USERNAME (which is your Oxford username) because the .htaccess file needs absolute paths, and the Oxford username is part of this.
Internet Explorer by default displays "Friendly HTTP Error Messages" if the content of your custom error message is less than 512 bytes. So, in the example above you must make sure the page size is greater than 512 bytes. One way would be to add a suitably sized graphic.
You will need to create a form and link to a CGI script which will process the form for you. The script will also validate your form before allowing it to be sent to your email account. This script is located at:
A short tutorial on using this script in a form is provided in the HTML tutorial.
Server side includes are a special type of HTML comment that tells the web server to dynamically generate data and place it in a web page. You can use SSIs on your OUCS web site by naming your files as ' .shtml'. A general tutorial on SSI is available at: http://www.webreference.com/programming/ssi/intro/
The Common Gateway Interface or 'CGI' technology is a well established method for web site interactivity. It is not a programming language itself but a standard method to allow external programs to run on a web server. The external programs can be written in many languages, but the most common one is Perl. OUCS recommends the use of 'Safe Perl' to build CGI programs. More information on the Perl language can be found on the Perl web site: http://www.perl.com
Yes, some useful but poorly documented examples are available here: Generic Perl Scripts.
Note that @ interpolates an array when used in double quotes ("") (unlike in perl4 which tried to guess whether you wanted to interpolate or have a raw @ in there). If you want to hard-wire an email address with an @ in it then either use single quotes or prefix the @ with a backslash ("$user\@wherever"). Note also that you gather the whole message together into one string to pass as the third argument.
Only a restricted set of the Perl language is available: usage of unsafe features (even within eval statements) are trapped and the program is not run. There are many Perl operators not available to the CGI directory in which your program is run. These include the operators that could affect the operating system. The following list is not exhaustive but includes the most common excluded operators:
- system, `backticks`, exec, fork, syscall, signal handlers, pipes (including open(FOO, "|bar") and open(FOO, "bar|"))
- network access (socket, bind, connect, ...)
- File munging (rename, link, opendir, chown, ...)
- System V IPC (shared memory, message queues, semaphores)
- File tests (-r, -w, -l, ...)
- Calling perl on other files (require, use, do 'file')
- Files opened for reading must be owned by the user. Your CGI
program is run with a current directory of ~/cgi/. It is strongly recommended that
you use relative pathnames (for example,
- Files opened for writing must be opened by using a filename containing no "/" characters. The filename is taken to live in the directory ~/cgi/out and the file must already exist at the time the open is performed. It can be a symbolic link if desired.
Once you have written and debugged your CGI program, put it in ~/cgi/bin (creating that directory if necessary). There is no need to include a leading "#!" line, nor will one be honoured if you do. Supposing that your username is quux and your program is called foo, the URL to run your program is
Any use of a masked operator in your Perl program will trigger a compile time error (which your browser will display) and the program will not run at all. A "masked operator" is an operator which is restricted but which, unlike "open", is not aliased to a secure sanitised version. The error message will be something like opname trapped by operation mask at line ... where opname is replaced by the name of the offending operator.
Please be aware that, even with the restrictions on what your program can do, it is possible that someone out on the web will be able to persuade it do something you weren't expecting. Even with the file limitations, for example, your program may have a bug which lets someone see the contents of any file you own. You are responsible for the CGI programs you write and you must ensure that your CGI programs do not contravene OUCS rules.
For sorting lists, the perl built in sort operator is masked (since inconsistent comparison subroutines can cause the underlying C library qsort function to core dump). Two functions are provided for sorting lists in the two most common collating sequences: ASCII and numeric. To sort an array @unsorted into increasing ASCII order use
- Every CGI script must output at least one header line. If your
program generates output, it needs a Content-type line indicating what kind of
document (MIME type) it is producing. If your script outputs an HTML page, the
correct format is:
If you have moved your site from users hosting to a different one either inside or outside of the university you will probably want to re-direct your site visitors to the new location. This is easy to do by:
- create a
.htaccessfile using a text editor
- Type in the following code changing
myusernameto your username and replace
www.my-new-site.comwith the real location of your site:
- Save and upload to your users webspace. Visitors to your users web space will now automatically be re-directed to the new location.