export location for scripts run automatically at system startup
and shutdown; obsolete, exists for XENIX compatibility
rc0.d, rc2.d, rc3.d, shutdown.d
export location for scripts run automatically at system startup
and shutdown; see
init(M)
/home
conventional name for second filesystem which contains users'
home directories; may be mounted from a central server; some
system administrators may choose to set this up as /u
/ibin
export location for binaries needed to install the system
SSO component root containing public (exported) and private
read-only files
P
root of directory hierarchy for
product database information
/shlib
export location for public static shared libraries
/stand
the boot filesystem, which typically contains the /boot
executable, boot standalone programs, and bootable kernels; see
boot(HW)
/tcb
storage for trusted computing base
/tmp
temporary storage, periodically purged
/tmp_mnt
default storage for temporary mount points used by the automounter;
see
automount(NADM)
/u
alternative name for /home
/usr/
traditional export location for public user hierarchy
bin
traditional export location for public executable programs
include
traditional export location for public program header files
lib
traditional export location for static and dynamic shared libraries
spool
traditional export location for delayed execution files used by system services
such as cron, printing, and mail
tmp
temporary storage, periodically purged
/var/
root of directory hierarchy for non-shared (client-specific) data
opt
root of directory hierarchy for
writable system data such as configuration information
opt/K
root of directory hierarchy for the non-shared (client-specific)
writable portions of component SSOs
opt/K/VendorCode/ComponentCode/ComponentVersion
root of directory hierarchy containing copies of
public (exported) and private writable files
belonging to a component's SSO
Software storage objects (SSOs)
An SSO starts out as a single directory subtree
in the /opt hierarchy.
The pristine state of the SSO remains
in the same location throughout its lifetime on the system, and can be used
as a clean source for network installations later.
Each time a software storage object is configured to a particular
client, it expands by copying some files and creating
links to other files.
Some files are both copied and linked.
(Throughout this discussion, client refers to either the local system
or a network filesystem client such as a diskless machine.)
How a file is accessed after its SSO is configured to a client
depends on whether the file is shared or non-shared,
and whether it is public or private.
A shared file is one that a client reads, but does not modify.
If a file is shared among multiple client machines on the
network, it exists only in the original distribution
location (/opt).
A non-shared file is specific to an individual client. The client
can modify this file without affecting any other client's copy.
During the ``attach'' phase of installation,
non-shared files are copied from a private directory under
the SSO's /opt hierarchy to the
appropriate /var/opt subdirectory.
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 symbolic links.
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.
Once configured to a particular client, an SSO has two parts:
a /opt part which is shared
a /var/opt part which is specific to a client
These two parts can be called the program
part (/opt) and the data part (/var/opt).
This separation between program and data allows control over the
location of data that must be backed up regularly or preserved during an
upgrade.
For each SSO in a product, a client can locate
the program part locally or remotely, and the data part
locally or remotely.
Also, the remote part of each storage object can be located
on a different server.
Once an SSO is configured into a /opt part and
a /var/opt part, the ``export'' phase of installation
makes public those read-only and writable files which are
not private to the SSO.
Symbolic links are created from the traditional file
locations to real files in the /opt and /var/opt
hierarchies. The symbolic links allow every public
file's true location to be made transparent to the system.
See
``Hiding the details of SSO implementation''
for more information.
Both shared and non-shared files may be either private or public.
There is no mutual exclusivity between these attributes.
The following four combinations are possible:
shared/private
Files remain under /opt.
They are not linked to an external directory.
non-shared/private
Files are copied to /var/opt for each client.
They are not linked to an external directory.
shared/public
Files remain in /opt and are
linked to an external directory.
non-shared/public
Files are copied to /var/opt
for each client and are linked to an external directory.
Product file locations
The files in an SSO are stored in the subtree located under the
directory:
/opt/K/VendorCode/ComponentCode/ComponentVersion
This directory is called a component's SSO root.
For example, the SSO root for the SCO X server component,
version 5.2.0d, is /opt/K/SCO/XServer/5.2.0d.
Corresponding to the SSO itself is a directory
in /var in the client's local file space.
This is the hierarchy to which all non-shared files are copied.
The pathname to the directory in /var is:
The Link Kit hierarchy contains the utilities, source and object files
that your system needs to create a new version of the kernel. Rebuilding
the kernel is necessary when configuration changes are made such as
changing the value of a kernel parameter, or adding a new device driver.
Many files and some directories in the Link Kit are symbolic links into
the Unix component SSO. This can produce some
unexpected effects if you use relative pathnames to access different parts
of the Link Kit. See
``Hiding the details of SSO implementation''
for more information.
If you are writing shell scripts, you can use
ssoPathMap(ADM)
to return the path to the root of an SSO.
Other Link Kit files under /var/opt are symbolic links to
the Unix component SSO under /opt.
Such files include utilities in /etc/conf/cf.d,
most Driver.o and stubs.c files under
/etc/conf/pack.d/*,
kernel object files in /etc/conf/pack.d/kernel, and
some driver configuration scripts. These files are shared/read-only
and should not normally be modified.
If you need to make a temporary copy of the Link Kit for test purposes,
use the command cpio -pLd. This will
replace symbolic links with real files in the copy.
(Do not use the
tar(C)
command as its inherent limitations make it unsuitable for making
a copy of the Link Kit.)
Copy the Link Kit to a temporary directory hierarchy, and
then set and export the environment variable
ROOT so that the Link Kit utilities will
work with the directory hierarchy having /tmp/new_root as its
root. For example, the following
commands create a copy of the Link Kit
under /tmp/new_root/etc/conf:
Software storage objects (SSOs) preserve the
traditional directory structure and filenames
by using symbolic links to point to the real files
which are maintained in the /var and /opt/var
directory hierarchies.
The versions of the
cd(C)
and
pwd(C)
commands built into the Bourne, and C shells
use physical pathnames by default.
Use the -L option to
cd to traverse the traditional directory structure
while hiding the details of the implementation
of SSOs.
Similarly, the -L option to
pwd displays the traditional
directory structure.
The default behavior of these shells can be changed to use
logical pathnames by specifying the -L option to
sh(C),
or by setting the cdlogical variable for
csh(C).
The versions of cd and pwd
built into the Korn shell and /bin/posix/sh
(the XPG4-compliant version of
ksh(C))
use logical pathnames (assume the -L option)
by default.
The /bin/cd and /bin/pwd utilities
only understand physical pathnames.
The -l option to
ls(C)
displays symbolic links and the files to which they point.
However, this lists the details of the symbolic link's inode
rather than the inode details of the file to which it points.
When listing files, use the
l(C)
command or the -Ws option to
ls
to hide the implementation of SSOs. If a file is a symbolic link,
an ``@'' is appended to its filename and the inode details of the
file ultimately pointed to are displayed. Specify the -Wv option
if you want to display all filenames in a chain of symbolic links.
Warning
Note the following when making changes to files within SSOs:
If a file is not exported out of the SSO, it is private to the component
and may or may not be included in future releases of the product.
It is not a public file.
In general, you should not access these files from your own scripts or
programs.
Any modification that you make to a file under the
/opt/K/VendorCode/ComponentCode/ComponentVersion
hierarchy affects more than just the local host.
The change will be carried along by custom to any other
machines installed from the changed host, and it will also affect
diskless and dataless clients of this machine.
Make changes to such files with caution. You can detect such changes
using the custom verification function (for more information, see
custom(ADM)).
Changing directories using relative pathnames
(especially from within scripts)
may not always place you in the directory you expect.