How to manage sites on our comprehensive web hosting service

Procedures for looking after your website hosted on our comprehensive web hosting service

Most management operations for your site are carried out on the management server, access.nsms.ox.ac.uk, or through your online site administration interface.

Important Note

Please remember that access.nsms.ox.ac.uk is not the server that your site runs on.

 

Expand All

Management server

Login to access.nsms.ox.ac.uk using an SSH or SFTP client.

IP address-based access restriction

Access is restricted to known IP addresses that have been registered with us (via the technical contact section of the comprehensive web hosting request form). If you need to add or change your registered IP address then please email your IP registration change request to us.

Login credentials - University members

Your username for the management server will be your Oxford username (abcd1234).

The password is your NSMS password, which can be reset by visiting the password reset page. Please note, you will first need to authenticate yourself using your SSO username and password, after which you will be able to update your NSMS account password. Your account will expire in line with your University card.

Login credentials - non-University members

Your username for the management server will have been provided to you when your site was set up, and will normally take the form nsms1234.

You will need to provide a public SSH key that can be used to identify your connections. On a Linux system a suitable key can normally be found in ~/.ssh/id_rsa.pub.

Once logged in you should find the following files / directories (<SITE> is the primary name of your web site):

    database_details
    <SITE>/cron
    <SITE>/home
    <SITE>/htdocs
    <SITE>/logs

There may also be a <SITE>/cgi folder; these are not normally used 

File/folder Purpose
database_details This file will be located in the <SITE>/home folder and contains the server details and credentials for your site database
<SITE>/cgi Contains CGI scripts such as form actions that can be executed but not viewed directly
<SITE>/cron May contain exactly one file called crontab that will be synchronised to the web server to run cron jobs
<SITE>/home Space for files you wish to store outside of the document root of your site, such as backups
<SITE>/htdocs The document root of the web server. Files stored here are accessible through your website
<SITE>/logs Contains read-only copies of log files from the web server for your site

Important Note

Please note that files outside of these specific folders are only stored on access.nsms.ox.ac.uk and are not backed up.

 

Instructions for MySQL

  1. Connect to access.nsms.ox.ac.uk using SSH
  2. Check the connection details for your site database by reviewing <SITE>/home/database_details
  3. Connect using the command-line client as follows:
    $ mysql -h <database server> -u <username> -p
  4. GUI clients can also be used over an SSH port tunnel. An example command-line for setting up a port tunnel is:
    $ ssh -L 3306:database-server.ox.ac.uk:3306 abcd1234@access.nsms.ox.ac.uk

    and you would then connect your GUI client to localhost:3306

Instructions for PostgreSQL

  1. Connect to access.nsms.ox.ac.uk using SSH
  2. Check the connection details for your site database by reviewing <SITE>/home/database_details
  3. Connect using the command-line client as follows:
    $ psql -h <database server>
  4. GUI clients can also be used over an SSH port tunnel. An example command-line for setting up a port tunnel is:
    $ ssh -L 5432:database-server.ox.ac.uk:5432 abcd1234@access.nsms.ox.ac.uk

    and you would then connect your GUI client to localhost:5432

  1. Login to access.nsms.ox.ac.uk
  2. Check quota and usage for all of your sites:
    $ webquota
