Linux

The laboratory supports Ubuntu, which has "stable" and "bleeding edge" versions. We strongly recommend use of the stable "LTS" version, which has support for five years, rather than the other versions which are only supported for nine months. A PhD student selecting a "stable" system should be able to use the same system for three years without requiring an upgrade. Those selecting "bleeding edge" are likely to want to keep up with the latest version, with a rolling upgrade to the latest version (either "early" in the cycle to try the latest features, or "late" to wait til teething problems are sorted). There may be pressure to upgrade if a system is no longer supported and there is a security problem with the system. Permanent members of staff are likely to require either rolling upgrades, or occasional reinstalls.

The system aims as far as possible to be a simple “out of the box” installation: the criterion for altering things is purely to make the system interact comfortably with the laboratory infrastructure (such as printers, and the file servers which house your home directory among many other things), provide a "standard" set of packages, and to protect the security of the system.

Time-sharing systems

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.

There are a number of Linux servers available for remote login via secure shell. Windows users typically access them using PuTTY, 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
 ssh-remote.cl.cam.ac.uk domain name pointer ssh-remote-0.cl.cam.ac.uk.
 ssh-remote.cl.cam.ac.uk domain name pointer ssh-remote-1.cl.cam.ac.uk.
 ssh-remote.cl.cam.ac.uk domain name pointer ely.cl.cam.ac.uk.
 ssh-remote.cl.cam.ac.uk domain name pointer slogin-old.cl.cam.ac.uk.
 $ host -t ptr ssh-remote-1
 ssh-remote-1.cl.cam.ac.uk domain name pointer svr-ssh-1.cl.cam.ac.uk.
 $ host -t ptr distro-ubuntu
 distro-ubuntu.cl.cam.ac.uk domain name pointer distro-u18-04.cl.cam.ac.uk.
 distro-ubuntu.cl.cam.ac.uk domain name pointer distro-u16-04.cl.cam.ac.uk.
 distro-ubuntu.cl.cam.ac.uk domain name pointer distro-u10-04.cl.cam.ac.uk.
 $ 

This shows that the ssh-remote service runs on e.g. ssh-remote-0 and ely, and that ubuntu services are run on the machines distro-u16-04 and distro-u20-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-04 on a TSS machine.

Kerberos authentication 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 the above example, if wanting to connect to the ssh-remote service, try e.g. ely.cl.cam.ac.uk. 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 'light' tasks, such as accessing files, on a standard machine, but not for CPU intensive tasks. slogin-serv should provide such a service, being a service running on multiple machines, e.g. one physical and two virtual. If there are problems connecting, it is worth trying the machine ely so that logs etc can be inspected.
• 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.
• svn server (svn*-serv), permanently running: svn upgrades the metadata 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. Such problems can be avoided by always using a specific version. 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 should 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.
• 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 distro-list.cl.cam.ac.uk. 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.