Installing Third-Party Applications
John Caywood As UNIX moves into mainstream computing, third-party applications come with it. As administrator, you're asked not only to install new applications, but to maintain them. Here are some tips to help. Inappropriate Instructions Installation instructions for major third-party applications typically require: 1. that you install them in /usr. 2. that you edit your .cshrc or .profile files to modify your PATH variable, and to add a MY_PACKAGE_ROOT to your environment. Some want even more. These instructions are inappropriate because: 1. /usr is often overwritten by operating system upgrades. If you install a package into /usr, you may have to either reinstall the package or restore it from dump tape after an OS upgrade. Moreover, /usr is the 2nd-hardest partition to enlarge (/ being the worst). Eventually you're going to run out of space in /usr. 2. modifying .cshrc or .profile for everyone on the system is not a trivial task when you've got 20, 50, 500, or more users. Whether you do it yourself or leave some of it to users, it will take time to set up and more time to maintain. Unsatisfactory Alternatives Symlinks are a good idea for you -- but not for your employer. Yes, you can symlink the package directory, and if it does get overwritten at upgrade, it's easy enough to recreate the symlinks. Of course, if you get ill, die, or find another job, tracing all those links throughout all of the file systems is going to be a pain for somebody. Furthermore, symlinks won't help with the environment and path modifications that every user on the system needs. You could put the package in a separate partition, and mount it on /usr. However, you get only so many partitions on a hard disk, and it's easy to run out of possible partitions as one package after another is purchased. Next point -- modifying everyone's .cshrc or .profile. There are lots of ways to do this. The Better Way Put the package where you want it, and create a shell script in /usr/local/bin or wherever you put local software. If this directory is already in everyone's path, the installation is complete. The shell script is in Listing 1. /bin/sh is very portable --it's always there: that is, it will also be there after the next operating system upgrade. Setting the package directory in this script means that if for any reason you have to move the directory, there's only one file to edit. All other files are automatically up-to-date. You fix just one file, not hundreds, and your users do nothing at all. Another advantage is that you test the script, fix misspellings, and so forth. There are no questions from users who misspelled MY_PACKAGE_ROOT and can't understand why it won't work. If at the next release of this application other variables are needed, or if you change from a node-locked to a floating license and a new environment variable has to be set, you make the change once, in this script. Your users make no changes. The exec statement is very efficient. The shell passes control to the new program using the old pid. execing this way doesn't take up extra space in the process table. And, /bin/sh is usually small, smaller than csh or ksh, and is often in the buffer cache anyway. Multiple Programs If the package includes several programs, Listing 2 shows an easy way to deal with this. Either symlink or hard link the other programs to /usr/local/bin/package. `basename $0' strips off all but the final part of the name. The case statement is built into the shell, so no extra processes are needed. You can even rationalize the name this way: instead of having to type SuperDataBase, you can name the script super, or db or anything that's easy to type and easy for users to remember. If you're in a GUI environment, have your menu exec this script, too, instead of adding environment variables to the menu item. If your users are already used to running a specific program by a well-known name, by all means keep that name. Or, if the user manuals cite a specific spelling, keep that, too, at least with a link. (I didn't do this on one package I installed, and every new hire asks me about it.) If you don't have a local binary directory, consider starting one. It should appear first in a user's path. The next time a user logs in, your script will be executed instead of the original binary. When you're confident that everyone uses your script, you can move the package anywhere you want. Multiple Startups Listing 3 shows how to deal with a package that can be run in several modes. You can find a name that is meaningful to the way your users will execute the package, then save them typing and scribbling notes to post on their terminals to get to different behaviors. Remember to create links to the script under all names by which it may be invoked. You may want to write a script to create all of the links in case of a catastrophe. The shell script approach is so simple, efficient, and effective that I've often wondered why the third-party vendors haven't included such a script in their setup or install programs. There is no better way to ensure that all users have the right environment for execution of the program. I've used this approach again and again under SunOS 3.5 through 4.1.3, and I plan to use it to simplify my migration to Solaris 2.x. The principle is independent of the UNIX flavor you're running. Try this approach the next time you install a package.
About the Author
John Caywood received B.S. and M.S. degrees in computer science from Old Dominion University, Norfolk, Va., and he taught computer science there for three years. He is currently employed by Computer Sciences Corporation under contract to NASA Langley Research Center, where he administers a network of Sun workstations and Macintoshes in the Technical Editing branch. He can be reached at J.S.Caywood@LaRC.NASA.GOV.
|