Creating custom collectors for UNIX systems

You can create custom connectors if the basic set collectors do not collect values for the prerequisite properties that are required for the product to be installed. When you create custom collectors, the file name must be the same as the prerequisite property though without the subtype in its name. The collector is stored in the/UNIX_Linux subdirectory. The collector can contain code to obtain actual values for one or many prerequisite properties. It can also use the common functions to obtain those values if required.

Before you begin

Ensure that you review the set of functions in the following appendixes before you create the collectors. Determine whether you can use any of them to obtain the actual values:

Determine whether the collector must check that the prerequisite property exists and if it does, what other information must be gathered. Each check must return a value, whether one exists. For example:

Check whether a product is installed, for example, a package that is installed with RPM.
Check what version of the product is installed.
Check whether the available disk space for a mounted file system

If you want to use subtypes, suffix_identifier, and further categorize a prerequisite property by application, utility, or service subtype, you can create a common collector. Pass the differentiator for the suffix_identifier subtype, that is, differentiator_suffix_identifier to its collector. For example, os.package is the common collector to check for the existence of packages. To check for the existence of openssh, pass the name of the package when the tool invokes the os.package collector in the packageTest.sh script file, as follows:

./os.package openssh

Where openssh is the name of the package, that is, the suffix_identifier subtype and the differentiator_suffix_identifier differentiator.

Procedure

Create a shell script file. Save the file in the ips_root/Unix_Linux directory, with a variant of the following file naming convention but without a file extension:
```
[prefix_identifier.]property_name
```
Where:
- prefix_identifier is an identifier for a predefined category of prerequisite properties as outlined in Table 1. This prefix identifier is required by some of the predefined categories, for example, env.
- property_name is the name of the prerequisite property, for example, path.jre
Using an editor, open the file and include the path to the common_function.sh if you must use common functions, as follows:
```
. ../lib/common_function.sh
```
Add the code to obtain the value for the prerequisite property by using commands and options specific to that platform to access elements of the host environment. For example, the custom env.path.jar prerequisite property needs to check whether the JRE is set in the PATH variable. The following code runs the env command, searches the output for PATH variable, and then searches its value for the JRE path.
```
envJRE=`env | grep "PATH" | grep -w "/opt/IBM/Java60/jre/bin"`
```

Ensure that the check returns standard output:

echo $TRUE_STR|$FALSE_STR 
'If the scan checks for the existence of the prerequisite 
'property
echo $res 
'If the scan checks returns the value, for example, product version,
'of the prerequisite property
echo $AVAILABLE_STR
'If the scan returns no value for the prerequisite property
echo $UNAVAILABLE_STR 
'If the scan returns a valid check for the prerequisite property

In the example, the check either returns True or False that is based on the value of the $envJRE variable:

if [ $envJRE ]; then
	echo $TRUE_STR
else
	echo $FALSE_STR
fi

Run the custom collector to ensure that there are no runtime errors and debug as necessary.
Edit the ips_root/UNIX_Linux/packageTest.sh script to call and run the custom collector.
Create a custom evaluator only if the custom collector returns values other than boolean values.