Information for new arrivals
An Introduction to the Computing Facilities at the Computer Laboratory
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 Computing Service, commonly known as the CS. 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 Computing 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 two most important are:
- Raven Many web-based services provided by the University use an authentication system called Raven.
Information at http://www.cam.ac.uk/cs/raven/
- Hermes The University Computing Service email system is called Hermes. Information at https://webmail.hermes.cam.ac.uk/
An introductory booklet about the University Computing Service is available from the Computing Service Reception, or you can find information about them here: http://www.cam.ac.uk/cs Application forms for Computing Service accounts are dealt with at the Computer Service Reception desk (New Museums Site, Cockcroft 2). 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*.cl.cam.ac.uk (e.g. slogin-serv1, 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.
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 are Intel based (although there are still one or two Suns), running 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.
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 Computing Service. The CS also runs a ``Personal Workstation Facility'' (PWF: see http://www.cam.ac.uk/cs/pwf/), which may be of use to people who need to use PCs or Macintoshes. There are PWF 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 firstname.lastname@example.org
If you think you need more than the Windows Terminal Server can provide, discuss the matter with your Supervisor.
Support is available for Windows 7, Vista and XP 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 email@example.com 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.
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 Computer 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 Computing 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 Computing Service machines, Hermes (the Computing Service Mail Service), Raven (the University of Cambridge's central web authentication service), or the PWF, 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/
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 http://www.cl.cam.ac.uk/local/sys/access/otpw/
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.
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, TEX output 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 http://www.cl.cam.ac.uk/local/sys/network/wireless/.
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.
There are two university-supplied mail systems that lab users may think of using as their default mailer. The Computing Service provides a system called Hermes on which all students (at least) have accounts.
See http://www.cam.ac.uk/cs/docs/email.html for a full overview of all email clients available.
For staff (and for research students if they want to use it) the laboratory provides a mail system that delivers locally. If you have such a lab mailbox then by default your mail will arrive in your home directory and can be read with MH compliant mail user agents. For more details, see
People who think they understand UNIX mail should be aware that our mail hub does not run sendmail, and many features, including local delivery mechanisms, are not as you might expect them to be.
Mail can be accessed via emacs under UNIX, but users who wish to do this should not use rmail for email.
The mail address of the lab is:
so your mail address (if you have email delivered here) will be:
e.g. Fred Bloggs might be firstname.lastname@example.org - although note that we set up mail forwarding for most users, so mail sent to this address will be forwarded automatically.
If you have problems with remote mail or need help with finding out correct addresses, send mail to ``email@example.com''.
There is an alternative central University mail system called Hermes, which is run by the Computing Service. Many new users will have already received details of their Hermes account via their college. Hermes is optimised for a different style of use, and may be better for people who expect to need frequent remote access to Email. In particular, people who want to use POP or IMAP are recommended to use Hermes. See http://www.cam.ac.uk/cs/email/ for details.
We do not tend to create local mailboxes for people who have Hermes accounts, preferring to forward any mail sent to us to Hermes. If you do have access to both, we strongly recommend that you choose one of them and arrange to forward the other to it. Likewise we do not tend to create local mailboxes for visitors, preferring to forward any mail sent to us to their forwarding address. Please be careful not to leave Email unread.
Those users who work largely within a Microsoft world may prefer to use the Exchange Server mail system which provides IMAP/POP access alongide access via Outlook and a web browser.
We now direct all incoming mail via the Computing Service's ``ppsw'' mail hub. Before it is sent on to the Lab, the mail is scanned for spam, using a program called SpamAssassin. SpamAssasin records its view of the mail (and the reasons for its view) in the message headers. SpamAssassin is good, but it is not faultless. Its view of the mail is recorded as a ``score'' - a measure of its spamminess: in general, the higher the score, the more likely a message is to be spam.
You use the score by detecting it in your mail filter, and taking action on the basis of what it says. We've set up web instructions on how to do this: (for standard UNIX mail delivery):
(for Outlook mail delivery under Windows):
Printing and Writing Documents
We have a large number of printers of various types. Most of them are laser printers. We have several good quality colour printers, some that are less good, an A0 colour plotter, and most of the laser printers will print double-sided. They are scattered evenly all over the building, mostly in the alcoves. There is a sign on each printer giving its name.
On older linux systems you can type lpq -list for an up-to-date list of all the available printers, their types, their locations and the document types that they will print. On more recent linux systems you need to visit
UNIX users can change their default printer by setting the PRINTER environment variable in their .profile file. Look at the manual pages for lpr and lpq for more details of the printer system, and at http://www.cl.cam.ac.uk/local/sys/printers/
If printing from Windows machines see
Under Windows you may need to install a particular printer, see:
and for troubleshooting help:
Double sided printing is available on most printers and should be used where possible (it is the default on those printers that allow it) as should software options to put more than one logical page on a physical page.
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.
The text formatting system that we support under UNIX is TEX which runs on all the UNIX machines. This document was produced with LATEX, a macro package built on top of TEX.
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 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.
- General System Administration matters (try to use one of the more specific rôle addresses below if possible)
- System Administration specific to Windows machines
- System Administration specific to UNIX machines
- System Administration specific to networks
- Any requests or problems relating to telephones
- Problems (e.g. toner out) with Printers
- Problems (e.g. toner out) with Photocopiers
- Address for the report of any suspected email abuse (etc) from the department.
- 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.
- This is used for management of the top level pages for the Department.
- This is used for management of the www server itself, rather than the data it serves.
- Addresses to contact when anything needs to be moved.
- Addresses to contact when computer equipment needs to be moved.
- Departmental Reception Desk
- The Senior Secretary managing Reception Staff
- Departmental Secretary: The Departmental Secretary is responsible for Administrative matters concerning the Department (rather than providing what might otherwise be understood as secretarial support).
- Matters relating to Health and Safety
- For reporting routine problems with the building
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, X, mail, and wide and local area communications. Safety Officer.
- Robin Fairbairns
- Userid: rf10 Phone: 34419 Room: GC11
Knows about UNIX, Windows, the backup system and TEX. Postmaster.
- Chris Hadley
- Userid: ckh11 Phone: 34686 Room: GC14
Knows about UNIX, printers and printing problems, user accounts. Lab Archivist.
- Jiang He
- Userid: jh347 Phone: 34759 Room: GC13
Knows about telephones, network connections and documentation
- 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, and TEX. Deputy postmaster.
- 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 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.
General local information is provided by the Computing Service:
If you have an account on a machine in cl.cam.ac.uk, 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 firstname.lastname@example.org 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.