Lab Directory Infrastructure

/home/user1

With the exception of ranier, this is scratch space on every machine (i.e., not backed up)

/nfs/rainier/home/user1

Home directory space.

/nfs/rainier/home/user2

Home directory overfill space. Anyone in the esysadm group should be able to create directories there.

/nfs/xraid/home/user1

Most package management occurs within /nfs/xraid/home/user1. For convenience, we have an alias for this directory called /l/esysadm. We organize it using the following directory structure:

• download
• build
• packages
• arch
• repository

Most of these directories are further subdivided by architecture. We have one non-architecture specific directory

• noarch

and 3 architecture-specific directories:

• linux
• irix
• solaris

We describe the purpose of each directory below:

• download

  Directory for storing package distributions that are installed on our machines. Package distributions usually come in the form of a tar.gz or tar.Z file. If the package distribution is source code, java binaries, python scripts, or some other non-specific architecture distribution, it should be placed in the noarch directory. Otherwise it is an architecture-specific binary distribution and should be placed in either the irix, linux, or solaris subdirectory. This directory is not backed up.

• build

  Directory for configuring and building a package to be installed within the packages directory on our machines. The naming convention for placing a package in the build directory is as follows:

  /l/esysadm/build/<arch>/<package>/<version>

  If the package distribution is java binaries, python scripts, or some other non-architecture specific files, configure the package within the noarch directory. If it is source code, configure and build the package in the appropriate architecture directory (i.e., the architecture you're targeting): irix, linux, or solaris. Similarly, if it is an architecture-specific binary distribution, configure the package in the appropriate architecture directory: irix, linux, or solaris.

• packages

  Package installation directory. The naming convention for installing a package here is as follows:

  /l/esysadm/packages/<arch>/<package>/<version>

  If it is an architecture-specific installation, place it in the appropriate architecture directory (which can also be referenced as /l/local/packages). If it is a non-specific architecture installation, configure it to install in the noarch directory and then add links to the architecture-specific directories so that it can visible from machines of all architectures.
  
  
• arch

  General installation directory for common versions of all packages. No actual executables are stored here; only links to the packages directories. stow can be used to automatically create the links.

• repository

  Area to install architecture-independent data for the lab (e.g., CVS repository, component examples, etc.)

/usr/local

This is local disk space on each machine (i.e., local filespace). Some server installations are done at here if they require root protection. Since it will not be common to maintain multiple server versions, we will use the following server naming convention:

/usr/local/<package>/<version>

It is often convenient to add a link to the server installation

/usr/local/<package> --> /usr/local/<package>/<version>

so that you can shorten the downtime between server upgrades. This will allow you to deploy an updated version of a server and then just update the link to point to the newer version when ready. Also, unless the server configuration has changed, you won't need to modify any of the system configuration files because the path will be the same.