Computer Laboratory

Information for new arrivals

An Introduction to the Computing Facilities at the Computer Laboratory

Chris Hadley

This document describes the computing facilities available to staff, research students and longer-term visitors at the University of Cambridge Computer Laboratory. It is intended to tell you what exists, how it is used, and who to see for more information.

If you're new to the lab, please read the entire document. It will save time in the long run. Doubtless you will discover lots of important things which are not written down here and should be. When you do, tell Chris Hadley, so that the document can be improved for future users.


It can be confusing for new arrivals - a variety of pieces of paper giving passwords may be handed to you in your first few days. This section should help you make sense of them.

The Computer Lab is (obviously) part of the University - some services we run ourselves, and some are run by the University Information Service, commonly known as the UIS (or the CS by older people as they used to be called the Computing Service). For that reason there are several passwords that you might need to access these various services, some of which will be provided for you automatically and some of which you may need to request.

You will be allocated a University unique identifier made up of your initials followed by some digits (eg Fred Bloggs might be fb123). This identifier is called a CRSID. If you already had one of these through previous associations with the University, then it should not have changed. If you are accidentally allocated two different identifiers, please tell sys-admin so that the error can be corrected. All of the services, ours and those run by the University Information Service, make use of your CRSID.

You will also be allocated a Computer Lab account. In return for a signature, you will be given a login name (your CRSID) and an initial password. This password is required for you to login to machines housed in the Computer Lab. We use a unified account system, so the same password will work on both Windows and Linux machines. We request that you change this password as soon as you can to one that you can remember easily. We suggest that you do this on a Windows machine rather than a Linux machine because the Linux passwd command is not very user-friendly - if there is a problem with the password you try then it will either fail silently or give an ``Authentication token manipulation error'', which is not of much use. Under Windows if there is a problem then it will return useful information, like ``password too short'', or ``password does not include a lower case letter, an upper case letter and a digit''. On a Windows machine type Ctrl-Alt-Del and select Change a password..., and follow the instructions.

There are a variety of other passwords you might be given. The most important are for:

These two services will use the same password. An introductory booklet about the University Information Service is available from the Information Service Reception in the Roger Needham Building (next door), or you can find information about them here: Application forms for Information Service accounts are available from Information Service Reception, or may have been set up for you in advance. Remember to quote your CRSID on any forms you fill in.


As described above, when you arrive at the Computer Laboratory, you will have (or will be given on request) accounts on a large number of machines, including a set with names which are of the form slogin-serv* (e.g. slogin-serv, slogin-serv2 etc) - all running varieties of Linux. These machines are connected to the Lab Ethernet, and in general can be accessed from anywhere else within the department.

You may have been allocated a desktop machine - but not always because often nowadays people often prefer to work with their own laptop. This should all have been arranged in advance.

Depending on what research you are doing and who you are working with, you may need accounts on other machines. Nearly all machines in the Computer Laboratory run some variety of UNIX or Windows. Many of them are used for particular purposes by the research groups that obtained them. It may be possible to get an account on such a machine even if you are not doing related research, but you should bear in mind that the primary use of the machine will have priority. There are also a number of machines which are used as servers; accounts on these are not generally available.

The slogin-serv* machines mentioned above perform a variety of functions. These include

  • login from the internet: users wanting to connect from outside the department are normally able to ssh directly to their workstations. However, their workstation may be switched off, they may not have a suitable kerberos ticket, or they may not have a user ssh key, making an slogin machine more appropriate.
  • providing standard Lab machines for users whose workstations do not have all the facilities available on standard Lab managed systems and who may want to perform certain tasks on a standard machine.

For more details of these machines and the services that they provide

Before you commit yourself to using a particular machine for your research, you should ask whether that machine or something compatible is likely to be available for your entire stay at the Computer Laboratory. There is nothing more embarrassing than finding yourself without a machine on which to do the final part of your research.

