IS&T Software Release locker configuration guidelines

Unlike lockers maintained by some other groups (such as the sipb, infoagents and gnu lockers), most lockers maintained by IS&T Software Release generally don't contain multiple, unrelated applications, but usually only one (or at most a small functionally-related application group). For the software we maintain, we generally find it easier to work this way, particularly for applications where we need to keep multiple version running concurrently. To make life easier for locker maintainers and users, we have also adopted some specific locker configuration guidelines. These lockers are found under /afs/athena/software in the AFS hierarchy. Some of the major lockers currently set up in this configuration include:

• acro
• applix
• arcinfo
• arcview
• autocad
• frame
• freewrl
• hotmetal
• java
• maple
• math
• matlab
• ooffice
• ptc
• sas
• soffice
• splus
• stata
• tecplot
• xess

Here is a description from a user's point of view, using splus as an example:

Doing add splus adds a "small" base locker which mounts below /mit/splus. The application itself is not in this locker, but its appropriate bin directory (such as /mit/splus/arch/sun4x_59/bin) contains a "generic" startup script (or more precisely, a link to a platform-independent script in /mit/splus/arch/share/bin) called splus that does two main things: 1. it attaches another version locker actually containing the software, and 2. it invokes another script (of same name, splus) in the appropriate bin directory of the version locker, which actually invokes the application. We generally write such scripts in Perl.

In our example, the version locker might be splus_v3.3 and you would see it mounted below /mit/splus_v3.3 after you invoke and run the startup script.. The naming convention for the version-specific lockers will follow this pattern, i.e. <software>_v<version>, where <version> will be a version descriptor. The "generic" script is "smart enough" to know that you normally will want to run the latest version available, and that there might be version skew across platforms. Hence, if you are on a Sun, it might attach splus_v3.3 and invoke /mit/splus_v3.3/arch/sun4x_58/bin/splus (running release 3.3), but on Linux it might use splus_v3.4.

The startup script can also take a local command-line option switch to explicitly specify a version, i.e. if you want to run release 3.2 on a Sun even though 3.3 is available, you could do add splus followed by splus -ver 3.2. If the application also uses its own command-line switches, they should follow the "version-selection" one just described (i.e., put our local version-selection switch in the first position if you use it). If a particular version/platform combination is not available, you should get an informative error message to that effect. In general, the currently recommended, default version is the one with the simplest launch command (i.e. add splus; splus). We generally put a symbolic link at the top level of the base locker to the various version lockers currently available, so you can easily see what versions there are, and one named current which points to the current default version. By using AFS @sys links, current might point to different version lockers on different platforms.

Another way to run applications is to attach the version locker directly, bypassing the base locker- for the Sun example above, this would be done by typing add splus_v3.2 followed by splus (the version selecting command-line switch is now unnecessary since you have already specified the version implicitly in the add command). We do not generally recommend that you launch this way- one reason is that the base locker script sometimes sends you operational messages about the software that you would miss if you don't use it by attaching the version locker directly.

One of the advantages of this system is that it allows overlapping versions during a transition, and at least the last prior version will most likely be around for a couple of months after the new one is installed. We also have flexibility in setting the default to either the "new" or the "old " version. In some cases there may be reasons for keeping around older versions more or less indefinitely, and these may be explicitly listed in What Runs Where.

The use of separate local mount points (such as /mit/splus_v3.2 and /mit/splus_v3.3) also allows users to access different versions of an application at the same time, or easy switching back and forth which otherwise would be quite cumbersome. This may sometimes be useful for comparison purposes.

Our launch scripts also incorporate a system for sending messages to users, either "once only" or "every launch". The former requires remembering that a user has seen a particular message. We do this with a "magic cookie" system that writes information to a file .sw_messages in each user's home directory. As a "dotfile" this is normally invisible on ordinary directory listings but you should see it if you type ls -a in your home directory. If this file is deleted by intent or by accident, you will get repeats of any messages currently being sent, even if you have seen them before. Normally you wouldn't want to delete it- it shouldn't get bigger than a few hundred bytes or so.

We're also adopting standard locker documentation conventions: a file README.athena at the top locker level has some important basic information; if we have written a local Web page it will be in file www/home.html, in subdirectory www below the top locker level. Many of our lockers have a README.config file with configuration and setup information, although this is mostly of use to locker maintainers.