Previous Table of Contents Next

User Access to Applications

Making applications available to users is a major task for system administrators. Most users depend on reliable access to application software to get their jobs done. The demands of creating and maintaining user access to application software can easily consume a quarter or more of system administration time.

You may need to perform any or all of the following tasks to administer user access to applications:

  Acquire software.
  Locate space for the software.
  Install the software on multiple local systems, or on a server.
  Set up user environments, such as paths, links, and environment variables.
  Revise user environments each time the software version changes or new software is added.

Anything that you can do to leverage these tasks will increase productivity.

You can use a variety of creative approaches to managing software access. One existing approach uses the automounter extensively to match up users with the proper binary version of applications. The principal drawback to using only an automounter approach is that it does not manage the environmental setup that most packages require.

Another existing approach uses scripts that are run once on each system to set up the user environment for an application. Subsequently, when the user starts the application, the environment is already properly prepared. A disadvantage to this approach is that it introduces additional command names that users have to learn to prepare for running an application. An additional drawback is that some programs use the same environment variable names as other programs with different values. When users run a script for a specific application but do not start the application until later, other packages that use the same environment variable may be affected. (See “Wrappers and Dot Files” later in this chapter for an example.)

Another approach is to have user .login or .profile files “source” a global configuration file that sets up the user’s environment.

Another approach uses wrappers to manage access to software. Wrappers are tailored application startup scripts. These scripts set up the user’s environment at runtime and start the application. Wrappers perform the setup that you would otherwise have to hard-code in individual users’ dot files.

Using wrappers together with standard application server layouts and simplified user mount and path setups can produce an environment in which you need to do very little, if any, administrative maintenance of the end user environment. Users can have as few as one software access mount and one software access path component.

Most application access at Sun is based on this last approach, which was developed by Sun Information Resources. SunSoft recommends that you consider dedicating servers to provide access to application software over the network, in the manner proposed in the following sections.

NOTE:  A comprehensive description of how to configure and manage application servers is beyond the scope of this book. However, the approaches and examples cited here provide you with a foundation based on sound principles and real-world experience.

Automating Your Application Environment

The information in the following sections provides suggestions for ways that you can automate your application environment. The key technologies and techniques are introduced in Table 12-2 and described in the following sections.

Table 12-2 Key Elements for an Application Server

Element Used to
NFS/automounter Share application file systems across the network; guarantee consistency and integrity with read-only access
Online: DiskSuite™ Permit file systems larger than individual disks; enable a single mount to access a huge distribution
wrappers Remove setup requirements from the end-user environment; provide all users with consistent behavior
symbolic links Allow one executable to have many startup names; permit generic path references to version-named locations; control default application versions
common command directory Make all commands accessible with a single path component
rdist Facilitate replication of file systems across application servers
NIS/NIS+ Facilitate sharing files in a network environment

When you set up an application server, you dedicate a single slice (partition) to contain the applications and wrappers. You create two (or more) directories in the slice. The application directory contains the applications and wrappers, as well as a symbolic link directory that you can use to determine the default version of the application. The common command directory contains symbolic links in the form of command names that link to the wrappers for each application. You can use a product such as SunSoft Online: DiskSuite? to create a large file system that spans more than one slice or disk. When you have installed the application packages, you write a wrapper that sets up the environment for the application. If you want to copy the setup to another server, you can do so by using the rdist command. Refer to “Designing an Application Server” later in this chapter for a detailed description of these tasks.

Previous Table of Contents Next