If we know in advance which group you are joining, you may have been given accounts on the appropriate machines already. If not, you will need to ask the person in charge of the research group which owns the machine. Once you have cleared it with the appropriate person, the account will normally be added by sys-admin. All of the machines are under central management even though the group which paid for them have the final say in who uses them.

In addition to the departmental machines, you may want an account on machines run by the University Information Service. The UIS also runs a ``Managed Cluster service'' (MCS: see, which may be of use to people who need to use PCs or Macintoshes. There are MCS areas in various locations throughout the University, including a room SW11 in the William Gates Building. See the section on Passwords for application details.

Windows and other non-UNIX Machines

For people who want access to a Windows system merely to run Office applications such as Microsoft Word we run a Windows Terminal Server, a Windows Server running in Terminal Services mode allowing remote connections. Linux users typically access this facility using the cl-rdesktop command to connect to the server, Windows users can use the Remote Desktop Connector application to access the server.

The service is provided primarily for access to Microsoft Office applications for occasional use. Additional applications are only added to the server if there is widespread support for them.
See If you need help with this facility send email to [Javascript required]

If you think you need more than the Windows Terminal Server can provide, discuss the matter with your Supervisor.

Support is available for Windows 8.1 and 7 and such systems are usually centrally managed. Central infrastructure provision includes SQL Server as well as Exchange mail services. All Microsoft products need to be licensed. Please contact [Javascript required] if you need a product that is not already installed on your machine. Visual Studio and MSDN are available for use.

No formal support for other versions of Windows is provided.

No formal support is offered for User owned machines whether Windows, Macs, or even some version of UNIX.

Managed vs Unmanaged Machines

The default allocation for users is what is known as a Managed machine. That is, it is managed by us as system administrators. However, there is a fine distinction between managed and unmanaged, and users of managed machines can perform most system administrative tasks themselves. For users of Windows systems the distinction is fairly plain, managed systems get their credentials from our Active Directory, unmanaged systems do not. For users of Linux systems, managed systems will have their password systems and kerberos credentials managed by us. We would also expect them to take printer configurations from us, and our automounter system to allow access to the central file server (a.k.a. elmer, or the filer). Users of such managed machines do not have the root password because there isn't one, but it is possible to gain privilege using the sudo command. There is also the cl-asuser command which allows the registered user of the machine to run a number of safe commands with raised privileges. So, for example, it is usually possible to install software yourself (within the limits imposed by the particular software distribution), see

Alternatively, you may opt to have an unmanaged machine, on which you will be entirely responsible for the system administration yourself. Be aware, however, that opting to do it all yourself means that you will restrict the amount of help that we are able to give you, and that if you run into problems you may be largely on your own. Unmanaged systems do not sit on the main lab VLAN, and will not be able to access the filer using NFS. We would expect users on unmanaged systems to comply with common-sense security procedures, e.g. do not create accounts for people outside the lab, do install security updates to software, etc.

User-owned Machines

Increasingly it is not uncommon for people to bring their own machines into the lab. Please talk to one of the Computer Officers if you wish to attach it to the lab network. If nothing else it may need to have DHCP servers set up to supply its IP configuration, and there may be other issues to consider, such as security and consistency with lab software. It will be placed on a separate virtual network from the rest of our machines. In the first instance, to request a connection please complete the form at

in the first instance.

If you are running a Windows-based machine we require you to run up to date anti-virus software, and also be up to date with all security hotfixes. Free anti-viral software is available via the University Information Service, see

Conditions of Use

All the machines in the Computer Laboratory are used subject to the conditions of the University Information Strategy and Services Syndicate. You can get a copy of the rules from Information Service Reception, or you can read them online in the Computing Service Information Server. Remember also there are laws governing the use of computers, in particular the Data Protection Act and the Computer Misuse Act. From your point of view, the most important things to remember are:

  • Don't use other people's accounts, or allow your account to be used by anyone else.

  • Respect people's privacy, and all copyright and licencing restrictions. Ability to do something does not imply permission.

  • Behave sensibly, especially in the use of shared resources.

Whilst it is not absolutely forbidden, we do not think very highly of people who use our machines for games playing. Such activities must not impede or annoy other people in any way. A small amount of recreational or private use of computing facilities is perfectly acceptable.


We have a unified password system that keeps passwords in step on our UNIX and Windows machines. If you change your password on one machine it will change on all of them to which you are allowed to login.

We do not support different passwords on different machines or groups of machines. Your password is not the same as any you might have on University Information Service machines, Hermes (the UIS Mail Service), Raven (the University of Cambridge's central web authentication service), or the MCS, and it will not propogate to or from them if changed.

We ask you to choose a sensible password (only 8 characters, not a word, and with one or two non-alphabetic characters). You should not tell your password to anyone, and you should change it if you believe that someone else has discovered it.

Although we try quite hard to keep intruders out of our systems, there is no very strong enforcement of internal security. The UNIX filespace protection mechanism should be seen as a way of preventing accidents rather than a serious way of keeping information safe or private. In particular, the Lab systems are not suitable for the storage of sensitive personal data covered by the Data Protection Act. You may protect your files as you wish, but we do not encourage extensive use of read protection. Remember that it makes it harder for people to help you when you have problems if they cannot read your files. If you change the protection mode of your home directory, you should not rely on this as the only protection for your files; such changes may occasionally be lost if your filespace is moved to a different disc.

We are making increasing use of Kerberos on lab machines. Kerberos is a computer network authentication protocol, which allows machines and users communicating over the network to prove their identity to one another in a secure manner. This system uses tickets, normally automatically obtained when logging on at the workstation console, to authenticate user NFS access to the filer (e.g. elmer). This is a complex system, and in most cases there are many ways to do things. For details see

Connecting from outside the lab

We occasionally have trouble with people trying to break into our machines from outside. As a result, we are quite careful about login sessions that originate outside the building. This is both because we are bound by software licence agreements to keep proprietary code reasonably secure and because people would be annoyed if someone from outside managed to destroy important data.

Some restrictions concerning login type connections to lab machines from outside the department have been imposed, and it is possible that further restrictions will follow. Currently people can login directly to lab machines from outside the department using the Secure SHell ssh / slogin / PuTTY. ssh uses encryption and multiplexed channels to provide a simple and more secure connection between machines. If there is a security problem we may block direct ssh access to most machines from the internet (although is likely to still be available). Before you have a need to login to the lab from outside you should read our webpage on ``Use of the Secure Shell (ssh)'', at

However, even connections using ssh can be insecure as the password can be intercepted by a variety of means. OTPW (one time passwords) are a solution to this. See

for details of how to prepare and use OTPW - we use a simple paper-based scheme. Using this you will be able to access the following sets of machines:

  • slogin-serv - connect to a Time Sharing System, which can be used for simple commands, but as a shared resource, is not appropriate for intensive computing.
  • ssh-relay - allows an incoming connection to be relayed over ssh to an internal workstation.

Each service is provided by a number of machines for resilience. If a connection fails, try again, and it may try another server. If it repeatedly fails, try appending 1, 2 and 3 to the name (eg slogin-serv1 or ssh-relay2), to access a particular instance of the service. The services may share machines, but users should not rely on this. In particular, it may be that users cannot use ssh-relay machines to run shell commands.

The next time you log in from outside the department to any of the ssh server machines slogin-serv, ssh-relay, svn-serv, etc, when a user key is not available, you will be prompted for Password NNN: in which case you should enter your prefix password, immediately followed by the (usually eight character) one-time password number NNN from your password sheet.

It is wise to generate a OTPW sheet when in the Lab and carry it around, so that if there are problems it is possible to login to sort them out. If you really can't get in contact sys-admin and we may be able to suggest alternative means of access.

File Systems

The UNIX systems make extensive use of NFS in conjunction with an auto-mounter to present a reasonably coherent filestore. Everybody has a personal home directory, called /home/login-name. You get the same directory whatever UNIX machine you use. If you use the pwd command to find out the true name of the directory, you may see a different name, beginning /nfs, /Nfs or /auto; names of this form should never be written into programs or shell scripts - they are not the preffered form and may only be valid in the short term.

All user file spaces, both UNIX and Windows, are housed on a file server. This means that it is possible to access your Windows space (if you have one) from within UNIX and vice versa.

Although we have quite a lot of disc space, we also have a lot of people, so we have to manage the space carefully. Furthermore, we have a limited backup capability which imposes restrictions on the amount of backed-up filespace we can allocate each user. You will find that you have a filespace quota, which limits the amount of material you have on disc. You will probably find your default quota quite generous and adequate for some time, but if you are an experienced user and have brought material with you from another site you may require more. Do not despair. Within reason, your quota can be increased to give you enough space to do your work. Before asking for an increase, you should check your files carefully for wasted space such as old emacs backup files, object code, browser cache which can be recreated etc. You should also learn about the gzip command, which can save a vast amount of space by compressing infrequently used files.

Space that is not backed up (aka scratch space) is available, either on a shared disc (UNIX = /anfs/bigdisc, Windows = \\filer\bigdisc\*) or locally on a workstation. UNIX users: To create local scratch space for yourself run sudo mkscratchdir on the specific machine - this will create a directory /local/scratch/login-name.

Remember to be especially careful with data in space that is not backed up.

In addition to personal directories, research groups may have ``group'' directories for shared material. These are accessed by names beginning /usr/groups/ (UNIX) or \\filer\groups (Windows). Some of these have group quotas, but there are some older ones in which we have to rely on common sense and good manners to keep disc usage under control. Do not store personal files in group areas.


The various machines are connected to the Lab Ethernet. It appears in offices as a set of 4 RJ45 (ie telephone-like) sockets in the floor boxes which also house power sockets. The sockets are not enabled by default - the wires from the sockets lead back to a number of wiring closets and the connections within these closets need to be set up by a system administrator.

If you need a socket enabled go to

and then Request a network connection and fill in the details requested.

Please do not rearrange connections to sockets yourself - fault finding is difficult if our documentation concerning what is connected where is out of date.

There are several wireless networks available in the William Gates Building. For full details see

Operating schedule

Our server machines normally run 24 hours a day, 7 days a week. Any problems which arise will usually be dealt with promptly during normal office hours, but there is no formal staff cover at night, weekends, public holidays etc.

Occasionally we need to switch off the main machine room for power or air-conditioning work; this is usually but not invariably done at a weekend. Individual machines are taken down from time to time for maintenance, upgrades etc. We try to avoid peak times where possible, and to give notice by email.

Hardware can of course fail at any time. You should be aware that in order to save money, most of our machines are not on ``fast response'' maintenance contracts; some older machines are not covered at all. Repairs can sometimes take a long time. Do not rely on everything being working all the time. If you have deadlines, allow plenty of time in your schedule to meet them.


The file server takes regular snapshots of user filespace which you can access yourself to recover recently deleted files. UNIX users can type ls -l .snapshot in your home directory (note that this does not show up if you use ls -a), and you will see a number of directories named sv_hourly.n, sv_nightly.n and sv_weekly.n. sv_hourly.0 will be the most recent, and you should be able to recover accidentally deleted files from there yourself.

We also take regular backups, but this is mainly to protect ourselves from hardware failures and bugs in system software. System administrators may be able to restore files not in the snapshots if enough information is given, but retrieving individual files can be a lengthy process. There are better ways of spending our time. If you do have to ask for a recovery, give as much information as you can about what you lost, when, and its previous update history. Dumps may fail for a variety of reasons, and it is unwise to rely on dumps being done at particular times. Filesystems on private workstations may or may not be dumped--do not rely on them without checking.

We do not take regular archive copies of discs. Backups normally go back a few months, but no further.

In addition, if your workstation doesn't have an optical disc writer we have DVD and CD-ROM writers available for individual use, contact sys-admin for details.

Workstations and Logging In

Workstations should be switched off when not in use for extended periods (e.g. over the weekend or even overnight). The <b>slogin-serv</b> machines can be used when your machine is off. Many machines can be switched on remotely - contact sys-admin for details.

If the monitor has its own power switch it is a good idea to turn that off when it is not in use for a substantial period.

If you are logging in from a remote network you will need to use ssh. You will be asked for your ssh key pass phrase on the relevant machine, which should not be echoed to the screen as you type it.

If the login attempt fails, you are not told why. This is a standard security feature. It could be a wrong identifier or password, an attempt to log in from an unauthorised location, or one or two more obscure reasons. If you cannot log in after several attempts, contact one of the experts who will check logs to see why it is failing.

Logging out and Powering off

Logging out is not at all difficult, but we do ask people to do it. Unattended idle sessions are a security risk, they consume system resources, and impede some system maintenance activities. We do not expect you to log out if you are just going for a cup of coffee or a short meeting, but you really should log out at the end of your working day. We do not like seeing multi-day sessions.

If you are not going to be logged into a workstation for a while and you are certain that nobody is using it remotely then please turn it off.


For visitors, interns, and many other users we will by default redirect all mail arriving or originating here to the email address supplied by that user when we create their account.

The University information Service provides a system called Hermes on which most people have accounts. Mail which arrives here is by default forwarded to a Hermes account, so your mail address (if you have email delivered here) may be:

                    [Javascript required]

e.g. Fred Bloggs might be [Javascript required]. But it will be forwarded to:

                    [Javascript required]

For details see

The mail address of the lab is:


If you have problems with remote mail or need help with finding out correct addresses, send mail to ``[Javascript required]''.



We have a large number of printers of various types. Most of them are colour laser printers, some are Black and White, all will print double-sided. We have an A0 colour plotter, suitable for printing posters. They are scattered evenly all over the building, mostly in the alcoves. There is a sign on each printer giving its name.

For a list of printers and their locations see:

UNIX users can change their default printer by setting the PRINTER environment variable in their .profile file. For more details of the printer system see:

If printing from Windows machines see

Under Windows you may need to install a particular printer, see:

and for troubleshooting help:


Please do not print large jobs in the middle of the day. If printing a large number of pages please periodically check the printer has enough paper.


Many UNIX programs are customisable to suit personal preferences. This is a powerful and useful facility, but it needs to be used sensibly. The more you customise, the less likely it is that you will be able to get help when you have a problem, because other people will not understand your world. You may also find that you have a lot of work to do to keep your customisation up to date when new versions of the underlying programs are installed.

A particular danger is picking up extensive customisation from other people. This can be a quick way of getting started with something, but remember that the person you got it from is quite likely to leave the Lab before you do, perhaps leaving you without support. If you do pick up customisation from friends, take the time to understand what you have installed.

It is easy to lock yourself out of the X window system by setting up your customisation badly. A trick worth knowing is that if you terminate your password with ``F1'' when you log on, all your customisation will be ignored and you will get a very simple session with just a single window. This should be enough to enable you to undo the changes you made and try again.

Questions, and how to get help

When you have a problem or a question, try your best to find out the answer for yourself before bothering other people. Even if you do not find the answer, you are likely to learn other useful things.

On UNIX systems, the man command allows you to access the on-line manual. If you want to know about the ssh command, type man ssh. The man command can tell you about all the UNIX commands, system calls, C library routines and various other things. If you don't know the name of the manual entry you want, type man -k wombat for a list of all entries that have to do with wombats.

The other place to look for documentation is in the local WWW pages. Most local modifications are documented and URLs for this are given through this document. A good starting point is

Other useful sources of information are:-

Roommates and others in your group

The people you actually work with can be a valuable source of help. It is not their job to help you of course, but most people will be prepared to give some assistance to a newcomer. But be careful, the information you get might not always be accurate or up to date.

Your supervisor

Whether your supervisor can help with day-to-day problems will depend very much on whether he or she routinely uses the systems you are having trouble with. It is definitely worth a try, because your supervisor should at least understand what you are trying to do.

The Experts

Certain questions are best directed by email to a rôle address, that is, an address which matches a set of people all of whom might be able to answer (see below). This is because questions directed to an individual might go unanswered if that person is away, or it might save that individual having to forward your question if you have not sent it to the person best equipped to deal with it. Many of these addresses run a ticketing system - you will be returned a ticket number in acknowledgement when you email them.

When contacting sys-admin, unix-admin, win-admin, mac-admin or printing, please make sure you say which specific machine your problem relates to. Please do not assume all machines are identical as far as software goes - they are not. Even if you are absolutely certain your problem is a general one then it is probably still a good idea to say which machine or machines you know it to be a problem with. As well as saying which machine, also give details, e.g. cut and paste an example, and try to make it easy to reproduce the problem.

Rôle addresses

[Javascript required]
General System Administration matters (try to use one of the more specific rôle addresses below if possible)
[Javascript required]
System Administration specific to Windows machines
[Javascript required]
System Administration specific to UNIX machines
[Javascript required]
System Administration specific to Macs
[Javascript required]
System Administration specific to networks
[Javascript required]
Any requests or problems relating to telephones
[Javascript required]
Problems (e.g. toner out) with Printers
Problems (e.g. toner out) with Photocopiers
[Javascript required]
Address for the report of any suspected email abuse (etc) from the department.
[Javascript required]
This address should be used for any problems with email. When reporting a problem, please include all the headers of the message, along with the error messages.
[Javascript required]
This is used for management of the top level pages for the Department.
[Javascript required]
This is used for management of the www server itself, rather than the data it serves.
[Javascript required]
Addresses to contact when anything needs to be moved.
[Javascript required]
Addresses to contact when computer equipment needs to be moved.
[Javascript required]
Departmental Reception Desk
[Javascript required]
The Senior Secretary managing Reception Staff
[Javascript required]
Departmental Secretary: The Departmental Secretary is responsible for Administrative matters concerning the Department (rather than providing what might otherwise be understood as secretarial support).
[Javascript required]
Matters relating to Health and Safety
[Javascript required]
For reporting routine problems with the building

System Administrators

The rôle addresses mentioned above are preferred, but if you do need to speak to a specific person:

Piete Brooks
Userid: pb22 Phone: 34659 Room: GC16

Knows about Linux PCs, mail, and wide and local area communications. Safety Officer.

David Damarell
Userid: djsd100 Phone: 31858 Room: GC11

Knows about UNIX.

Chris Hadley
Userid: ckh11 Phone: 34686 Room: GC14

Knows about UNIX, printers and printing problems, networks, user accounts.

Martyn Johnson
Userid: maj1 Phone: 34647 Room: GC09

In overall charge of the system support team. Knows about UNIX, Linux PCs, networks, the backup system.

Brian Jones
Userid: bdj23 Phone: 67018 Room: SN10

Knows about Linux, Windows, databases; PC and general hardware, PCBs.

Graham Titmus
Userid: gt19 Phone: 34620 Room: SS26

Knows about Windows, Microsoft Applications, Databases, UNIX, Macs, Lisp and similar languages. Windows postmaster.

Online information services

A large part of the University Library catalogue is available online. This includes many departmental libraries, including our own. There is a terminal in the library to access the catalogue. The computer lab's web page is

This holds pages for all the main research groups as well as system and departmental information and maps of the buildings.

General local information is provided by the Information Service:

If you have an account on a machine in, you can export your own personal files to the WWW. Details at:


We are mentioning telephones in a document about computer facilities because the computer and telephone networks are intimately linked. Telephones are on a Cisco VoIP system and are powered over the Ethernet connection. A second RJ45 socket on the back of the telephone may be used to daisy-chain a computer, and this facility is often used for workstations or laptops. The telephone number is configured as a property of the handset and does not depend on where it is plugged in. Telephones are allocated to individuals and if the phone on your desk does not display your name then it has not been assigned to you and you should send email to [Javascript required] for advice.

Voicemail is available and this and other facilities can be controlled from a Web browser. Further information about the University telephone system may be found at