The actual /opt directory on a typical workstation
contains three things:
/opt directory, and
The link to the "master" opt directory usually references
an NFS-mounted location on the "master" opt network node.
However, any means for making the directory visible via the filesystem
should work, not just NFS. Thus, this scheme will work on an Apollo
Domain/OS network (we've done it) and should work equally well on AFS,
DFS, EFS, SMBFS, or any other connection mechanisms.
The application links are normally created and maintained using the repln script. They are pretty
tedious to manipulate by hand, although it can be done in a pinch.
The "master" link can be changed in an instant to a different machine. This might be required for any of several reasons, including
opt just won't cut it any
more!),
opt node,
opt directory are
present in the new one. If this is an issue, it is normally easier to
simply delete all the application links and then re-create them using
the repln script once the new
master link is established.
This structure can also apply to the master node--it can be a "client"
of its own installation. If the master opt directory is
actually /opt on the master node, then no "mstr" link
need be created. The links of the form
appname ---> pkg/appname-version
or
appname ---> site/appname-version
will be in the correct place already. If the opt
directory is in a different location than /opt (such as
is the case in our diagrams, where it lives in
/_c/opt.10) then the actual /opt directory
on the master node can be built to look just like a workstation's
/opt. For our example, the master node's
/opt/mstr link has the value /_c/opt.10
instead of an NFS pathname.