Software storage objects

A software storage object starts out as a single directory subtree in the /opt hierarchy. This portion of the SSO remains unchanged in the same location throughout its lifetime on the system, providing dependable software for network installations.

To keep the files in the SSO unchanged, custom(ADM) makes copies of files that are expected to change (for example, files that need to be configured differently for different users or programs). custom also links certain files to locations outside the SSO where other programs and users expect to find them. Copying and linking these files is called ``configuring the component to a client''. During a standard installation, custom loads an SSO onto the local system, then configures it to the local system. In more complex installation scenarios, custom can also configure an SSO to one or more ``network filesystem clients'', such as a diskless machine.

Whether a file is copied, linked, or both, depends on whether the file is ``SHARED'' or ``CLIENT'', and whether it is ``PUBLIC'' or ``PRIVATE'':

• A SHARED file is one that clients read, but do not modify. If a file is shared among multiple client machines on the network, it exists only in the original distribution location (/opt). Files such as programs (binaries), drivers, and message catalogs may be SHARED files.

• A CLIENT file is one that clients may need to modify. custom loads the (unchanging) prototype for a component's CLIENT files into /opt. Then, for each client (including the local system), custom copies the files to the subdirectory in /var/opt that corresponds to the component's SSO. Files such as log files and user configuration files may be CLIENT files.

• A PUBLIC file is one that is visible and accessible outside of a component's private SSO. This lets users and outside components access the file by means of links. Files such as user applications and user configuration files may be PUBLIC files.

• A PRIVATE file is one that is not visible outside of a component's SSO. Only programs and scripts belonging to the component are expected to access a PRIVATE file directly, so accessing a PRIVATE file from outside the SSO is not supported. Files such as back-end binaries, data files, and internal configuration files may be PRIVATE files.

So, once configured to a particular client, an SSO has two parts: the /opt part, which is shared, and the /var/opt part, which is specific to a client. These two parts can loosely be called the program part (/opt) and the data part (/var/opt).

For each SSO in a product, a client can locate the program part locally or remotely, and the data part locally or remotely. The remote part of each SSO can be located on a different server. Also, this separation between program and data allows control over the location of data that must be backed up regularly or preserved during an upgrade.

Once an SSO is configured into a /opt part and a /var/opt part, links make every PUBLIC file's true location transparent to the system.

Both SHARED and CLIENT files may be either PRIVATE or PUBLIC. There is no mutual exclusivity between these attributes. The following table shows the four possible combinations:

	SHARED	CLIENT
PRIVATE	These files remain under /opt. They are not linked to an external directory.	These files are copied to /var/opt for each client. They are not linked to an external directory.
PUBLIC	These files remain in /opt and are linked to an external directory.	These files are copied to /var/opt for each client and are linked to an external directory.

See also:

• ``Product file locations''