Administer > Content utilities > IDK scripts > Dynamic configuration with ISM parameters

Dynamic configuration with ISM parameters

The ISM parameter utility enables control scripts and installation hooks to access the values of SA custom attributes. The key of an ISM parameter matches the name of its corresponding custom attribute. The value of a custom attribute determines the value of the parameter. The source of a custom attribute is an SA object such as a facility, customer, server, or device group.

Set with the SA Client, a custom attribute is a name-value pair that holds configuration information. For example, to designate the port number of an Apache web server, a custom attribute named APACHE_1.3_PORT could have a value of 80. If an ISM has a parameter named APACHE_1.3_PORT, a control script could access the current value of the custom attribute.

Using the ISM Control window of the SA Client, an end-user can view the source (SA object) of a parameter, view the parameter value, and override the parameter value.

Development process for ISM parameters

The overall process for developing and using ISM parameters follows:

  1. With the ISMTool, add a new parameter.
  2. With a text editor, write a control script (or modify an installation hook) to access the parameter.
  3. With the ISMTool, build and upload the ISM.
  4. In the SA Client, install the application contained in the ISM onto a managed server.
  5. In the SA Client, create a custom attribute with the same name as the parameter.
  6. In the SA Client, run the control script on the managed server. At runtime, the script retrieves the parameter (control attribute) value from Server Automation.

Adding, viewing, and removing ISM parameters

The ISMTool --addParam command creates a new parameter, which may be fetched by any script in the ISM. A parameter is a tuple with four fields, each specified by an ISMTool option. The following table lists the fields and their corresponding options.

ISM parameter Fields

Parameter field

ISMTool option

Description

Name

--addParam

The name of the ISM parameter, which must match the name of the custom attribute.

Default Value

--paramValue

The default value of the parameter. The script uses the default value if a matching custom attribute is not found.

Type

--paramType

The data type of the parameter. Allowed values:
‘String’
‘Template’

Description

--paramDesc

Text describing the parameter.

The following Unix command adds a parameter named NTP_SERVER to the ntp-4.2.1 ISM:

ismtool --addParam NTP_SERVER \	
	--paramValue 127.0.0.1 \
	--paramType 'String' \
	--paramDesc 'NTP server, default to loopback' ntp-4.2.1	

To view the parameters that have been added to the ntp-4.2.1 ISM, enter the following:

ismtool --showParams ntp-4.2.1

To remove the parameter added in this example, you enter the following command:

ismtool --removeParam NTP_SERVER ntp-4.2.1

Accessing parameters in scripts

After you’ve added a parameter with ISMTool, you can write an ISM control script to access the parameters. The supported scripting languages follow:

  • Bourne Shell
  • Korn Shell
  • Windows command shell
  • Python
  • Perl

Shell scripts access the parameters through environment variables, Python scripts through dictionaries, and Perl scripts through hash tables.

ISM parameters utility

To fetch parameters, a control script runs the parameters utility, which resides in the ISM shared runtime package. Only those parameters defined with the --addParam command can be fetched.

The parameters utility has the following syntax:

parameters [options]
--scope <scope> ; server|servergroup|customer|facility|
; servicelevel|os|custapps|webserver|appserver|
; dbserver|systemutilities|osextras|install|
; default (default is all)
-s/--sh ; Bourne Shell syntax
-k/--ksh ; Korn-Shell syntax
-p/--python ; Python repr'ed dictionary
-l/--perl ; PERL map
-c/--cmd ; Windows Cmd syntax
-b/--vbscript ; Windows VBScript syntax
-h/--help ; Help
-v/--version ; Version

The --scope option limits the search for the custom attribute to the specified area of Server Automation. For example, if you specify --scope facility and a custom attribute has been defined for both the facility and the customer, then the custom attribute of the customer is not considered. See Search order for custom attributes.

If the parameters utility encounters an error during retrieval, it returns a special parameter named _OPSW_ISMERR, which contains a brief description of the error encountered.

Sample scripts

The following Bourne Shell example is a control script that configures the NTP time service on Unix. The parameters utility retrieves two parameters, NTP_CONF_TEMPLATE and NTP_SERVER, that have been defined for the ISM.

#!/bin/sh
. ‘dirname $0‘/../env/ism.sh
86 Chapter 6
eval ‘${ISMDIR}/bin/parameters‘
echo $NTP_CONF_TEMPLATE | \
sed "s/NTP_SERVER_TAG/$NTP_SERVER/" > /etc/ntp.conf

The following control script, written in Python, also configures NTP.

#!/usr/bin/env python
import os
import sys
import string
ismdir=os.path.split(sys.argv[0])[0]
cmd = ’%s --python’ % (os.path.join(ismdir,’bin’,’parameters’))
params = eval(os.popen(cmd,’r’).read())
template = params[’NTP_CONF_TEMPLATE’]
value = params[’NTP_SERVER’]
conf = string.replace(template,’NTP_SERVER_TAG’,value)
fd=open(’/etc/ntp.conf’,’w’)
fd.write(conf)
fd.close()

The following example shows a configuration control script for Windows. In this example, for 32 bit Windows operating systems, each parameter is output in the form of name=value (one per line).

The Windows FOR command sets each parameter as an environment variable. (In the listing that follows, the FOR command is split into two lines, but in the actual script, the FOR command must be on a single line.) Finally, the parameters are passed to an NTP configuration script named WindowsNTPConfigureScript.cmd.

@echo off
SETLOCAL
cd /d %ISMDIR%
for /f "delims== tokens=1,2" %%i in ('""bin\parameters.cmd""') do set
%%i=%%j WindowsNTPConfigureScript.cmd %NTP_CONF_TEMPLATE% %NTP_SERVER%
ENDLOCAL

Search order for custom attributes

With the SA Client, you can set a custom attribute in several places. For example, you could set a custom attribute named APACHE_1.3_PORT to 8085 for a managed server named foo.hp.com, and you could set the same custom attribute to 80 for the Widget Corp. customer, which is associated with the foo.hp.com server. At runtime, if a control script on foo.hp.com accesses the APACHE_1.3_PORT parameter, which value will it fetch? In this case, the value will be 8085 because a custom attribute for a server occurs first in the search order.

Note that if a custom attribute is not found, the script uses the default parameter value that you set with the ISMTool --paramValue option.

Default Search Order

The default search order for custom attributes is as follows:

  1. Server
  2. Device Group
  3. Customer
  4. Realm
  5. Facility
  6. Operating system.
  7. ISM (created in the software policy during the upload operation)
  8. Patch Policy
  9. Software Policy

Multiple device groups and service levels are searched alphabetically. For example, if a server belongs to the ABC and XYZ groups, the ABC group is searched for the custom attribute before the XYZ group. A server group that is a subgroup does not inherit the custom attributes of its parent group.