Defining a custom binary payload
Administrators can define a custom binary payload and deploy it across environments. A binary payload file can contain binary files, configurations files and executable files such as batch or Shell scripts. For example, you can promote changes to your custom plugins from your development environment to the production environment.
To create a custom binary payload
In the AR System Administration console, open the AR System Single Point Deployment Payload form and perform the following procedure:
|1||Go to the Basic Information panel|
|2||Go to the Operations panel|
To select automatic rollback on failure and to deploy the payload, select appropriate value for the following fields:
|3||Go to the Deployment Details panel|
To create a binary payload click Save and click Close.
(Optional) To start the binary payload deployment select Yes from the Available for download option.
|6||(Optional) To view the status of the binary payload, click View Payload Status and click Close. |
For more information about viewing the status, see Viewing the status of a binary payload .
To deploy previously deployed binary payload onto the new server in a server group
Perform the following steps when you add a new server to a server group, and you want to deploy a previously deployed binary payload (such as patches or hotfixes) onto the new server.
- Open the AR System Single Point Deployment Payload form.
- Enter the Deployment Payload name and click Search.
Records matching with the given Deployment Payload name are fetched.
- Create a copy of each matching record by clicking CTRL+ ALT+C on the keyboard.
- Select No from the Available for Download option.
- Select Specific Server from the Where to Deploy field.
- Select the new server name from the Server Name field.
- Click Save.
- Repeat this procedure for all the matching records fetched in step 3.
- Search all the new records by using the Specific Server Name.
- Select all the new records by clicking Select All
- Click Modify All
- Select Yes from the Available for Download option.
- click Save.
AR System Single Point Deployment Payload form fields
This section describes the fields available on the AR System Single Point Deployment Payload form.
The following table describes how to set the fields in AR System Single Point Deployment Payload form.
|Basic Information panel|
|Deployment ID||Contains a unique identifier for binary payload that is automatically populated when you click New Request.|
|Deployment Payload Name||Descriptive name for the payload entry, such as serverfix.|
|Deployment Payload Group Name|
Deployment payload group name that consists of multiple binary payloads, such as patch001.
This group name is reflected on the AR System Deployment Management form when you create a package by using the AR System Deployment Management Console.
|Deployment Payload Description||Description related to the fix that you are providing in the payload.|
For each component, shows one of following status for the binary payload deployment:
|Status Details||Displays the overall status of the payload.|
Runs the given operating system command, such as (UNIX) \opt\bmc\run.sh
Processing Group Name
|Logical group of payloads that correspond to a particular process. Consider the following validations:|
|Dependent on ID|
Signifies the dependancy of current payload with another payload.
|Extract Zip Attachment||Extracts the attached zip file.The default value is Yes.|
Adds a file to the payload. If you have multiple files, create a zip file.
Note: BMC supports files only in .zip format.
Specifies instructions to the file based on one of the following options.
|Available for Download||Instructs the AR System server to start the payload deployment. Once you select Yes, you cannot reset it to No.|
Cancels the active payload deployment.
Note: When you choose this option in a server group environment, the payload deployment finishes on the server where the deployment is in progress. However, the payload deployment on the other servers will be cancelled.
|Start Rollback||Removes a successfully deployed payload.|
Automatic Rollback on Failure
Determines the action performed when a payload deployment fails on any server in a server group based on the following options:
For example, when you set the value to Yes, if the package deployment is successful on the first two servers but fails on the third server, the payload is rolled back from all the servers in the server group. If you set the value to No, then the successfully deployed payloads on the first two servers are not rolled back.
|Deployment Details panel|
Binary payload deployment is supported on the following operating systems:
The path to the directory where you want to deploy the binary payload. You can specify the following types of paths:
Where to Deploy
Select one or multiple servers. Choose one of the following options:
When you select the Specific Server option and you have a specific server that has multiple components with File Deployer services, the binary payload is deployed to all the File Deployers on that particular server. To select a specific File Deployer, first, you must specify the process, then start the process of binary payload deployment.
Select a particular server. Choose one of the following options:
Note: The Server Name is only displayed if you select the Specific Server option from the Where to Deploy field.
Select Monitor Type. Choose one of the following options:
Note: The Monitor Type is displayed only if you select the All Server of a Type option from the process type Where to Deploy field
Select process type for the binary payload. Choose one of the following options:
When you select a process type from the list, that particular process is stopped and the attached binary payload is deployed. After the binary deployment is successful, the process starts again. When the deployment fails, an automatic rollback is triggered and the process is started after the original binary is restored.
For example, if you select the BMC:JavaPlugin option from the Process Type list, the Plugin Server is stopped, but the other armonitor processes are still running. The binary is deployed for the Plugin Server. If the binary deployment is successful, the Plugin Server starts again. However, if the binary deployment fails, the original binary is restored after which the Plugin Server starts.
If a process defined in the armonitor.cfg or armonitor.conf file such as Email Engine or BMC Remedy Flashboard is down, the process is automatically started after successful package deployment, provided the process restart is required.
If you select the BMC:JavaPlugin process type, you enter the Java plugin name as specified in your environment. This field is case sensitive.
System Information panel
Displays audit information for a particular package. This information is automatically populated.
|View Payload Status||Shows the payload status. For more information about viewing the status, see Viewing the status of a binary payload.|
|Close||Closes the form.|