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 CDF s 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 CDF s. A product that does not require CDF s 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:
• When creating a cluster for the first time (using sam).
• When adding a client (using sam).
• 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:
# 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):
"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 CDF s 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.
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 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 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.
/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 CDF s 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 CDF s 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:
• With the product already installed on a standalone system, use sam to create a cluster for the first time.
• With the product already installed on a cluster system, use sam to add a new client.
• Use update to load and reload a fileset onto a clustered system. Be sure that all remnants of the fileset (including empty CDF s) have been removed before testing a fresh load.
• 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 — HP-UX Release 9.0: August 1992