Nodes

aliasMapping/policy

Based on the policy that you set in nodes:default:aliasMapping:policy: (for all environment types) or nodes:envType:aliasMapping:policy: (for a specific environment.type), each node is referenced by:

• A global node alias, when policy: HOSTNAME|EXISTING

  HOSTNAME (default) maps each layer defined in the provision/environment.type sections to a list of node aliases or hostnames.

  EXISTING uses the details of a Platform Manager node that already exists in Command Central (such as Platform Manager installed from the web user interface, the CLI, or another template) and ignores any parameters included in the nodes section of the template, except the node alias.

• An indexed node alias when policy: INDEX

  INDEX uses a node alias generated from a custom prefix (specified in the prefix: parameter) and an index number, based on the consecutive order of the hosts in provision:envType:infrastructure:hosts.

When policy: INDEX, you must also include the prefix: parameter. The value of the prefix: parameter is used to generate an indexed node alias in provision:envType:layer:aliases. Use the delimiter: parameter if you want to specify a custom delimiter for the generated indexed node alias. For example:

nodes:
    default:
      aliasMapping:
        policy: INDEX
        prefix: node
        delimiter: "_"

In the nodes section, you can also use reference parameters to refer to the node alias prefix and index. For example:

nodes:
    default:
      aliasMapping:
        policy: INDEX
        prefix: ${node.alias.prefix}             # The prefix of the node alias.
      default:
        port: ${spm.port}
        bootstrapInfo:
          installDir: /opt/sag${node.alias.prefix}${node.index} # The indexed node alias
                                                                # (prefix plus index number)

credentials: ${spm.credentials.alias}

In the nodes:default:default: section, you must specify the credentials alias for the Platform Manager administrator user credentials. Beginning with Platform Manager release version 10.11, the credentials parameter is required and by default uses the ADMINISTRATOR credentials alias. If Platform Manager is already bootstrapped on the target node and you use a custom password for the administrator user account, you must define a credentials alias for the custom administrator user credentials. For example, in the following template snippet, the credentials parameter refers to the spm.credentials.alias parameter.

nodes:      
    default:      
      default:      
        port: ${spm.port}      
        secure: ${spm.secure}      
        credentials: ${spm.credentials.alias}

You can specify the value of the spm.credentials.alias parameter in the environments/default section, a separate properties file, or as argument of the apply composite template command. The spm.credentials.alias parameter maps to the alias of the common credentials configuration instance you created for your custom administrator user, for example: spm.credentials.alias: SECURE_ADMINISTRATOR

where SECURE_ADMINISTRATOR is the alias of the custom COMMON-CREDENTIALS-SECURE_ADMINISTRATOR configuration instance. For information about creating common credentials configuration instances, see Configuration Types for Command Central and Platform Manager OSGI ENGINE.

When bootstrapping nodes with version:

• 10.11 and higher, you should use the ADMINISTRATOR credentials alias or a custom credentials alias with a strong password. Note that the ADMINISTRATOR credentials alias does not have a default password value and you must specifying a strong administrator password before using the ADMINISTRATOR credentials. For more information, see Default and Custom Passwords for Product Administrator Users.
• 10.7 and lower, by default the template uses the DEFAULT_ADMINISTRATOR credentials alias, which includes the default password. IBM strongly recommends that you replace the default password with a strong administrator password.

nodes/default/default/bootstrapInfo

In the nodes/default/default section, you can add an optional section with bootstrap information that enables you to bootstrap Platform Manager to a local or remote installation.

You can specify the following parameters in the nodes/default/default/bootstrapInfo section:

bootstrapInfo:
  installer: ${bootstrap.installer}    # The file name of the Command Central
                                       # bootstrap installer to use
                                       # for bootstrapping Platform Manager.
  installDir: ${install.dir}           # The installation directory
                                       # of Platform Manager.
  substituteUserCredentials: ${subst.credentials.alias}  # For remote bootstrap: the 
                                                         # alias for the substitute user
                                                         # credentials to use to install
                                                         # and start Platform Manager. 
  credentials: ${credentials.alias}    # For remote bootstrap: The SSH credentials
                                       # to use to connect to the remote hosts.
  version: "${release}"                # The release version of
                                       # the Platform Manager node.
                                       # For backward compatibity when "cc.installer"
                                       # is not available.

For more information about how to use substituteUserCredentials: and credentials:, see Bootstrapping on a Remote Machine with a Substitute User.

After you download the Command Central bootstrap installer for the release that you want from the IBM Passport Advantage Online website, save the downloaded Command Central bootstrap installer file into the $CC_HOME/profiles/CCE/data/installers directory. To list the available bootstrap installers, run the following CLI command: sagcc list provisioning bootstrap installers.

Usage Notes

• When you use the Command Central bootstrap installer for the nodes bootstrap, only Platform Manager is installed on the nodes, without the CLI. To install the CLI with the same template, you must include an inline template that installs the CLI as a product.
• Command Central attempts to connect to the Platform Manager host and port of the node, which Command Central wants to use, with the user credentials specified for the node. If Platform Manager is running and responds, Command Central uses the node. If Platform Manager does not respond, Command Central attempts to connect to the remote host using the SSH protocol and the user credentials defined in the bootstrapInfo section. If the connection is successful Command Central bootstraps and starts Platform Manager, and waits until Platform Manager becomes responsive and available to establish an HTTP/S connection.
  Important: By default, the Command Central bootstrapper installs Java on the remote host and the SSH user connects to the Java installation. If required, you can use an existing Java installation on the remote host by adding a javaPath property in the bootstrapInfo section to specify the Java location as follows: javaPath: /path/to/java

• You can define the ${install.dir} parameter as a variable in the environments section that points to ${user.home}, for example:

  environments:
    default:
      cc.installer: cc-def-10.7-milestone-w64.bat
  	   install.dir:  ${user.home}\sag102
  ...
  nodes:
    default:                                        
      default:                                      
        port: ${spm.port}                         
        secure: false
        bootstrapInfo:
          installDir: ${install.dir}    # Installation directory
          installer: ${cc.installer}
  ...

  To resolve ${user.home} correctly in Windows, you must start the Command Central and Platform Manager Windows services from a local user account with administrator permissions, not from a "Local System" user account.