Website management on the MWS

Responsibilities of a website manager

Allowing others to use the server:

You may apply for accounts for people who will be maintaining the data on the web server at the same time as you apply for the server. You may also apply for people to be given access to the server at a later date. To add other users or managers to an existing web site, complete another online application form giving the names and user identifiers of those who are to be allowed access. Passwords will be sent through the University Messenger Service in the usual way and the person will be added to the site users or managers group as relevant.

It is is normal for all the users of a site to be managers. Users who are not managers can create personal web pages, but the cannot modify the main site unless the managers have used advanced facilities to enable access. This is not recommended unless the managers have significant Unix expertise (see the section on User Groups below).

Note that if someone already has access to the MWS to work on another web site you will still need to complete an application form, but that person will not receive another password. He or she will be given access to your site by Computing Service administration but will use the same password to access, using the relevant website name, all sites to which they are authorised.

Removing people from server access

If someone no longer requires access to the web server you should send email to mws-support@ucs.cam.ac.uk. You need to ensure that any data that person has been maintaining is passed to someone else, this can be either an existing or new web server user.

If someone has access to several sites, and their access to one site is cancelled, then any personal web pages they have will no longer work on that site but will be visible from the other sites to which they have access.

If you no longer wish to be the manager:

You will need to notify the Computing Service that you are handing over control of the server to another person. A managed web server must always have at least one manager. Web servers that are abandoned (i.e., have no managers) will be removed. The Computing Service cannot take responsibility for an abandoned server.

Email

email addresses

As previously stated all websites must have a working webmaster address and email to this address must be dealt with in a timely and professional manner.

In addition, every user of the web server must have an address @cam.ac.uk so that they can be contacted should the need arise.

email provision

There is no incoming email to the web servers. Outgoing email from CGI, PHP or SSI will use the site's webmaster address by default. Users cannot use CGI, but can send email if they are logged on to the site. This will use their user@cam.ac.uk address. For further mail notes and advice see the MWS FAQ.

Logging in to the Web server

Web site managers and users can connect to their site using ssh or scp/sftp (ftp, an insecure protocol, can only be used from inside the cam.ac.uk domain).

For example, for the site www.foo.cam.ac.uk

    ssh www.foo.cam.ac.uk

will place the manager/user in his/her own home directory on the server, e.g. /home/spqr99.

Document and log location

The directories initially provided for web site content and related material are:

• /site/htdocs: the document root of the site
• /site/cgi-bin: the script directory for the site
• /site/admindir: a directory where authors may place material which is not to be accessed directly by the web server, but is to be used by scripts etc.
• /site/apache/logs: directory containing Apache logs

Whenever Apache sends an error page to a browser, it writes a message to /site/apache/logs/error_log explaining why the error occurred. If you experience a problem with one of your pages, look in this file before asking for help.

Creating pages

You can create your pages either by preparing them elsewhere and then moving them to the server using scp or sftp, or using an editor once you have logged in using ssh. If you are in the Cambridge domain you can use rcp or ftp to transfer pages, or telnet or rsh to login, but these are deprecated as all data, including your password, will pass across the network unencrypted.

User groups

Default groups

There are two default user groups; website managers (groupname managers) and users (groupname users). All users (including the managers) will be the latter group.

If a site manager creates a file or directory the group owner will, by default, be managers, for example:-

    
    -rw-rw-r--   1 spqr99     managers      9516 Sep 13 18:55 draft.html
    drwxrwxr-x   7 spqr99     managers      1024 Mar 23 00:17 manual

Restricting access to particular areas

If you wish, you may restrict access to certain parts of the server to named individuals. For example, a departmental web site may wish to allow research groups to maintain their own pages. A manager of the web site will have access to the whole server, but some individual users will only require access to a particular area. To do this you will need to create groups and allow the members of the group access to their own research group directories.

However: note that you need to be familiar with Unix if you are to manage this successfully, as it will also involve changing groups and permissions on a directory created for the group's files. We advise that, wherever possible, you should avoid doing this and use human, rather than technical, methods to ensure that website users update only the correct areas.

To create other user groups you use the local command groupmanage. Note that:-

• there is a limit of 100 self created groups per web server
• each user can only be in 13 groups
• site managers cannot add others to the managers or users groups
• managers are not automatically members of any created user group
• groups cannot be deleted, but can be emptied of users and/or renamed
• group names must be in capitals e.g. COURSES
• changes to group membership only take place when the user next logs in.

Using groupmanage:-

• To create a group COURSES:
  groupmanage COURSES --create
• To give the group a description (this will help the managers to remember what the group was intended for):
  groupmanage COURSES --title "Course information"
• To add users to the group
  groupmanage COURSES --add xyz998
• To remove a user from the group:
  groupmanage COURSES --remove xyz998
• To make a local group manager
  groupmanage COURSES --manager-add spqr99
• To remove a manager from a group
  groupmanage COURSES --manager-delete xyz998
• To remove all managers from the group
  groupmanage COURSES --manager-clear
• To check the status of a group
  groupmanage COURSES --info
  Which will display information, e.g.
  

      
      group        COURSES
      title  	Course information
      managers
      members      spqr99 xyz998

You will then need to create a directory for the group and change its group ownership to that group.

For examples controlling access from a web brower see the page on access control using .htaccess

Logs & the DPA

Version 6.0 of the statistical log analysis program analog is provided. This appears to be the final version, as development of analog seems to have ended in December 2004. The program is installed as /usr/local/bin/analog (/usr/local/bin is on the default path). Analog's own documentation is available locally in /usr/local/analog-6.0/docs as well as from the analog web site. The images needed to view analog6.0 HTML output are at /usr/local/analog-6.0/images. To make these images available to your web server when displaying your reports, copy (or soft-link) this directory into the directory containing the reports.

The Apache log files are rotated monthly. All but the two most recent old ones are compressed using gzip (e.g. /site/apache/logs/access_log.2.gz). Twelve old versions are normally kept, so at least a year's worth of logs are normally available. If you intend to keep logfiles of your server elsewhere, please be aware of your responsibilities under the Data Protection Act 1998. More information about these responsibilities have been published by the University Data Protection Officer.

Last updated: November 2010