| Installing opt_depot using setup.sh |
This document is intended to help guide the systems administrator though the process of installing opt_depot using the setup shell script included with the opt_depot software package.
The first thing to do is figure out what type of configuration you want for opt_depot, depending on the functions you would like it to perform. There are 3 types of installations:
Example: using opt_depot with a home Linux system.
Advantages: Allows clean and simple management of software packages in a non-networked UNIX environment.
Configuration Issues: Because there is no common network involved, running opt_link is unnecessary. Also, there is no need to put the line to run opt_setup into chron; simply run opt setup when installing any new software packages
Example: In a networked system the opt_depot scripts are physically installed on each individual client, as opposed to having them installed on the server.
Advantages: This setup allows the greatest customizability among clients with respect to directory and file names.
Disadvantages: Maintaining the opt_depot scripts is more difficult, since each client has its own copy of the opt_depot software to maintain and update.
Configuration Issues: Since each client has a copy of opt_depot, separate configuration files will reside on each client as well. These files contain the directory information necessary to run the opt_depot scripts, and may vary from client to client.
Example: The opt_depot package is installed on the server, allowing all clients access to a shared copy of the program.
Advantages: see client-side with network disadvantages. Only the server's copy of opt_depot must maintained, and any client systems using opt-depot will possess the same directory structure with respect to the depot, software base and log directories. However, each client may still have its own individual 'sites' file indicating the package archives for that particular client system.
Disadvantages: see client-side with network advantages. Directory and filenames must be constant across all clients. For example, if the depot directory is specified as "/opt/depot", then all clients must use it as the designated depot directory.
Configuration Issues: Sharing a copy of the opt_depot located on the server also entails sharing a common configuration file, meaning that all directory and filenames used by opt_depot must be constant across the client systems.
Here at Applied Research Laboratories we prefer to use the shared network installation, since it's is less of a hassle to maintain the opt_depot scripts. Thus far we have had no problems stemming from the use of consist ant directory names across our clients, and in fact this type of installation seems to make managing opt_depot a simpler task all around.
Step One: Finding Perl
When the setup program is executed, the first thing it does is search for any versions of perl that may be on the system. If it finds either the 'perl' or 'perl5' command, it will return the directory where it was located.
If perl is not found at all , or if the administrator doesn't want to use the perl version that was found, then setup.sh will prompt the administrator for the absolute pathname of the perl executable.
It's important to remember that opt_depot needs perl 5,0 or above in order to function properly. In addition, the particular location of perl specified by the administrator during setup will be added to opt_depot during the copying process (step six) in the form of a #! line placed at the beginning of each opt_depot script.
Step Two: Entering the Software Base directory
Once the first step of the installation process has been completed, setup.sh will then ask the administrator to enter the software base directory. This directory is where the /bin/lib/man/include/info directories are located. We here at ARL use /opt and if no name is entered then setup.sh will designate /opt as the base directory.
Step Three: Entering the Depot directory
After entering the software base, the administrator will be prompted for the location of the depot directory. Depot may contain physically installed packages and/or symbolic links to packages in the software archives.
For organizational purposes, the default for the depot directory is /opt/depot. We have found that placing the depot directory under the software base makes it easier to manage, but there is no requirement that depot be a sub-directory of the software base.
Step Four: Entering the Log directory
An optional feature of opt_depot is to have a log file created when opt_depot, opt_link and opt_clean are run. The output from these programs will be printed out to files contained the the log directory.
Again, there is no requirement that the log directory be in any particular location relative to the depot or software base directories. At ARL we simply use /logs/opt_depot.
Step Five: Creating a sites file
To effectively manage the depot directory, opt_link needs o know the locations of the package archives that contain packages available for linking into depot. This information is provided by the sites file.
Setup.sh will execute the modify_scripts utility contained in the opt_depot package to create the sites file. Each entry in the file will consist of a label, the location of the package archive, and its relative priority. There must be at least one software archive listed in the sites file for opt_link to function properly.
Step Six: Choosing an installation directory
The final step in the installation process is to specify the directory where the opt_depot scripts will reside. Setup.sh will install the opt_depot scripts in a package style format to this directory, with the executable scripts placed under /bin, man pages placed under /man, and configuration and uti;ity files placed under /etc. The #! line from step one will be added to the scripts at this time.
All Done
At this point opt_depot should be able to run. The administrator may want to consider adding a call to opt_setup to the chron table and should create any .exclude or .priority files that might be needed.