![]() |
![]() |
| ||
Chapter 28Creating Custom Rule and Probe Keywords (Tasks)This chapter provides information and procedures for creating your own custom rule and probe keywords. Probe KeywordsTo understand what a probe keyword is, you first need to recall what a rule keyword is. A rule keyword is a predefined lexical unit or word that describes a general system attribute, such as host name, hostname, or memory size, memsize. Rule keywords and the values that are associated with them enable you to match a system that has the same attribute to a profile. This match of a system's attributes defines how the Solaris software is to be installed on each system in the group. Custom JumpStart environment variables, which you use in begin and finish scripts, are set on demand. For example, information about which operating system is already installed on a system is only available in SI_INSTALLED after the installed rule keyword is used. In some situations, you might need to extract the same information in a begin or finish script for a purpose other than to match a system and run a profile. Probe keywords provide the solution. Probe keywords extract attribute information and remove the need for you to set up a matching condition and run a profile. For a list of probe keywords and values, see Probe Keywords and Values. Creating a custom_probes FileIf the rule and probe keywords that are described in Rule Keywords and Values and Probe Keywords and Values are not precise enough for your needs, you can define your own custom rule or probe keywords by creating a custom_probes file. The custom_probes file is a Bourne shell script that contains two types of functions. You must save the custom_probes file in the same JumpStart directory where you saved the rules file. The two types of functions that you can define in a custom_probes file are as follows:
Syntax of the custom_probes FileThe custom_probes file can contain any valid Bourne shell command, variable, or algorithm. Note - You can define probe and comparison functions that require a single argument in the custom_probes file. When you use the corresponding custom probe keyword in the rules file, the argument after the keyword is interpreted (as $1). When you use the corresponding custom rule keyword in the rules file, the argument is interpreted as starting after the keyword and ending before the next && or begin script, whichever comes first. The custom_probes file must meet the following requirements:
To improve clarity and organization, define all probe functions first, at the top of the file, followed by all comparison functions. Syntax of Function Names in custom_probesThe name of a probe function must begin with probe_. The name of a comparison function must begin with cmp_. Functions that begin with probe_ define new probe keywords. For example, the function probe_tcx defines the new probe keyword tcx. Functions that begin with cmp_ define new rule keywords. For example, cmp_tcx defines the new rule keyword tcx.
|
#!/bin/sh
#
# custom_probe script to test for the presence of a TCX graphics card.
#
#
# PROBE FUNCTIONS
#
probe_tcx() {
SI_TCX=`modinfo | grep tcx | nawk '{print $6}'`
export SI_TCX
}
#
# COMPARISON FUNCTIONS
#
cmp_tcx() {
probe_tcx
if [ "X${SI_TCX}" = "X${1}" ]; then
return 0
else
return 1
fi
}
|
The following example rules file shows the use of the probe keyword that is defined in the preceding example, tcx. If a TCX graphics card is installed and found in a system, profile_tcx is run. Otherwise, profile is run.
Note - Always place probe keywords at or near the beginning of the rules file to ensure that the keywords are read and run before other rule keywords that might rely on the probe keywords.
Previous Contents Index Next ![]() |