User's Guide
    Sysadmin's Guide
    Grid Info

Lab Directory Infrastructure


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


Home directory space.


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


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:


    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:


    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.)


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:


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.

Last updated 31 Mar 2006 by