Consolidating Startup Shell Scripts

Russ Hill

Most large UNIX sites use NFS to a main NFS server, especially for home directories, which makes accessibility to user files as well as backups easier. If one workstation goes down, the user can just move to another workstation and continue working. With some large companies, however, different groups use different types and classes of workstations, and each group has a different type of UNIX. These different systems still have the ability to use NFS and keep their same user home directories, but some sites choose to use different home directories for each type of UNIX system.

This setup means users have to transfer files back and forth between their different home directories. To solve this problem, you need a clean, easy way of changing the users' environment to the different UNIX systems at login. A consolidated startup shell environment is just the answer.

In most cases, it's easier to have users' home directories in one place. Then, no matter what UNIX system they are running on, users always get the same home directory. Users can just make subdirectories within their own home directory for the different systems that they use. For programmers especially, having one directory tree containing all their code is much easier than having their files scattered across multiple systems. With one directory tree, users can make directories like ~/Solaris, or ~/hp and keep all their code compiled under one tree. Also, administering one home directory per user is much easier than dealing with multiple home directories on many different systems, so creating a consolidated startup shell environment makes sense.

Creating Startup Files

Writing startup files from scratch can be quite difficult, so you might want to start with the standard system startup files that come with your system and add any good features from your current users' startup files. Then you can go back and rewrite this master set of startup files into something usable. By incorporating features from many sources, you can quickly create very robust startup shell scripts that can be used by many people. This process is much easier than creating your own startup files from scratch. Next, you will need to combine the startup files from many different types of UNIX systems into one master set of files.

Combining Startup Files

Combining startup files from different types of UNIX systems is very easy, but is usually only beneficial if the systems are configured in a similar manner. Fortunately, a good portion of the startup shell scripts are identical across all UNIX systems; therefore, all you need to do is handle the minor differences. The DISPLAY variables and PS1 values rarely change, however, there are a few places where you want system differences. These differences are in three areas: aliases, paths, and the graphical user interface (GUI) startup.

For example, in the alias section you would want the df command to be bdf on HP-UX and df -k on Solaris. The PATH statement on HP-UX needs to include /usr/bin/X11; whereas, Solaris should include /usr/openwin/bin. The same is true of the GUI startup with HPVue, Open Windows, and Motif. These are usually the major differences; however, your site may include others.

To distinguish these differences, I created a machine environment variable by using the command: uname -s in the .profile. This tells the type of UNIX system, and all differences are found from this variable. This variable could have been chosen in other ways. For example, you could use a part of the system name. If all your Suns begin with sun, you could cut this from the hostname. Or, you may have different releases of HP-UX that you want to have different user environments, depending on the release number. In that case, you could use a release environment variable, uname -r, also.

Distributing New Startup Files

To distribute the new startup files, you should proceed slowly, especially if users have been using the same startup files for a while. The best way is just to give out the new startup files to new users and let the features of the startup files speak for themselves. Let users replace their own startup files with a simple shell script that will save their original files to a backup and then overlay their startup files. With a command like this, users can replace startup files whenever they need to. The system administrator need not help individual users write their own customized startup files.

User Changes

The startup files in the users' home directory should be writable by users, so they can make changes as they desire; however, individual users should never make significant changes to the startup files. Mainly users should only comment and uncomment lines in the startup files. If users are making significant changes, then you need to add a lot more features to the startup files. After users have been using the new files for about 6 months, you can review what changes were made and incorporate the good ideas into the master startup files, so that all the users can have access to these new features.

Startup Shell Scripts

Consolidating startup shell scripts into a master set of files will help you easily centralize user directories. The startup shell scripts should to be enhanced enough to configure the users' environment for the system that they are logged into and commented enough so that the user understands each part of the file. This allows users to move between UNIX systems, while still keeping their same environment and home directory. I have included a combined Korn shell environment .profile (Listing 1) and .kshrc (Listing 2) for HP, Solaris, and AIX systems to illustrate this idea.

About the Author

Russ Hill is a UNIX consultant specializing in Internet firewalls and large-scale UNIX sites and can be reached at rhill@nbsi.com.