Inter-Departmental Resource Sharing for the LHNCBC

L. E. Berman
Internal Report for the Communications Engineering Branch
April 7, 1995


1.0 Background

As we have agreed in previous systems administration meetings we would like to provide a unified consistent paradigm for sharing software resources among the departments within the LHNCBC. Currently we have all been providing public domain software such as emacs, perl, gcc, mosaic, and other sundry software to our users by our own mechanisms. There has also been some resource sharing between the branches, but this has been on a limited scale.

Limitations of the current scheme are the duplication of effort in maintaining the same software packages for each branch, the waste of disk space for this maintenance, inconsistent naming conventions for platform dependent software, and the lack of necessary redundancy to insure high likelihood of resource availability (i.e. - software package not available due to a server being down). We are proposing the depot paradigm to overcome these limitations.

The depot paradigm was developed at NIST by our very own Steve Clark and Barry Warsaw, et. al. Depot takes advantage of features in the automounter that allows for overlaying a filesystem on a common mount point regardless of operating system and hardware architecture. Depot is organized such that consistent naming conventions and a predetermined file hierarchy exist to facilitate easy access to required resources.

2.0 Depot Paradigm

To understand depot you must keep in mind that there are two different views of each resource. There are the client and server views. For demonstration purposes, let us assume that ceb is maintaining a resource named sundry for SUN OS 4.1.X and Solaris 5.4 and will export this to lhc.

2.1 Server

As shown in figure 1 the server side (ceb) physically has the sundry resource existing underneath /export/depot. The sundry hierarchy has been exploded to present the typical path navigation for an exported resource under depot. At the first level under sundry the following items are available:

  • doc - this contains any documentation relevant to a particular application that is not a man page
  • etc - application specific files necessary at run-time that are platform/OS independent (ex: emacs .el files)
  • include - platform/OS independent header files
  • man - platform/OS independent man pages
  • plat.sun4os4 - contains all of the binaries, etc files, header files, libraries, and man pages specific to a SUN 4 running SUN OS 4.1.X.
  • plat.sun4os5 - contains all of the binaries, etc files, header files, libraries, and man pages specific to a SUN 4 running Solaris 5.X.


Figure 1. Server (ceb) side physical view of a resource to be shared with clients.

In this example, the platform/OS dependent portions of the resource are available in path.sun4os4 and plat.sun4os5. Each application that exists under sundry will appear in both path.sun4os4 and plat.sun4os5. These directories contain the following items:

  • bin - binary files specific to the particular platform/OS
  • etc - application specific files necessary at run-time specific to the particular platform/OS
  • lib - libraries specific to the particular platform/OS

2.1.1 Server System Files

  • /etc/dfs/dfstab
    share -F nfs -o rw=lhc, root=ceb /export/depot

2.2 Client

From the clients' (lhc) perspective, there is a physical and logical layout for the resource as shown in figure 2. At the top level the user sees /depot with all of the available resources from other servers. The hierarchy is very similar to the server, except that at the third level, you will notice that instead of having directories path.sun4os4 and path.sun4os5, there is a directory "plat". When a client tries to access something in the sundry hierarchy that is platform/OS specific, the automounter will automatically reference the correct portion of the resource by overlaying the correct subdirectory on top of /depot/sundry/plat. In figure 2 we see that lhc would overlay path.sun4os4 ontop of /depot/sundry/plat since it is a SUN OS 4.1.X machine.


Figure 2. Client (lhc) side physical/logical view of a resource to be mounted from server (ceb)

2.2.1 Client System Files

  • /etc/auto_master
    /depot auto_depot
  • /etc/auto_depot
    sundry -intr / ceb:/export/depot/&\


    		/plat ceb:/export/depot/&/plat.${ARCH}${OS}

2.3 Extending Resource Sharing

The example described above can easily be extended by sharing resources from several machines. This is done by adding more entries in the client's /etc/auto_depot file and by making the necessary changes to the server's /etc/dfs/dfstab file.

3.0 Departmental Responsibilities

Each group has agreed to assume responsibility for a particular resource. Additionally, each group will be responsible for maintaining a backup copy of one other resource so that we can maintain resource redundancy in the event of a system failure. Redundant resources will not be required to maintain "src" trees. The resource assignments are as follows:

RESOURCE PRIMARY REDUNDANT
adm cmis lhc
gnu itb ceb
sundry ceb itb
x11r5/6 lhc cmis

Each of these resources will be exported to interested parties and should be setup so that they can be modified by members of the "depot" group (aronson, berman, sclark, neve, patsy, seamans). Jules will also put together a depot mailing-list.

4.0 Unresolved Issues

This is a good start but there are still some unresolved issues that we should consider:

  1. How do we handle operating system upgrades? If a particular branch is not ready to move to the next version of an OS how shall this be resolved?
  2. How do we handle building software that might contain many options?
Return to top Return to top