Surviving the User Maintenance Jungle

Carolyn Conner

One of the biggest time consumers of system administration is user maintenance. This is especially true if you are responsible for several UNIX systems, each with independent home directories and hundreds of users, but do not have one of the sophisticated commercial system management packages installed. User maintenance consists mainly of adding, modifying, and deleting user accounts from the system, as well as maintaining user startup scripts. Just keeping up with the demand for user access can be overwhelming. Keeping the startup scripts up to date further complicates the issue.

The constant change of software usually requires startup script environmental variable changes. Then, even though most users need the same basic environmental settings, they also need the ability to change and customize their own startup scripts, thus increasing the chance for script corruption. After a startup script becomes corrupted, the sys admin must recreate it, at least to the point where users can continue to do their job.

The solution for this demanding role is to get organized, plan, keep things simple, and delegate the appropriate tasks. The easiest step is to keep skeletons of all of the basic startup scripts in one location such as /etc/skel, so that they can be easily located and modified. If possible, multiple UNIX systems can share the same skel directory by NFS mounting it on the other machines. If you are working in a heterogeneous environment with several variations of UNIX, you will also need to factor platform-specific considerations into your overall user maintenance plan. The scenario outlined here borrows from the user administration structure of Solaris 2.x, but can easily be modified to fit your needs. The underlying logic of this plan is to centralize all of the startup scripts and then copy what is necessary for individual users to their respective home directories as accounts are created or updated.

Make List, Check Twice

