Using a Common Command Directory

You want to create symbolic links for all application command names in the /usr/apps/exe directory. When you do so, users can access all of the software in the distribution with a single, unchanging path component.

If you choose to have a common command directory for a parallel hierarchy, as mentioned previously, two path components are sufficient to access the entire distribution.

The command names are symbolic links that point to the location of the wrapper for their application. For example, if the package FooTool 2.0 has the commands foo and bar, create these names as symbolic links in /usr/apps/exe, as follows:

$ cd /usr/apps/exe
$ /usr/bin/ln -s /usr/apps/pkgs/footool/dist/wrapper foo
$ /usr/bin/ln -s /usr/apps/pkgs/footool/dist/wrapper bar
$ ls -l foo bar
lrwxrwxrwx   1 nobody   nobody        35 Apr  6  1992 foo ->
                         /usr/apps/pkgs/footool/dist/wrapper
lrwxrwxrwx   1 nobody   nobody        35 Apr  6  1992 bar ->
                         /usr/apps/pkgs/footool/dist/wrapper

Notice that the link destinations refer to the generic directory name link, footool, rather than explicitly to the footool,v2.0 directory. Use the generic directory name link for each package in this way to determine the version of the package to which the commands are connected. The users start the default version of the software, and you can change the default version simply by changing the link that determines it.

You could link the command names via the specific version-named directory instead, but you would find that changing from one version to another, when that time inevitably arrives, requires more work and more exposure. This extra work might not be obvious when packages have only one or two commands, but some applications have many. FrameMaker, for instance, has more than 80 commands!

Setting User Configurations

The following sections describe what you need to do to set up the user environment to access files on the application server.

Mount Points

In a general implementation, each user system needs to have a mount point directory; for example, /usr/apps.

Mounts

You can mount files from an application server when you use NFS. You can mount files either by editing the /etc/vfstab or by using the automounter.

If you use the /etc/vfstab file, edit it on each user’s system and add a line that looks like the following:

#device   device    mount    FS     fsck    mount     mount
#to mount  to fsck  point   type    pass    at boot  options
#
server-name:/usr/apps - /usr/apps  nfs   -     yes      ro

For example, to mount from an application server named oak, become superuser and add the following line to the user’s /etc/vfstab file:

oak:/usr/apps - /usr/apps nfs  -  yes  ro

Refer to Part 3 of this book for information about setting up the automounter.

Path

Each user typically needs either one or two path components to access applications, depending on whether you implement a parallel hierarchy. The name of the second component depends on the naming scheme applied to the parallel hierarchy. Suppose the path components are as follows:

/usr/apps/exe
/usr/apps/local/exe

The order in which you put the directories in the path is up to you. If you have applications that share the same name in both directories, you may want priority applied to either the global or the local distribution. The placement in the path relative to the standard OS directories is significant only if you expect to encounter name conflicts with commands in those locations.

A path for Solaris 2.x users could conceivably be as simple as the following:

/usr/openwin/bin /usr/bin /usr/sbin /usr/apps/exe /usr/apps/local/exe