Provision Service
For Control-M to run and monitor jobs on your application host, a Control-M/Server and Control-M/Agent should be installed. The Provision service allows you access to the full cycle of the following setup processes for agents and servers:
-
Provisioning a New Installation of a New Control-M/Agent, including the option of deploying application plug-ins or integration plug-ins (even plug-ins developed in Control-M Application Integrator) to the Agent during provisioning.
-
Upgrading an Existing Control-M/Agent and deploying certain plug-ins to an existing Agent.
-
Provisioning a Control-M/Server, either as a new server or by transferring an existing Control-M/Server from one machine to another (server rehydration).
If the host on which you want to provision an Agent or Server uses a proxy server, ensure that the HTTP_PROXY and HTTPS_PROXY environment variables are defined. Values for these variables are in the format {protocol}://{host}:{port}. For example, http://172.19.0.169:3128 or https://server.com:3128. For authentication to the proxy, include logon credentials, as in the following example:
HTTP_PROXY= http://username:password@proxy.example.com:1234
If you want to opt out of proxying on specific hosts or particular destination ports, you can use the NO_PROXY environment variable, set with a comma-separated list of hosts. For example, NO_PROXY=hostname.example.com,10.1.0.0/16,172.30.0.0/16:443
Provision a New Control-M/Agent and Deploy Plug-ins
For a new installation, the Provision service includes the following major commands:
-
Image: Prepares the file system installation of the Agent.
-
Setup: Registers and configures the Agent with a Control-M/Server.
-
Install: Runs all phases of image installation (including both Image and Setup).
Separating the Image and Setup phases can help in a situation in which installing and setting up Agents dynamically is required by your architecture. In this scenario, you can prepare your image (whether it is a VM image, a Docker image, AWS AMI, etc.) with the Agent inside it. Then when required, use the setup command to dynamically perform Agent setup and register it to the Control-M/Server.
For a more static architecture, where there is no distinction between building an image and instantiation, you can use the provision install command, which allows you to install in a single step.
The following additional commands are available for removing an image and for uninstalling a Control-M/Agent from the application host:
The images used during provisioning are JSON code too. Each image contains a list of installation packages in the order that they are installed. Several default images are provided with the base installation of Control-M Automation API, and you can create additional custom images (for example, for installation of a newer version of the Control-M/Agent). To prepare for provisioning, you must obtain the installation packages (for the Agent, application plug-ins, or integration plug-ins, even plug-ins developed in Control-M Application Integrator) that are referenced within the images. You can also (optionally) customize the location in which to save these packages (for example, you might want to save the packages in a JFrog Artifactory repository, in Amazon S3 Buckets, or in your local file system). For more information about these preparatory tasks, see Control-M Automation API Provisioning. To alternatively set a different location of packages using local Automation CLI parameters, see environment configure.
The following API commands enable you to provision Agents and deploy plug-ins:
provision images
The provision images command enables you to get a list of the images that are available on the server for a specific OS. Returns a list of image names.
CLI Syntax
ctm provision images <os>
The following table describes the provision images command parameters.
Parameter |
Description |
---|---|
<os> |
Determines one of the following operating systems:
|
Here is an example of a request for a list of available images and a typical response:
> ctm provision images Linux -e devEnvironment
[
"Agent.Linux",
"Agent_20.Linux",
"ApplicationsAgent.Linux",
"BigDataAgent.Linux",
"Server.Linux",
"Server_20.Linux"
]
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
REST API Syntax
Example using curl:
os=Linux
AuthHeader="x-api-key: $token"
# AuthHeader="Authentication: Bearer $token" #for a session token
curl -H "$AuthHeader" $endpoint/provision/images/$os
provision image
The provision image command enables you to download an image and prepares it for installation.
In the case of an Agent image, this command also installs the image into the current user account, but does not configure it or register it with a Control-M/Server.
You can use this command also to install Control-M Integrations plug-ins. You store the obtained plug-in zip file in the <EM_HOME>/AUTO_DEPLOY directory and then run just this command.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
ctm provision image <image> -f <configuration file>
The following table describes the provision image command parameters.
Parameter |
Description |
---|---|
<image> |
You do not need to include the OS extension in the name of the image. For example, you can specify Agent, rather than Agent.Linux. The operating system is detected automatically. |
<configuration file> |
JSON file that contains the javaHome parameter when provisioning Control-M/Agent. The following is an example of the parameter in a JSON configuration file that indicates the location of the JRE to be used for installation of Control-M/Agent on Windows: Copy
|
provision agent::setup
The provision agent::setup command enables you to connect and register an image with a Control-M environment.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
ctm provision agent::setup [server] [name] [port] [-f <configuration file>]
The following table describes the provision agent::setup command parameters.
Parameter |
Description |
---|---|
[server] |
The agent registers to this Control-M/Server. If omitted or empty and only one Control-M/Server exists in the system, it will be selected. |
[name] |
The host name or alias of the Control-M/Agent. This is the logical name of the Control-M/Agent. If omitted or empty, the machine's name will be used. |
[port] |
This port is used as the Control-M/Agent listening TCP/IP port. If omitted or empty, an available free port will be used. |
[configuration file] |
(Optional) JSON file that contains additional parameters. |
{
"connectionInitiator": "AgentToServer",
"tag": "abc_1234",
"serverHostName":"ctmServer2",
"serverPort": 7777,
"secondaryServerHostName": "ctmServer3"
}
The following table describes additional provision agent::setup command parameters to use in the configuration file.
Parameter |
Description |
---|---|
connectionInitiator |
Determines the component that initiates the connection between the Control-M/Agent and Control-M/Server. Values:
Default: BothAllowed |
tag |
Defines a tag associated with the Control-M/Agent, used in Role-Based Administration (RBA) Tags can contain alphanumeric characters, as well as the underscore character, and can be up to 85 characters long. This parameter is available only if your Control-M/EMis of version 9.0.20 or later. |
serverHostName |
Defines the name of the server host, in case you want to override the default server host name. This parameter is required if the user performing agent provisioning uses Role Authorizations. |
serverPort |
Defines the number of the port used for server-to-agent communication, in case you want to override the default server port. This parameter is required if the user performing agent provisioning uses Role Authorizations. |
secondaryServerHostName |
The name of the secondary Control-M/Server host used in High Availability (HA) configurations. This parameter is relevant if the user performing agent provisioning uses Role Authorizations. |
Examples
provision agent::setup
provision agent::setup "" "" 2056
provision agent::setup "controlm1" "" 2056
provision agent::setup "" "alias1" 2056
provision agent::setup -f persistent.json
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
ctm provision saas:agent::setup <agentTag> [name]
<agentTag> |
The agent tag associated with the agent authorization token. For information about generating a token, see Generating an Agent Token. |
provision agent::install
The provision agent::install command enables you to combine the image and the setup commands into one action. Downloads the agent and then connects and registers it with a Control-M/Server.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
ctm provision agent::install <image> [server] [name] [port] [-f <configuration file>]
The following table describes the provision agent::install command parameters.
Parameter |
Description |
---|---|
<image> |
The image that you want to install (one of the images returned by the provision images command). |
[server] |
The Agent registers to this Control-M/Server. If omitted or empty and only one Control-M/Server exists in the system, it will be selected. |
[name] |
The host name or alias of the Control-M/Agent. This is the logical name of the Control-M/Agent. If omitted or empty, the machine's name will be used. |
[port] |
This port is used as the Control-M/Agent listening TCP/IP port. If omitted or empty, an available free port will be used. |
[configuration file] |
(Optional) JSON file that contains additional parameters. If you upgrade Control-M/Agent to version 9.0.21, you must use a configuration file and set the mandatory javaHome parameter. |
{
"connectionInitiator": "AgentToServer",
"tag": "abc_1234",
"serverHostName":"ctmServer2",
"serverPort": 7777,
"javaHome": "C:\\java\\Eclipse_Adoptium_jre-11.0.14.9-hotspot"
}
The following table describes additional provision agent::install command parameters to use in the configuration file.
Parameter |
Description |
---|---|
connectionInitiator |
Determines the component that initiates the connection between the Control-M/Agent and Control-M/Server. Values:
Default: BothAllowed |
tag |
Defines a tag associated with the Control-M/Agent, used in Role-Based Administration (RBA). Tags can contain alphanumeric characters, as well as the underscore character, and can be up to 85 characters long. Note that this parameter is available only if your Control-M/Server is of version 9.0.20 or later. |
serverHostName |
Defines the name of the server host, in case you want to override the default server host name. This parameter is required if the user performing agent provisioning uses Role Authorizations. |
serverPort |
Defines the number of the port used for server-to-agent communication, in case you want to override the default server port. This parameter is required if the user performing agent provisioning uses Role Authorizations. |
javaHome |
(Mandatory) Defines the full path where a JRE is installed. |
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
ctm provision saas::install <image> <agentTag> [name]
<agentTag> |
The agent tag associated with the agent authorization token. For information about generating a token, see Generating an Agent Token. |
provision image::remove
The provision image::remove command enables you to uninstall an image from this user account without unregistering it in Control-M.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
ctm provision image::remove
provision agent::uninstall
The provision image::uninstall command enables you to uninstall an image from this user account and unregisters it from the Control-M/Server.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
ctm provision agent::uninstall
Upgrade an Existing Control-M/Agent and Deploy Application Plug-ins
You can use API commands to perform various upgrade activities on existing Control-M/Agents, including agent upgrades and plug-in deployments. The following table lists the various activities that you can perform using the provision upgrade group of API commands:
|
Control-M/Agent |
Control-M Managed File Transfer (MFT) |
Control-M Application Pack |
---|---|---|---|
Upgrade to a new version |
Yes |
Yes |
Yes |
Roll back to a previous version |
Yes |
Yes |
Yes |
Install new plug-in on existing Agent |
NA |
Yes |
Yes |
Remove plug-in from Agent |
NA |
Yes |
No |
To prepare for provisioning, you must obtain the Control-M/Agent installation packages that you plan to use in your upgrades and place them in the <EM_HOME>/AUTO_DEPLOY directory. You must also ensure that the <EM_HOME>/CM_DEPLOY directory contains packages that are available for deployment, from your installations of Control-M MFT and Control-M Application Pack. For more information about preparing the packages, see Preparing Installation Packages for Agent Upgrades.
The Provision service offers the following commands for upgrade processes:
Command |
Description |
---|---|
Obtains a list of upgrades that are available, based on the installation packages that you have in your directories. |
|
Obtains a list of agents in your environment that are eligible for an upgrade. |
|
Transfers a deployment package and installs it. |
|
Rolls back an upgrade deployment package at the target Control-M/Agent. |
|
Obtains status details for a specific upgrade activity. |
|
Obtains status details for all upgrade activities or for multiple upgrade activities based on specified filters. |
|
Retrieves output log messages from the Control-M/Agent regarding a specific upgrade activity. |
|
Retries to run an upgrade activity that failed previously. |
|
Deletes the record of an upgrade activity that has finished running. |
|
Aborts an upgrade activity that is currently running. |
provision upgrades:versions::get
The provision upgrades:versions::get command enables you to obtain a list of upgrades that are available, based on the installation packages that are currently stored in your directories — Control-M/Agent packages in <EM_HOME>/AUTO_DEPLOY, Control-M MFT and Control-M Application Pack packages in <EM_HOME>/CM_DEPLOY.
CLI Syntax
ctm provision upgrades:versions::get
REST API Syntax
curl -H "Authorization: Bearer $token" $endpoint/provision/upgrades/versions
Response
The response lists all available upgrades according to type (Agent, MFT, or AppPack) and target version, as in the following example:
[
{
"type": "Agent",
"version": "9.0.18.200"
},{
"type": "AppPack",
"version": "9.0.18.100"
},{
"type": "MFT",
"version": "9.0.18.100"
}
]
provision upgrades:agents::get
The provision upgrades:agents::get command enables you to obtain a list of agents in your environment that are eligible for upgrade using any of the packages that are found in your directories. You can optionally limit the list to upgrades of a certain type (Agent, MFT, or AppPack) and target version.
CLI Syntax
ctm provision upgrades:agents::get [-s <query string>]
Where <query string> can contain one or both of the following fields:
Field |
Values |
---|---|
type |
Agent, MFT, or AppPack |
version |
Target version to which you want to upgrade For example: 9.0.20.200, or 9.0.21.000 |
The following example command will return details for agents that can be upgraded to version 9.0.20.200:
ctm provision upgrades:agents::get -s "type=Agent&version=9.0.20.200"
The following example command will return details for agents on which Control-M MFT can be deployed (installed or upgraded):
ctm provision upgrades:agents::get -s "type=MFT"
REST API Syntax
curl -H "Authorization: Bearer $token"
"$endpoint/provision/upgrades/agents?type=Agent&version=9.0.20.200"
Response
The response provides details for each agent and each possible upgrade that can be performed on it. In the following example, one agent was found eligible for upgrade from version 9.0.00 to version 9.0.18.100. The same agent was found eligible for installation of Control-M MFT version 9.0.18.000 (which is currently not installed).
[
{
"agent": "vw-one-ae65",
"ctm": "vw-one-ae65",
"type": "Agent",
"platform": "windows_x86_64",
"fromVersion": "9.0.00",
"toVersion": "9.0.18.100"
},{
"agent": "vw-tlv-one-ae65",
"ctm": "vw-tlv-one-ae65",
"type": "MFT",
"platform": "windows_x86_64",
"fromVersion": "",
"toVersion": "9.0.18.000"
}
]
provision upgrade::install
The provision upgrade::install command enables you to transfer a deployment package to the agent host and installs it there. Use this API command to perform any of the following activities:
-
Upgrade a Control-M/Agent to a newer version.
-
Install a new plug-in (Control-M MFT or Control Application Pack) on an existing Agent.
-
Upgrade a plug-in (Control-M MFT or Control Application Pack) on the Agent.
ctm provision upgrade::install <server> <agent> <type> <version> [activityName] [-f <configuration file>]
The following table describes the provision upgrade::install command parameters.
Parameter |
Description |
---|---|
<server> |
Name of the Control-M/Server |
<agent> |
Name of host or alias of the Control-M/Agent |
<type> |
Type of upgrade — Agent, MFT, or AppPack |
<version> |
Target version to which to upgrade |
[activityName] |
(Optional) A name for this upgrade activity. If you do not specify an activity name, the default activity name is "<server>, <agent>, <type>". |
[configuration file] |
Full path to a JSON file that contains installation details If you upgrade Control-M/Agent to version 9.0.21, you must use a configuration file and set the mandatory javaHome parameter. For more details about this configuration file, see Configuration file for provision upgrade or rollback. |
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
REST API Syntax
In the following curl example, note that the path to the configuration file is prefixed with an @ character.
curl -H "Authorization: Bearer $token"
-H "Content-Type:application/json" --data "@installConfigurationFile.json"
-X POST $endpoint/provision/upgrade/install
Configuration file for provision upgrade or rollback
You need a configuration file in the following scenarios:
-
If you are using a REST API command, use the configuration file to specify values for the various upgrade parameters or rollback parameters (which can be included in a CLI command). These parameters include several required parameters (server, agent, type, and version) and the optional activityName.
-
To specify values for the following additional parameters. These parameters cannot be included in the CLI command.
If you upgrade Control-M/Agent to version 9.0.21, you must use a configuration file and set the mandatory javaHome parameter.
The following table describes additional provision upgrade::install command parameters to use in the command file.
Parameter |
Description |
---|---|
installUser |
The user account used to perform the installation of the package. This parameter is required if all of the following conditions exist:
In all other cases, the user is set automatically, and any value that you set through this parameter is ignored. Due to JSON character escaping, if the user name includes a backslash, each backslash must be doubled (for example, "domain\\userName"). |
notifyAddress |
(Optional) A list of email addresses of recipients of notifications regarding this upgrade or rollback process. Use the semicolon character (;) to separate multiple email addresses. |
description |
(Optional) A description for the upgrade activity. |
(Optional) Determines the location of the installation files to use when upgrading the selected Control-M/Agents or its plug-ins. Valid values:
To upgrade from a network location, you must first define the same network location on the Control-M/EM system parameter CentralDeployLocation and the Control-M/Server system parameters CTM_AUTO_DEPLOY_PACKAGE_LOCATION_WINDOWS and CTM_AUTO_DEPLOY_PACKAGE_LOCATION_UNIX. If these parameters are not defined and useNetworkDeployment is set to True, the upgrade fails. This feature requires Control-M/EM version 9.0.21 |
|
(Mandatory) Full path where JRE is installed. This feature requires Control-M/EM version 9.0.21 |
The following sample configuration file contains all possible parameters (including the optional parameters and the parameters that you could alternatively set through the CLI command):
{
"server": "localControlM",
"agent": "agent1",
"type": "Agent",
"version": "9.0.21",
"activityName": "Agent1 upgrade for localControlM",
"installUser": "user3",
"notifyAddress": "joe@example.com;jane@example.com",
"description": "Upgrading the agent to version 9.0.21"
"useNetworkDeployment": "false"
"javaHome": "C:\\java\\Eclipse_Adoptium_jre-11.0.14.9-hotspot"
}
Response
The installation package is deployed and installed, and an upgradeID is returned. The upgradeID has the following format:
<server>:<activityNumber>
For example, LocalControlM:12
provision upgrade::uninstall
The provision upgrade::uninstall command enables you to uninstall an upgrade deployment package at the target Control-M/Agent. Use this API command to perform any of the following activities:
-
Roll back the newest version of a Control-M/Agent.
-
Roll back the newest version of a plug-in (Control-M MFT or Control Application Pack).
-
Remove the Control-M MFT plug-in from the Agent (if no previous version was installed).
ctm provision upgrade::uninstall <server> <agent> <type> <version> [activityName] [-f <configuration file>]
The following table describes the provision upgrade::uninstall command parameters.
Parameter |
Description |
---|---|
<server> |
Defines the name of the Control-M/Server. |
<agent> |
Defines the name of the host or the alias of the Control-M/Agent. |
<type> |
Determines one of the following types of upgrade that you are uninstalling:
|
<version> |
Determines the version to uninstall. |
[activityName] |
(Optional) Defines a name for this upgrade activity. If you do not specify an activity name, the default activity name is "<server>, <agent>, <type>". |
[configuration file] |
Full path to a JSON file that contains uninstallation details. For more details about this configuration file, see Configuration file for provision upgrade or rollback. |
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
REST API Syntax
In the following curl example, note that the path to the configuration file is prefixed with an @ character.
curl -H "Authorization: Bearer $token"
-H "Content-Type:application/json" --data "@installConfigurationFile.json"
-X POST $endpoint/provision/upgrade/uninstall
Response
The installation package is uninstalled, and an upgradeID is returned. The upgradeID has the following format:
<server>:<activityNumber>
For example, LocalControlM:12
provision upgrade::get
The provision upgrade::get command enables you to obtain status details for a specific upgrade activity.
The response provides the status of the upgrade activity, as well as various additional details (such as UTC timestamps of certain phases during the upgrade activity).
CLI Syntax
ctm provision upgrade::get <upgradeID>
Where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
REST API Syntax
upgradeID="ctm1:3"
curl -H "Authorization: Bearer $token" "$endpoint/provision/upgrade/$upgradeID"
For more information, see Control-M Automation REST API Reference.
provision upgrades::get
The provision upgrades::get command enables you to obtain status details for all upgrade activities or for multiple upgrade activities based on specified filters.
The response provides the status of each upgrade activity, as well as various additional details (such as timestamps of certain phases during the upgrade activity).
CLI Syntax
ctm provision upgrades::get [-s <query string>]
Where <query string> can contain any of the following fields.
For multiple values, use commas. As wildcards, you can use question mark and asterisk characters (? and *).
The following table describes the provision upgrades::get command parameters.
Field |
Description |
---|---|
server |
Defines the name of the Control-M/Server. Note that this field was previously named ctm (deprecated name). |
agent |
Defines the name of the host or alias of the Control-M/Agent. |
fromVersion |
Determines the source version (before the upgrade activity was performed). Example: 9.0.00.100 |
toVersion |
Determines the target version. Example: 9.0.18.200 |
acivity |
Determines the type of upgrade activity:
|
status |
Determines one of the following activity statuses:
|
activityName |
Defines the name of the upgrade activity. |
The following example command will return status details for upgrades or rollbacks to version 9.0.18 and its fix packs on Agent1 and Agent2:
ctm provision upgrades::get -s "agent=Agent1,Agent2&toVersion=9.0.18*"
REST API Syntax
curl -H "Authorization: Bearer $token" "$endpoint/provision/upgrades?agent=Agent2&toVersion=9.0.18*"
For more information, see Control-M Automation REST API Reference.
provision upgrade:output::get
The provision upgrade:output::get command enables you to retrieve output log messages from the Control-M/Agent regarding a specific upgrade activity. The output log messages are displayed on-screen.
CLI Syntax
ctm provision upgrade:output::get <upgradeID>
Where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
REST API Syntax
upgradeID="ctm1:3"
curl -H "Authorization: Bearer $token" "$endpoint/provision/upgrade/$upgradeID/output"
provision upgrade::retry
The provision upgrade::retry command enables you to retry to run an upgrade activity that failed previously.
The original upgrade activity was already assigned an upgradeID, and the retry activity does not create a new one. The response only returns a message that the retry has started.
CLI Syntax
ctm provision upgrade::retry <upgradeID>
Where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
REST API Syntax
upgradeID="ctm1:3"
curl -H "Authorization: Bearer $token" "$endpoint/provision/upgrade/$upgradeID/retry"
provision upgrade::delete
The provision upgrade::delete command enables you to delete the record of an upgrade activity that has finished running (that is, an upgrade activity in status Completed, Cancelled, or Failed).
CLI Syntax
ctm provision upgrade::delete <upgradeID>
Where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
REST API Syntax
upgradeID="ctm1:3"
curl -H "Authorization: Bearer $token" -X DELETE $endpoint/provision/upgrade/$upgradeID
provision upgrade::cancel
The provision upgrade::cancel command enables you to abort an upgrade activity that is currently running (that is, an upgrade activity in status Running or TransferCompleted).
CLI Syntax
ctm provision upgrade::cancel <upgradeID>
Where <upgradeID> is the ID returned by the upgrade activity (install or uninstall).
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
REST API Syntax
upgradeID="ctm1:3"
curl -H "Authorization: Bearer $token" -X POST $endpoint/provision/upgrade/$upgradeID/cancel
Provision a Control-M/Server
Provisioning of a Control-M/Server is supported on Windows with an MS SQL database and on Linux with an Oracle database. You can create a new Control-M/Server or you can transfer an existing Control-M/Server from one machine to another (server rehydration).
When provisioning a Control-M/Server you can choose between running two separate commands or one command:
Method |
Typical scenario |
Commands |
---|---|---|
Two separate commands |
Dynamic installation: An image (such as a VM image) is prepared with the Control-M/Server ready inside it. Setup is performed at a later time, when required. |
|
One command |
A more static architecture, with no distinction between building an image and instantiation. |
|
An additional command is available for uninstalling a Control-M/Server from the host machine.
Setup or installation of a Control-M/Server is based on settings that you define in a configuration file (a payload JSON file). For the full description of this configuration file, see Server Provisioning Configuration.
The images used during provisioning are JSON code too. Each image contains a list of installation packages in the order that they are installed. Default images are provided with the base installation of Control-M Automation API, and you can create additional custom images (for example, for installation of a newer version of the Control-M/Server). To prepare for provisioning, you must obtain the installation packages that are referenced within the images. You can also (optionally) customize the location in which to save these packages (for example, you might want to save the packages in a JFrog Artifactory repository, in Amazon S3 Buckets, or in your local file system). For more information about these preparatory tasks, see Control-M Automation API Provisioning. To alternatively set a different location of packages using local Automation CLI parameters, see environment configure.
Image-related commands are used to manage images of both Control-M/Agents and Control-M/Servers. For details of these commands see their descriptions above:
-
provision images — list all existing images.
-
provision image — download and prepare an image.
-
provision image::remove — remove an image from the user account.
The following API commands enable you to provision a Control-M/Server:
provision server::setup
The provision server::setup command enables you to install a Control-M/Server and registers it in the Control-M environment.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
CLI Syntax
ctm provision server::setup -f <configuration file>
Where <configuration file> is a JSON file that contains Control-M/Server definitions. For the full description of this configuration file, see Server Provisioning Configuration.
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
provision server::install
The provision server::install command enables you to combine the image and the setup commands into one action. Downloads the Control-M/Server, installs it, and registers it in the Control-M environment.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
CLI Syntax
ctm provision server::install <image> -f <configuration file>
The following table describes the provision server::install command parameters.
Parameter |
Description |
---|---|
<image> |
The image that you want to install (one of the images returned by the provision images command). |
<configuration file> |
JSON file that contains Control-M/Server definitions. For the full description of this configuration file, see Server Provisioning Configuration. |
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.
provision server::uninstall
The provision server::uninstall command enables you to uninstall a Control-M/Server from this user account and unregisters it from the Control-M environment.
This functionality is supported only through the CLI, and cannot be called through a REST API command.
CLI Syntax
ctm provision server::uninstall [server]
Where [server] is the name of the Control-M/Server. This is required only on a Linux machine that has multiple Control-M/Servers installed.
If annotation is enabled for the Configuration Management category in Control-M, you must also provide an annotation to justify your action. For more information, see Annotation Input.