The first step is to make a list of the UNIX variations that exist in your user environment and consider the login process flow of each supported OS. For example, some variations of UNIX will process the contents of /etc/profile or /etc/login (depending on the user's shell) before running initialization scripts in the user's home directory. If you are supporting such operating systems, consider how this will affect your plan for imposing system-wide environmental controls on all users.

The second step is to consider locally installed applications and group the required environmental variables in files according to software product. This eases maintenance when software variables change, because the changes are all made in the specific software product file (i.e., all Sybase variables are in one file, all Syncsort variables are in another file, etc.). All of the miscellaneous variables that are not software product specific can be kept in a "base" startup script.

Figure 1 shows examples of such software product files. The only reason the software product files begin with a dot is so they will sort to the top of the list when viewed. Because all shells do not have the same coding requirements, there must be a separate startup script for each software product for that shell (i.e., files starting with cshrc and login are for C shell, and those with profile are for Bourne and Korn shells). The examples in Figure 1 are organized by shell. An alternative format would be application.shell, which would also give the application priority in the listing sort.

Listing 1 is an example of a Sybase product startup script. All of the environment variables necessary to access a particular Sybase system are located in this script. With each upgrade to the Sybase system, any changes to the environment variables are made in this one script.

After you finish creating your plan and the scripts needed to implement it, do not forget to review everything in detail. These files will be the core of your user's operating environment, so you need to verify that all of the pieces fit and work properly. Making the lists will be of no avail if you fail to "check them twice."

User Empowerment

The third step is to set the proper ownership and permissions for the skel files. These need to be set so that each user has the ability to modify his/her own startup script without affecting anyone else. Only individuals with root authority should be able to modify the skel files.

Under Solaris, the group sysadmin is created for the purpose of distributing system administration tasks. In the scenario outlined here, the sysadmin group is responsible for assigning startup scripts to users, and file permissions are set so that everyone else can read and execute the scripts. All members of the sysadmin group do not need root access. If your environment suggests that all members of the sysadmin group be able to modify the skel files, you can set the group permissions to include write permissions. The important point to remember is to limit the number of people who have write access. Strictly limiting the number of individuals who can modify the skel files, and strictly enforcing a policy of properly commenting any modifications to those files, makes startup script problem resolution easier. It also ensures a starting place for rebuilding in the event that a user's individual startup script becomes corrupted and must be recreated. You may also want to keep a separate archive of your skel directory, so that files corrupted by junior administrators can be easily restored.

An important aspect of this overall plan is the proper utilization of groups within your environment. The primary group to which a user belongs determines which startup profile they receive. These group assignments should be based on the existing business divisions of your company. In this example, as with the software product group files, the only users able to maintain these scripts must have root access. Only users in the cogrp group have the ability to read and execute them, since these scripts are applicable to only that group. This permission setup is illustrated below.

# ls -al /etc/skel/cogrp*
-rwxr-x---     root     cogrp     cogrp.profile
cogrp:
drwxr-x---     root     cogrp
-rwxr-x---     root     cogrp     local.profile
-rwxr-x---     root     cogrp     local.login
-rwxr-x---     root     cogrp     local.cshrc

When a user who belongs to the cogrp is added to the system, the scripts contained in the directory /etc/skel/cogrp are copied into the user's /home directory. In this case, three scripts are copied, one for the bourne and Korn shells and two for the C shell. For example, the local.profile points to /etc/skel/cogrp.profile, which contains all of the different software product files in bourne or ksh scripts (Listing 2).

Smoke and Mirrors

When these startup scripts are copied into each user's home directory, their permissions and ownership are set so that each user is able to modify his or her startup scripts. If an individual startup script becomes corrupted, the /etc/skel/cogrp files can be copied back into the user's /home directory to use as a starting point. The /etc/skel/cogrp/local.profile, local.login, and local.cshrc scripts should not need to be changed since they are only pointers to other files. See Listing 3 for examples of bourne/Korn and C shell startup scripts. Note that the strategy of these scripts is for the user's files to simply "source" the central files prior to any modifications the user has made. C shell scripts use the keyword "source" for this purpose, whereas Bourne shell and Korn shell scripts use the dot-space-filename construct for that purpose. This smoke and mirrors approach not only makes your life simpler, but it also safeguards the central, group-wide functionality.

The script in Listing 3 sources various software product files and should change only if the cogrp group needs access to a new software product file or if one is removed from access. The application-specific environmental variables are changed within each software product file.

Every Bourne or Korn shell user receives the /etc/skel/.profile.base similar to that shown in Listing 4. This sets the basic environmental variables that everyone needs regardless of the software product mix. Similar scripts are provided for the C shell.

The rest of the software product environmental scripts, for example, Syncsort in Listing 5, build on this base. All previously set PATHs are appended to the next software product's PATH.

Finally, in Listing 6, the /etc/skel/.profile.pathend finalizes the PATH settings that have been added by each software product script.

Delegate

Once the startup script maintenance is under control, much of user administration involves doing the same routine tasks over and over. The next logical step is to move the function of user maintenance to a non-root, less technical group of users, thereby freeing the system administrator for more critical tasks. This can all be accomplished with some training and minimal supervision.

To access the user maintenance GUI in SUN Solaris, the persons responsible must belong to the sysadmin group. This is also the reason that the software product files belong to the sysadmin group as illustrated above. Members of the sysadmin group assign startup scripts to users, but they cannot modify these scripts. In this user maintenance scheme, modification can only be done by persons with root authority.

Usually, there are other routine user maintenance duties that must be done by persons with root authority, but this restriction can be overcome by setting up root crons and scripts to perform these standard functions. The creation of these crons and scripts is well worth the time, especially if the user maintenance is being done by a non-root user.

Platform Tools

Different versions of UNIX have their own set of administrative tools for adding users, managing hosts, and so forth. Under Solaris, for example, the admintool utility can be used for this purpose. As new users are added to the system using admintool, a group of startup scripts is copied to each new user's home directory. In the examples above, the startup scripts are named local.profile, local.login, and local.cshrc. These invalid names are retained after the scripts are copied into a new user's home directory. The startup scripts will not be executed on login until they are renamed to the proper names, that is, .profile, .login, or .cshrc. Renaming these startup scripts must be done by a person with root authority, because admintool sets the ownership to the designated userid being created. That defeats our purpose of off-loading system administrators who have root authority. To get around this obstacle, I created the rename script shown in Listing 7. At various times during the day, a root cron job can be scheduled to execute the rename script, which renames the startup scripts to the correct names.

Renaming the startup scripts is an extra step that can be bypassed by naming the skeleton scripts correctly in the skel directory. Then, as soon as the scripts are copied to the user's home directory by admintool, they are ready to use. The admintool interface also allows you to specify the skeleton directory to be used in setting up the user's home directory. Thus, to set up a user in a special group, such as the cogrp group discussed earlier, you simply specify the appropriate group skeleton directory (/etc/skel/cogrp to follow our example).

Implementation

The procedures and startup scripts shown here have ample room for improvement. For example, in a heterogenous environment in which a user has access to multiple hosts (each with a different version of UNIX) but has a single, NFS-mounted home directory, you might want to improve the startup scripts by making them operating system sensitive. Such modifications could establish different sets of environmental variables based on the host operating system. The examples shown here will get you started in the right direction, however.

About the Author

Carolyn Conner, previously a mainframe systems programmer, is a two-year veteran UNIX administrator for Diamond Shamrock, a refining and marketing company. She can be reached at carolyn_conner@diasham.com.