CUC3 NFS Server

The Theory sector has a read-only NFS server carrying commonly used packages that are not part of the Linux distributions installed on the standard workstations. This server is currently available read-only to all machines in the Theory sector, so you can mount it on your personal laptop if you want. Workstations will have it set up automatically. You may need to be added to access lists to use some of the licenced software on personal machines.

The simpler packages are installed in the bin subdirectory, so you should make sure that /usr/local/shared/bin is in your PATH. The more complex ones may need special setup, and you should consult the software documentation pages for details.

The NFS service is currently provided by paun.ch.cam.ac.uk. There is also a second server, pou.ch.cam.ac.uk, that is kept in sync with paun. pou is intended as a hot spare, and so should not be used by workstations. Instructions for swapping to the hot spare.

If your workstation has an empty /usr/local/shared then you have not got the NFS filesystem mounted. If you are having problems then try a reboot. This shouldn't be necessary because we use the automounter.

The workstation documentation contains links to package lists for each image.

The server used to provide several different NFS exports for historical reasons. I used to do a completely separate one for each version of the standard workstation image, but this became too much work and started to occupy lots of disk space as we are now on the sixth major version of the standard image. We now have one export (/usr/local/software/linux) with a directory under it for each image version.

The top level contains software that works on any current image. These are usually well-behaved packages that don't need much in the way of supporting libraries (eg xmakemol) or binary-only packages that don't customise their install based on the image (eg VMD, Intel compilers). The very simplest 32-bit packages can go in the top level bin directory which is on the PATH of every image, but only do this if the package is something you are not likely to want to upgrade (eg xwrits). Everything else has a separate install directory and is controlled by a module. This level has Modules/modulefiles for 32-bit software modules and Modules/modulesfiles64 for 64-bit software modules. Avoid installing 64-bit software in the top level unless it's a binary-only package (eg Intel fce) and it is in its own directory controlled by a module in the modulefiles64 directory.

The next level down is the image-specific subdirectories. These have two subdirectories: i386 and x86_64. 32-bit software that works on the 64-bit machines should be put in the main image directory; i386 is specifically for 32-bit software that will not work on a 64-bit machine (eg binary Python modules, Portland compilers). All 64-bit software goes in x86_64. The Modules directory has three subdirectories: modulesfiles, modulefiles32, and modulefiles64. modulefiles32 is for the software that lives in i386.