Extending custom servers

You can create a custom server template for an application to categorize the application and later display it as part of the topology. You can also view details about the application, including the listening port, runtime information, and any configuration files or application descriptors that were collected.

In some cases, however, this might not be sufficient. For example, you might also need to access the product version. By default, TADDM cannot collect version information for arbitrary custom server applications.
You can, however, extend custom server templates to collect additional information, as required, by using the following approaches:
  • Run commands on the target system to populate any attribute in the IBM® model for the component.

    You can use this approach to set the productVersion attribute, for example.

  • Run commands on the target system and store the result as a configuration file for the component.

    One common use of this approach is to extract information from the Windows Registry.

  • Run a Jython script on the server.

    You can change any information about a component. The difference between this and the first approach is where the code runs. Additionally, you can use a Jython script to populate extended attributes and to create new model objects or relations.

To define a custom server, complete the following steps:

  1. Open the Discovery Management Console.
  2. Create a custom server template for the application by completing the following steps:
    1. Click Discovery > Custom Servers in the sidebar.
    2. Click Add to define a new custom server template.
    3. Configure the general information and criteria for the custom server template.
    4. Configure the custom server configuration files.
      You can configure the capture of the following types of files:
      • configuration files
      • application descriptors
      • software modules
      For more information on application descriptors, see Application descriptors. Software modules represent deployed application modules such as executable code or scripts that are running inside the custom server. This is an optional level of detail that you can add to the discovery of your custom server. If applicable, you can include these software modules in Business Applications for a higher level of visibility into the composition of your Business Applications.
  3. Create a directive file that contains the commands to run, and add commands and scripts to the directive file, as required.

    Use the format described in Table 1 when specifying commands in the directive file. Table 2 outlines the environment variables that you can use in the directive file.

    Keep commands as simple as possible. If the command stops during execution, the sensor will time out and the component is not discovered.

  4. Save the directive file.

    The directive file must have the same name as the custom server template, and must be stored in the following directory: $COLLATION_HOME/etc/templates/commands. TADDM triggers directives in this directory using the name of the custom server template.

Table 1 describes the command format for directive files.

Table 1. Directive file format
Directive Description

CMD:variable= path/command

You can define an inline command. For example:

CMD:productVersion=/usr/sbin/postconf
|awk '/^mail_version/ {print $3}'

You must always specify absolute paths to commands, and you must enclose with double quotation marks (") commands or arguments that contain spaces.

You can use environment variables associated with the process, specified by $VARIABLE$. For example,

CMD:productVersion=grep versionNum
$TOMCAT_HOME$/config/config.props |
awk '{print $2}'

CMD:NOP= path/command

You can run the command without assigning results to a variable. For example:

CMD:NOP=reg export HKLM\Software\
Microsoft\InetStp c:\windows\temp\
iis.reg /y

CMD:CONFCONTENT. filename= path/command

You can run a command and store the results in the custom configuration file specified by filename. For example:

CMD:CONFCONTENT.iisREG=cmd.exe /c type
c:\windows\temp\iis.reg

For more information, see the section on executing commands to create a custom configuration file.

SCRIPT: path/script

You can initiate Jython (.py) scripts. For example:

SCRIPT:path/command.py

When the path starts with (/) TADDM assumes an absolute path; otherwise the path is relative from $COLLATION_HOME. For more information, see the section on executing Jython scripts.

Table 2 describes the environment variables available for use in directive files.

Table 2. Directive file environment variables
Variable Description

$COLL_PROGPATH$

This variable expands to the name of the directory where the program is located. For example, if the command line is /usr/local/bin/foobar -c /etc/foobar.conf, the $COLL_PROGPATH$ variable expands to /usr/local/bin.

You can use this variable to insulate your directive file in cases when a command is located in different directories on multiple computers.

$COLL_PROGNAME$

 This variable expands to the fully qualified executable name. For example, if the command line is /usr/local/bin/foobar -c /etc/foobar.conf, the $COLL_PROGNAME$ variable expands to /usr/local/bin/foobar. To run the appropriate command, you can use $COLL_PROGPATH$/$COLL_PROGNAME$.

$COLL_CMDLINE$

This variable expands to the entire command line, including any arguments. For example, if the command line is /usr/local/bin/foobar -c /etc/foobar.conf, the $COLL_CMDLINE$ variable expands to /usr/local/bin/foobar -c /etc/foobar.conf.

You can use this variable to find the version of the secure shell daemon (sshd) running on a system without having to know where it is installed, using the following command:

CMD:productVersion=$COLL_PROGPATH$/
sshd -V 2>&1 |awk '/version/ {print $3}'