Computer Laboratory


Time sharing systems in the department

Most users will have a personal workstation running a suitable operating system for their work. However, users may have particular requirements to do things which require specific facilities not available on their workstation, or may want to use departmental facilities remotely. The department operates a number of time-sharing systems to fulfil such needs.

Note that they are intended for light use by many people, so are not suitable for resource intensive jobs. If you have such a need, email sys-admin.


Multi-user Windows access is provided via a Windows Server running in Terminal Services mode. It runs an RDP v6.1 server allowing remote connections. Linux users typically access this facility using the cl-rdesktop command to connect to the server (not available to Fedora Core systems before FC6), 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. Unlike on a Windows workstation users do not get Administrative rights and so cannot install applications.

Inactive sessions are disconnected automatically to reduce the load on the server, after 2 days of non-use the session is automatically logged out.


There are a number of Linux servers available for remote login via secure shell. Windows users typically access them using the PuTTY command, and Linux users use slogin or ssh.

To find out more about the host or hosts providing a particular service, use a command such as host to look up their address or pointer records, e.g.

$ host -t ptr ssh-remote domain name pointer domain name pointer
$ host -t ptr ssh-remote-2 domain name pointer
$ host -t ptr distro-ubuntu domain name pointer domain name pointer domain name pointer domain name pointer domain name pointer domain name pointer domain name pointer domain name pointer

This shows that the ssh-remote service runs on ssh-remote-0 and ramsey, and that ubuntu services are run on the machines distro-U9-04, distro-U8-04 and distro-U10-04. There are a number of machines, which helps resilience, but any particular machine may be unavailable at a particular time, so if a machine doesn't work, try another one. Try listing the servers and try them each manually in turn until one works (and email sys-admin reporting the problem giving the time and if possible a cut-and-paste of the command and error text). Non current distributions (e.g. machines starting distro-) may need to be booted, e.g. using "cl-boot-mc distro-U10-10" on a TSS machine.

Kerberos autjhentication requires you to request a connection to the canonical name of the machine, rather than to an alias for the service it is providing. In thge above example, if wanting to connect to the ssh-remote service, try e.g.

For the current list of available servers and aliases, look at the pointer record for slogin-list, distro-list, etc.

Idle sessions take up resources and block routine administration of the system. Please logout when not using the system. Idle sessions may be terminated.

There are a number of services which the machines provide including

  • a "std Lab" machine (slogin-serv) permanently running: users whose workstations do not have all the facilities available on standard Lab managed systems may want to perform certain tasks, such as doing an email look up, on a standard machine. slogin-serv should provide such a system, running on multiple machines, e.g. one physical and one virtual.
  • login from the internet (ssh-remote or ssh-remote-[01]) permanently running: users wanting to connect from outside the department are normally able to ssh directly to their workstations (unless there is a security alert). However, their workstation may be switched off, they may not have a suitable kerberos ticket, or may not have a user ssh key, making a server appropriate.

    To access files on the Netapp filer, a kerberos ticket is needed, e.g. using "cl-krenew --maxout -f".

    If a ticket is available on one machine but not the other, consider setting up a ticket on both, or using the machine specfic name, i.e. ssh-remote-0 or ssh-remote-1.

  • svn server (svn*-serv) permanently running: svn upgrades the meta data whenever a later version is used on a local copy. If this happens by mistake, the local copy can be downgraded using a python script.
    By always using a specific version, it avoids such problems. To get a full list, use "host -t ptr svn-serv-list".
  • filer access using the TGT server (cron-serv0 and cron-serv1) permanently running: cron and at jobs which need to access the filer may not work on user Workstations if the kerberos ticket needed to access the filer has expired. By setting up the TGT server to ensure a valid kerberos ticket, filer access should be available.

    It is recommended that more than one server is used, and that filing locking is used if simultaneous access might cause problems.

    Users shouild ONLY login to these machine to setup cron or at jobs. They should not be used for interactive sessions.

    The machines have restricted access. If you have problems logging in to setup a job, try connecting to the machine via slogin-serv.

  • SSH application relaying (ssh-relay[12]) permanently running: users wanting to relay ssh traffic (connections or port forwarding) can use these machines.
  • permanently running systems (various) permanently running: users may turn their workstations off when not in the department, and want to perform a quick task remotely without having to remotely boot it, so can login to the slogin machines.
  • specific distribution (distro-*) run only when needed: if a specific distribution is needed, such as a Fedora Core 6 system or a 32 bit CentOS system, there may be a suitable service available. For the current list of available aliases and servers, look at the pointer record for If you need a machine, start it using the boot web page or use cl-boot-mc on an slogin machine, and email sys-admin to keep track of current user requirements.