This document is written for the benefit of those system administrators at ARL:UT who wish to access (and make available on their systems) software which physically resides on the Computer Center computer systems. Using Sun's NFS (Network File Service) and a suite of perl scripts called opt_depot which was written by Computer Science Division personnel, it is possible to merge software which CSD has made freely-available into the directory called /opt on another system. Freely-available software may be public domain, no fee copyrighted, site licensed, or ARL:UT generated. System administrators are cautioned to not make copies of any of this software available outside of ARL:UT without checking with the Computer Science Division first.
Software which CSD has made freely-available will reside in the /site directory. At this time, there are two subdirectories: SunOS5.2 and SunOS4.1.3. The SunOS5.2 directory contains software that has been compiled under Solaris 5.2 and the SunOS4.1.3 directory contains software that has been compiled under Sun OS 4.1.3. There will be other subdirectories added as they become available, i.e. SunOS5.3. The system administrator should NFS automount the directory /v, using the NIS map auto.vol. This will mount the site subdirectory which is appropriate to his/her system under /v/site. For example, if his/her system runs Solaris 5.2, automounter will mount the CSD volume /site/SunOS5.2 as /v/site. For detailed information on automounting volumes, refer to the documentation for gash.
Once mounted, the system administrator will see two main subdirectories under /v/site: /v/site/packages and /v/site/os. The directory /v/site/packages is the one that contains the freely-available software, and is the focus of this document. It contains a subdirectory for each installed product that is freely available, i.e. elm, perl, etc. Within each software package (directory) are further subdirectories, typically bin, lib, and man. The executable(s) for the software package are kept in the bin directory, any libraries associated with the software package are kept in the lib directory, and any man pages are kept in the man directory. In addition, there may be other directories there (for example, info and include) depending on the software package. Finally, every directory in /v/site/packages should have a file called ARLUT_README, which includes such information as what the package is and what it does, the name of the person who installed it, the date of installation, where the sources were obtained, any special information about how the software was installed, and anything else that might be helpful to administrators.
The /v/site/os directory contains software that must be handled in a special way, and will be described later in the section entitled Exceptions.
If the system administrator is following this procedure for the first time, then there are some directories that must be created at this point:
The next step is for the system administrator to run one of the opt_depot scripts, called opt_setup, which actually invokes three other opt_depot scripts: opt_clean, opt_link, and opt_depot. The opt_setup script should be invoked with the command /v/site/opt_setup -v. The -v parameter tells opt_setup to be verbose. By default, the log file will be placed in /logs/opt_depot/opt. If the system administrator wants the log file in another location, it must be specified with the -l (lower case L) option.
Running the opt_setup script will cause several things to happen. The first is that soft links will be generated in /opt/depot for every directory (i.e. software package) found in /v/site/packages. That is, if there is a directory called /v/site/elm, then opt_setup will create a soft link called /opt/depot/elm that points to /v/site/elm. This function is performed by the script opt_link.
Secondly, the binaries, libraries, and man pages found in the subdirectories of each individual product are soft-linked together into the directories /opt/bin, /opt/lib, and /opt/man . That is, all executables from each product can be found in /opt/bin, all libraries from each product are found in /opt/lib, and all man pages from each product are found in /opt/man. There will be other directories created in /opt as needed (/opt/info and /opt/include), depending on the products in /v/site/packages and the files they create. This function is performed by the script opt_depot.
Thus, /opt logically contains all software from CSD's /v/site volume in addition to software previously installed into /opt. Therefore, /opt/bin can be placed in the default pathname, PATH, in order to use the products that have been added to the system. The same is true for /opt/lib and /opt/man, which are used in the LD_LIBRARY_PATH and MAN_PATH variables.
NOTE: The opt_depot script uses a lock file called lock.opt_depot to prevent two users from running opt_depot at the same time. This lock file is created in the destination directory (i.e. /opt) and is automatically removed when the run is completed. However, if the user CTRL C's while opt_depot is running, the lock file is not removed and the next time opt_setup is invoked, an error message will be displayed indicating that opt_depot is still in use. Remove the file /opt/lock.opt_depot and run opt_setup -v again.
On subsequent executions of opt_setup, the links in /opt/bin, /opt/lib, /opt/man, etc. will be checked for data integrity as a first step before doing anything else. Any bad links, such as to non-existent files in /opt/depot and any links to any files excluded or blocked by the /opt/.exclude and /opt/.priority files (described in the section Instructions for Controlling the Software), will be removed as a first step in the opt_setup process. This function is performed by the script opt_clean.
Execute the command catman -w -M /opt/man to rebuild the /opt/man/windex database. The man program uses this database to locate the man pages that were installed into /opt/man.
It will be necessary for the system administrator to run opt_setup on an occasional basis if they wish to incorporate changes as they are made to the /v/site volume. System administrators may wish to consider running opt_setup via a cron entry on some regular basis, such as daily or weekly.
Occasionally, there are multiple files withthe same name that need to be linked into a particular subdirectory of /opt. When opt_setup is run, it will report these name conflicts. There are three ways to resolve file name conflicts when running opt_setup:
The /opt/.priority file can contain either individual file names or software package names, specified either by absolute pathname or pathname relative to the /opt/depot directory. Each entry should be separated by a newline character, and comments are denoted by a pound sign (#) as the first character on a line. The order in which file names or package names are placed in the file determines the priority of the file or package and the one with the highest priority will be the one linked in /opt/bin, /opt/lib, /opt/man, etc. If there are two files by the same name, and one is listed in the priority file and one is not, then the one listed has the highest priority. If neither of the files are listed in the priority file, then the first one linked remains.
An example /opt/.priority file follows:
# This is the /opt/.priority file for determining opt_depot linking priorities
# Version 19.19 of gnuemacs will have priority over version 18.57
gnuemacs~19.19
gnuemacs~18.57
# The lmstat file in idl will have priority over all other files by that name
/opt/depot/idl/bin/lmstat
An example /opt/.exclude file follows:
# This is the /opt/.exclude file to keep opt_depot from linking files
# X Windows software X11R4 will not be linked into /opt
/opt/depot/X11R4
Some software that is made available on the /v/site volume is used often enough (or is important enough) that system administrators might wish to have a local copy of the software, rather than accessing the software over NFS. A good example of such software is X11R5. To accommodate this, system administrators might wish to make a local copy of /v/site/packages/X11R5 and physically install it in /opt/depot/X11R5. In this way, the system is using its own version which is faster and always available, rather than depending on the network. The opt_setup script will treat physically-installed packages in exactly the same way that it treats packages accessed via NFS.
System administrators may choose to run independently of NFS entirely and to make local copies of each software package in which they are interested. In this case, the system administrator would run the opt_depot script, rather than run opt_setup, which will create the appropriate links in /opt/bin, /opt/lib, and /opt/man to packages in /opt/depot.
The exception to the policies described above is for software that replaces executables that come with the operating system. For example, the Computer Center runs a specialized version of finger that displays the information in the gecos field of a passwd entry. Anticipating that some system administrators might wish to use our version of finger, but not wanting to put it in the default path, it has been placed in the /v/site/os directory. The system administrator has the ability to access that software and should manually install the software in the directory that the operating system expects to find it, such as the /usr/bin directory.
A simple diagram is included with this set of instructions which should demonstrate the client-server relationship of opt_depot. Also, copies of the man pages for each of the opt_depot scripts (opt_depot, opt_clean, opt_link, opt_nuke, and opt_setup) have been included for convenience.