HPUX CDFinfo[4]
CDFinfo(4) CDFinfo(4)
NAME
CDFinfo - CDFinfo file format and rule syntax
DESCRIPTION
Each fileset that is loaded and maintained on a HP-UX cluster server
may contain a CDFinfo file located in /system/fileset_name/CDFinfo.
The CDFinfo file contains instructions on how context-dependent files
and directories in that fileset should be handled by update and sam
(see update(1M) and sam(1M)).
See the WARNINGS section below for issues concerning future support of
the CDFinfo mechanism of cluster maintenance.
Filesets containing files that cannot be shared by every system in an
HP-UX cluster need some way of specifying how these files should be
handled. The CDFinfo file contains rules specifying which files
should be Context-Dependent Files (see cdf(4)).
It is possible to construct a product that does not require the use of
CDFs to operate properly in a clustered environment. The use of
front-end shell scripts that invoke the correct executable is one
example of how to eliminate the need for CDFs. A product that does
not require CDFs to operate are easier to maintain in a multi-vendor
environment, and are less likely to need modification if the cluster
support mechanisms change (see WARNINGS).
The CDFinfo file is used during three different operations on a
clustered system. They are:
o When creating a cluster for the first time (using sam).
o When adding a client (using sam).
o When loading a fileset onto a clustered system (using update).
For each file or directory in a fileset that cannot be shared by all
systems in a cluster (executable files or per-cnode configurable
files, for example), a rule can be specified in the CDFinfo file that
indicates how that file should be handled in each of the three cases
above. Files that can be shared by all cnodes do not need an entry in
the CDFinfo file (text documents and shell scripts are good examples).
Also, files whose path contains a directory that already has a CDFinfo
entry do not need an individual entry, as long as the directory is the
correct type of CDF. Thus, executable files under /bin or /usr/bin do
not need an individual architecture-specific CDF. Likewise, client-
specific files under the /usr/adm directory do not need their own
cnode-specific CDFinfo entry.
The first line of the CDFinfo file must contain the string:
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
# fileset_name
Where fileset_name is the name of the fileset to which the CDFinfo
file belongs.
The rest of the file contains rules that conform to the following
general syntax:
path_name{
createcdf (
action [[; action]...]
)
addcnode (
action [[; action]...]
)
update (
action [[; action]...]
)
}
path_name must beginning with /. Any or all of the createcdf,
addcnode, or update portions of a rule can be specified. A file that
is an architecture CDF does not need to contain the addcnode portion.
The action contained in the createcdf portion of a rule is performed
when sam is used to create a cluster server for the first time. It
can also be used by update if this rule is referenced by a create
action (see the create action for details).
The action contained in the addcnode portion of a rule is performed
when sam is used to add a client to an existing cluster system. It
can also be used by update if this rule is referenced by a create
action (see the create action for details).
The action contained in the update portion of a rule is performed when
update is used to load this fileset onto an existing cluster system.
Only the CDF rules for files that are loaded from the media are
exercised. Therefore there must be a file (or directory) on the media
with the exact name: path_name for that rule to be triggered. This
differs from the createcdf and addcnode portions of rules, which are
all executed when sam creates a cluster or adds a client-node.
Actions
Each action has the syntax:
operator [argument [argument]]
Valid operators are described in the next section. arguments can be
constructed by combining one or more of the following elements (see
specific actions for restrictions):
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
"quoted-string" A double-quoted string (usually a file
path). No substitutions are made between
the quotes.
ARCH When ARCH is specified in an argument, the
string ARCH is replaced by the CDF context
element for the hardware architecture on
which the file is to be used. The
architecture of the file is determined from
the file's magic number (if possible), or
defaults to the appropriate architecture of
the the system (in the case of createcdf or
addcnode rule portions), or to the
architecture of the update media being
loaded (in the case of an update rule
portion). Possible values include HP-PA
(Series 700 and 800) or HP-MC68020 (Series
300 and 400).
Actions that contain ARCH are ignored on a
homogeneous cluster. Currently Series
300/400 servers are defined as homogeneous
(can contain only Series 300/400 cnodes).
Where as Series 700/800 servers are defined
as heterogeneous (can contain Series
300/400 clients). Architecture-specific
CDFs are only created on heterogeneous
cluster servers.
CNODE The string CNODE is replaced by the name of
the client-node being added. CNODE can
only be used in the addcnode portion of a
rule.
LOCALROOT The string LOCALROOT is replaced by the
localroot context element. The localroot
element of a CDF is accessed by the cluster
server. A CDF containing localroot is
usually complemented with the addition of a
remoteroot element.
REMOTEROOT The string REMOTEROOT is replaced by the
remoteroot context element. The remoteroot
element of a CDF is accessed by all non-
server cnodes. A CDF containing remoteroot
is usually complemented with the addition
of a localroot element.
ROOTSERVER The string ROOTSERVER is replaced by the
cnode name of the cluster server.
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
ROOTARCH The string ROOTARCH is replaced by the
architecture string (HP-PA or HP-MC68020)
that corresponds to the cluster server.
Operators
The following operators can be used to make up the rule's action:
save Usage: save destination [alternate]
Example: save ARCH "/etc/newconfig/foo"
The save operator may be used only in the
createcdf portion of a rule, and converts an
existing file or directory (path_name) into a CDF.
In general, the existing file (or directory)
becomes an element of the CDF (as specified by the
destination). If path_name does not exist, the
contents of the file identified by alternate are
copied into the element of the newly created CDF.
The destination argument identifies the name of
the element of the CDF to be created. It can only
be one of: ARCH, LOCALROOT, REMOTEROOT,
ROOTSERVER, or ROOTARCH. The save action
translates directly into the HP-UX command:
makecdf -c destination [-f alternate]
path_name
load Usage: load destination
The load operator can be used only within the
update portion of a rule and is only exercised
when update extracts a file (or directory) called
path_name. If path_name is a regular file, a CDF
is created and the file is loaded as the CDF
element specified by destination. If path_name is
a directory, a CDF is created, and a directory is
created as the CDF element as specified by
destination. When a directory is created as an
architecture-specific CDF both HP-PA and HP-
MC68020 context elements are created, even if one
element will remain empty.
exec Usage: exec "command_path" [arg ...]
Example: exec "/bin/echo" CNODE
">/etc/issue+"/CNODE
The exec operator can be used only in the
createcdf and addcnode portions of a rule. exec
can be used where the required operation is too
complex to be handled by the existing CDF rules,
making it necessary to use an external command to
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
accomplish the desired action. Any number of
arguments can be provided. Use double-quotes for
strings that must not be altered. Any of the
argument specifiers listed previously (CNODE,
ARCH, etc.) can be used as arguments. These
arguments are then passed to command_path when
invoked.
copy Usage: copy [source] destination
Example 1: copy "/etc/newconfig/inittab" CNODE
Example 2: copy ROOTSERVER CNODE
The copy action is used primarily in the addcnode
portion of rules to copy a file (or directory)
into the CDF element of a newly configured client,
but can be used in all rule portions if needed.
In example 1 above, it is used to copy the
configurable file: /etc/newconfig/inittab into the
CNODE element of path_name. In example 2, it is
used to copy the file located from the ROOTSERVER
CDF element into the CNODE element.
When used in the update portion of a rule, the
source is implied to be that of path_name and can
be omitted.
When the copy action is applied to a directory,
only the subdirectory structure is copied; no
regular files are copied. The intent of this is
to support operations such as creating
/usr/spool/cron and its subdirectories for a new
cnode using the cluster server's /usr/spool/cron
directory as a template for what directories
should exist.
symlink The symlink operator is identical to the copy
operator, except that the destination file is
symbolically linked to the source rather than
copied.
move The move operator is identical to the copy
operator, except that the source file is moved to
the destination rather than copied.
remove Usage: remove
The remove operator may be used only in the
createcdf and update portions of a rule. In the
createcdf portion, it is used to specify that the
CDF should be created, but the standalone file
should be removed instead of being copied into a
Hewlett-Packard Company - 5 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
CDF element. This is useful for run-time data a
program can create (such as /etc/ps_data). In the
update portion, it is used to specify that the
file should not be loaded from the media.
create Usage: create path_name
The create operator may be used only in the update
portion of a rule. create is used to trigger the
createcdf and addcnode portions of the rule
associated with path_name. This is the only way
to exercise the createcdf and addcnode rule
portions outside of the initial cluster creation
and cnode addition done by sam.
See WARNINGS below for details on a problem
concerning the create operator.
Because of its complex nature, the create operator
should be avoided if possible.
EXAMPLES
The following example CDFinfo file uses several of the rules and
actions discussed. For a much larger set of examples, refer to
existing CDFinfo files located in /system/*/CDFinfo.
# MY-EXAMPLE
# Make the directory /bin an architecture-specific CDF
# so that files under /bin do not need individual CDF entries.
/bin {
createcdf (
save ARCH
)
update (
load ARCH
)
}
# Make the file /etc/mount an architecture-specific CDF
/etc/mount {
createcdf (
save ARCH
)
update (
load ARCH
)
}
# Make /etc/inittab a CNODE specific CDF, use the new version
# in /etc/newconfig if it doesn't exist, or when adding a client.
Hewlett-Packard Company - 6 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
/etc/inittab {
createcdf (
save ROOTSERVER "/etc/newconfig/inittab"
)
addcnode (
copy "/etc/newconfig/inittab" CNODE
)
}
# Make /etc/issue a CNODE specific CDF, and put the CNODE name
# into the new client's version when adding a cnode.
/etc/issue {
createcdf (
save ROOTSERVER
)
addcnode (
exec "/bin/echo" CNODE ">/etc/issue+"/CNODE
)
}
WARNINGS
The information contained is this manual entry pertains specifically
to HP-UX releases 7.0 through 9.0. The CDFs and CDFinfo files are
proprietary to HP-UX systems and it is likely that future releases
will support new, different, and more sophisticated mechanisms for
file sharing. Therefore products which use the CDFinfo mechanism to
support clustered systems may need to be revised. For this reason, HP
discourages the use of CDFs and CDFinfo files when avoidable.
In earlier versions of update (before HP-UX release 9.0), the create
operator does not exercise the addcnode nor createcdf rule portions if
path_name already exists on the filesystem (either as a CDF or regular
file). update's failure to exercise these rule portions usually
causes only one set of cnode elements to be created (the set of cnodes
belonging to the same architecture as the media loaded for the first
time). This is a problem only on heterogeneous clusters. The
customize script executed by update is usually responsible for adding
the remaining cnode elements.
Some of the less commonly used operators are known to give unexpected
results, especially when applied to filesets that have been relocated
(not loaded relative to / by update). It is suggested that CDFinfo
files use only the basic operators when possible. Try to avoid the
use of the create, symlink, remove, move, and copy operators when
possible.
Because of the complex nature of the CDFinfo file and the processes
that use them, testing is a vital element in creating a product that
can be successfully used in a clustered environment. When testing a
product, be sure to go through the procedures that make use of the
CDFinfo file:
Hewlett-Packard Company - 7 - HP-UX Release 9.0: August 1992
CDFinfo(4) CDFinfo(4)
o With the product already installed on a standalone system, use
sam to create a cluster for the first time.
o With the product already installed on a cluster system, use
sam to add a new client.
o Use update to load and reload a fileset onto a clustered
system. Be sure that all remnants of the fileset (including
empty CDFs) have been removed before testing a fresh load.
o Perform the above testing on both heterogeneous (Series
700/800 systems) and homogeneous (Series 300/400 systems)
cluster servers.
FILES
/system/*/CDFinfo CDFinfo files for installed filesets.
SEE ALSO
fpkg(1M), makecdf(1M), sam(1M), update(1M), cdf(4).
Hewlett-Packard Company - 8 - HP-UX Release 9.0: August 1992