Please Note:
the quota information for your web sites is *not* live information
as as such may be up to an hour out of date
www.mysite.ox.ac.uk (hosted on nsmsweb42.nsms.ox.ac.uk):
    Usage: 64 KB  Quota: 256000 KB

    Note that this information is updated hourly, so may not reflect the current state if things have changed

  3. Check current usage for example site www.mysite.ox.ac.uk:
    $ du -sh www.mysite.ox.ac.uk/*
4.0K    www.mysite.ox.ac.uk/cron
16K     www.mysite.ox.ac.uk/home
13M     www.mysite.ox.ac.uk/htdocs
5.1M    www.mysite.ox.ac.uk/logs
  4. Check for large files or folders in www.mysite.ox.ac.uk:
  5. $ cd www.mysite.ox.ac.uk/htdocs
$ du -sh * | sort -h

If your site quota is exceed then you will be alerted by email as follows, and have a 7-day grace period before restrictions come into effect:

Dear Sir / Madam,

The disk usage for your website www.jordan.ox.ac.uk
hosted on nsmsfoo.nsms.ox.ac.uk
is over your quota:

Space used: {{ contract.BlockUsed }} of {{ contract.BlockSoftLimit }} KB

Please can you log in to access.nsms.ox.ac.uk and remove or compress
files to reduce space:

https://help.it.ox.ac.uk/web/webhosting

Alternatively, if you would like to increase your quota, please have 
the website billing contact confirm this request via email to 
unix-team@it.ox.ac.uk

Prices are located here:

https://www.it.ox.ac.uk/charges#collapse1650581

If you have any questions or concerns, please do contact us at
unix-team@it.ox.ac.uk

Best wishes,

Michael

-- 
Michael Howe
Unix Platform Services Team Leader
IT Services, University of Oxford

  1. Create a file called crontab in <SITE>/cron on access.nsms.ox.ac.uk, with normal crontab(5) syntax. This file must have Unix rather than DOS/Windows file format (LF line endings, not CRLF)
  2. We strongly advise you to set an email address where the output of tasks will be sent. If you do not do this, you will not receive any output from your jobs

Your file will be copied to the web server during a synchronisation run every 5 minutes, and will then take effect and be run on the webserver (not on access.nsms.ox.ac.uk).

Here's an example crontab to enable the polling of cron jobs on a Drupal site every 15 minutes:

# Set recipient email address for task output
MAILTO='first.last@unit.ox.ac.uk'

# Poll Drupal cron every 15 minutes
15/* * * * * curl --silent -o /dev/null http://www.mysite.ox.ac.uk/cron.php

 

File permissions can be managed using the chmod(1) command when logged into the management server.

Each website is associated with an underlying username for that site, and all executable content is run as this user.

All files associated with the website should be owned by this user, so it should not be necessary to change the permissions on any files to make them readable or writable.

Static files (i.e. images and stylesheets) need to be readable by any user so that the web server itself can read the files (as it is only executables that run as the site user).

Log location

Your apache web server log files are accessible at <SITE>/logs on the management server.

Logs available

The logs are read-only, so are safe from accidental editing. They use a log level of 'info', are rotated every day, and kept for 395 days. The latest two logs are uncompressed text, older ones are gzipped, so to view these you need to either extract them to a writeable location, or you can use tools such as zgrep / zcat / zless.

Log format

The error log is in standard apache format. Since the logs record any messages at 'info' level or higher, you may want to narrow down data by grepping for lines which do not contain [info]. Further details are available in the Apache loglevel documentation

The access log has been customised to include extra useful data. This logging format is:

%{%Y-%m-%d %H:%M:%S%z}t %h %V %u \"%r\" %>s %b
Field specifier Meaning
%{%Y-%m-%d %H:%M:%S%z}t Date in ISO 8601 format, a space, then the time and UTC offset
%h

IP address of the client
%V Hostname of the server. This is useful if you have more than one virtual host running within a single contract
%u Username that the request has come from. For unauthenticated requests this will display as a hyphen
\"%r\" First line of the request, with added surrounding double quotes
%>s HTTP status code of the request, after any internal redirects have been done
%b Size of the response in bytes, excluding headers

Further details are available in the Apache mod_log_config documentation, and you may also wish to consult a
list of HTTP status codes. Note that 4xx error codes mean a problem with the site content or .htaccess settings, and should be solvable by you, whilst 5xx error codes could mean there is something wrong with the server.

Diagnostic example

An example of a recent problem that was diagnosed via log files involved a WordPress site that was migrated from a dedicated server to a hosted site running in a subdirectory. In order to maintain existing links, the site owner created a .htaccess file which re-wrote requests to include the new subdirectory. At this point the site started giving 500 errors.

The logs contained the following [error] level entry:

[Tue Feb 30 12:34:56 1970] [error] [client 127.0.0.1] Request exceeded 
the limit of 10 internal redirects due to probable configuration error
. Use 'LimitInternalRecursion' to increase the limit if necessary. Use
 'LogLevel debug' to get a backtrace

Which was enough information to realise that the .htaccess file was causing a re-write loop, and get it fixed.

Related links

Get support

If you cannot find the solution you need here then we have other ways to get IT support

Get IT support

Submit a suggestion, compliment or complaint