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.