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.

Passwords

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:

Raven Many web-based services provided by the University use an authentication system called Raven.
Information at http://raven.cam.ac.uk/

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: http://www.ucs.cam.ac.uk/
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.

Machines

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*.cl.cam.ac.uk (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*.cl.cam.ac.uk 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.

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 http://www.ucs.cam.ac.uk/desktop-services/mcs), 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 desktop.cl.cam.ac.uk, 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 http://www.cl.cam.ac.uk/local/sys/OpSystems/timesharing.html.
If you need help with this facility send email to win-admin@cl.cam.ac.uk

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 win-admin@cl.cam.ac.uk 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 http://www.cl.cam.ac.uk/local/sys/unix/software-install.

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

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

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.

Security

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 http://www.cl.cam.ac.uk/local/sys/unix/nfs-sec-krb5/.

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 slogin.cl.cam.ac.uk 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 http://www.cl.cam.ac.uk/local/sys/ssh/

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.

Networks

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.

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.

Backups

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.

Mail

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:

your-CRSID@cl.cam.ac.uk

e.g. Fred Bloggs might be fb123@cl.cam.ac.uk. But it will be forwarded to:

If you have problems with remote mail or need help with finding out
correct addresses, send mail to ``email-admin@cl.cam.ac.uk''.

Printing

Printing

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.

Etiquette

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.

Customisation

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
http://www.cl.cam.ac.uk/local/sys/

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

sys-admin@cl.cam.ac.uk

General System Administration
matters (try to use one of the more specific rôle addresses below
if possible)

win-admin@cl.cam.ac.uk

System Administration specific to Windows machines

unix-admin@cl.cam.ac.uk

System Administration specific to UNIX machines

mac-admin@cl.cam.ac.uk

System Administration specific to Macs

network-admin@cl.cam.ac.uk

System Administration specific to networks

telephone-admin@cl.cam.ac.uk

Any requests or problems relating to telephones

printing@cl.cam.ac.uk

Problems (e.g. toner out) with Printers

photocopyingcl.cam.ac.uk

Problems (e.g. toner out) with Photocopiers

abuse@cl.cam.ac.uk

Address for the report of any suspected email abuse (etc)
from the department.

email-admin@cl.cam.ac.uk

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.

pagemaster@cl.cam.ac.uk

This is used for management of the top level pages for the
Department.

webmaster@cl.cam.ac.uk

This is used for management of the www server itself, rather
than the data it serves.

moving@cl.cam.ac.uk

Addresses to contact when anything needs to be moved.

moving-machine@cl.cam.ac.uk

Addresses to contact when computer equipment needs to be moved.

reception@cl.cam.ac.uk

Departmental Reception Desk

senior-secretary@cl.cam.ac.uk

The Senior Secretary managing Reception Staff

departmental-secretary@cl.cam.ac.uk

Departmental Secretary: The Departmental
Secretary is responsible for Administrative matters concerning the Department (rather
than providing what might otherwise be understood as secretarial support).

safety@cl.cam.ac.uk

Matters relating to Health and Safety

building-services@cl.cam.ac.uk

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.

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
http://www.cl.cam.ac.uk/

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

Telephones

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 telephone-admin@cl.cam.ac.uk 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 http://www.phone.cam.ac.uk.