Bulk Robot Deployment with an XML File

 This article explains how to prepare an XML file to deploy robots in bulk. Once prepared, the XML file can be processed by placing it into the automatic_deployment_engine probe folder or by using USM. 
uim901
This article explains how to prepare an XML file to deploy robots in bulk. Once prepared, the XML file can be processed by placing it into the automatic_deployment_engine probe folder or by using USM. 
 
Contents
 
 
 
Verify Prerequisites
Verify the following prerequisites before performing bulk deployment:
  • Your Primary Hub is the source system.
  • Your UIM Server archive has the required robot installer archive packages:
    •  
      robot_exe
       
    •  
      robot_rpm
       
    •  
      robot_deb
       
    •  
      robot_sol
       
    •  
      robot_aix
       
  • Your target systems are supported. For supported software versions, see the Compatibility Matrix  
Also ensure that the following requirements are met for your specific operation system:
Windows
  • All appropriate firewall ports and Windows shares must be configured to allow remote WMI and DCOM connections. These ports are open and available on a default Microsoft Server installation.
  • Robots for Windows systems must be deployed from Hubs running Windows. The source system and target systems must also be in the same Windows domain, unless the target systems are in the default Windows domain 
    workgroup
    .
  • You must have local administrative privileges on the target systems. In addition, the user who is listed in the 
    host-profiles.xml
     
     
    for your target Windows systems must have remote access and remote execution privileges. We recommend that this user is an administrator.
Linux
  • The source and target systems must have 
    /bin/bash
    ssh
     (secure shell), and 
    glibc
    . Most supported Linux distributions include bash and ssh by default; all versions include glibc by default.
  • You must have access to 
    root 
    or a non-administrative account that supports 
    sudo
     to perform per-command, root-level operations.
Solaris
If you are using 
sudo
, configure your Solaris system to support passwordless requests to CA UIM. To allow passwordless requests, enter the following commands in the 
etc/sudoer 
file:
Ensure that you are adding the following commands to the 
NOPASSWD: 
section for your sudo user. Also, ensure that you are using the 
visudo 
command to edit the 
etc/sudoer
 file, not a text editor. 
  •  
    (root) /usr/bin/sh -c /usr/sbin/pkgadd -d /tmp/nimsoft-robot-amd64 -a /tmp/ask < /tmp/input
     
  •  
    (root) /usr/bin/bash /opt/nimsoft/install/RobotConfigurer.sh
     
  •  
    (root) /etc/init.d/nimbus start
     
Prepare the XML File for Robot Deployment
Before you begin preparing your XML file, note the following items:
  • Advanced users who want to perform extra customization can specify any supported robot parameter.
  •  
    (Linux and Solaris)
     The XML field that defines the relative path to the private key on the Hub system at 
    <rsakeyfile>/relative_path/to/private_key_file</rsakeyfile>
    .
  •  
    (Linux and Solaris)
     The 
    sudo_password
     parameter is only required for non-root users with administrative privileges.
  •  
    (Windows)
     If the target host is part of a domain, Windows usernames can also specify the domain (
    domain\username
    ).
  • To deploy a passive robot, add the following line to the <host> section:
    <robot_mode>passive</robot_mode>
  • If not specified, defaults are used for some required parameters:
    •  
      name
       defaults to the target host name.
    •  
      IP_version
       defaults to IPv4 
    •  
      Origin
       defaults to the parent Hub name
       The origin value is attached to all messages created by monitoring probes. MSPs, for example, might want to set origin to a client name.
    •  
      Robot mode
       defaults to active
       Users who plan to deploy marketplace probes can specify passive mode, as those probes are required by default to run on passive robots.
Example XML File 
<hosts>
<host>
<profile>
Windows
</profile>
<arch>
32
</arch>
<hostname>
customer1
</hostname>
<username>
domain\Administrator
</username>
<password>
admin_password
</password>
<domain>
AutoEnv
</domain>
<hubip>
10.10.10.10
</hubip>
<hub>
w2k8-x64-Primaryhub
</hub>
<hubrobotname>
w2k8-x64-Primary
</hubrobotname>
<hubport>
48002
</hubport>
<robotname>
w2k8-x86
</robotname>
<tempdir>
c:\tmp\supertmp
</tempdir>
</host>
<host>
<profile>
CentOS
</profile>
<arch>
64
</arch>
<hostname>
server1
</hostname>
<username>
root
</username>
<password>
root_password
</password>
<domain>
AutoEnv
</domain>
<hubip>
101.101.101.101
</hubip>
<hub>
w2k8-x64-Primaryhub
</hub>
<hubrobotname>
w2k8-x64-Primary
</hubrobotname>
<hubport>
48002
</hubport>
<robotname>
CentOS6-x64
</robotname>
<tempdir>
/opt/tmp
</tempdir>
</host>
<host>
<profile>
CentOS
</profile>
<arch>
64
</arch>
<hostname>
server1
</hostname>
<username>
username
</username>
<password>
user_password
</password>
<sudo_password>
sudo_password
</sudo_password>
<domain>
AutoEnv
</domain>
<hubip>
101.101.101.101
</hubip>
<hub>
w2k8-x64-Primaryhub
</hub>
<hubrobotname>
w2k8-x64-Primary
</hubrobotname>
<hubport>
48002
</hubport>
<robotname>
CentOS6-x64
</robotname>
<tempdir>
/opt/tmp
</tempdir>
</host>
</hosts>
Required Attributes
The following table lists all robot attributes that are required when you deploy a robot.
Attribute
Description
 
profile
 
Operating system on target system:
  • aix
  • centos
  • debian
  • hp-ux
  • linux (legacy support for previous RPM packages)
  • opensuse
  • rhel (Red Hat Enterprise Linux)
  • solaris
  • suse (SUSE Linux Enterprise Server)
  • ubuntu
  • windows
 
arch
 
Architecture of target system:
  • 32 (32-bit)
  • 64 (64-bit)
  • ia64 (HP-UX Itanium)
  • pa-risc (HP-UX PA-RISC)
  • ppc64 (AIX 64-bit)
  • s390x (zLinux)
  • sparcv9 (Solaris)
 
hostname
 
Target system hostname or IP address.
 
username
 
User name for an account on the target that has administrative permissions or supports sudo for root-level permission.
 
password
 
Account password.
 
domain
 
Domain to which the robot belongs. Case-sensitive.
 
hubip
 
IP address of the hub that manages this robot (referred to as the parent hub).
 
hub
 
Name of the parent hub.
 
hubrobotname
 
Robot name of the parent hub. Case-sensitive.
 
hubport
 
Port that the parent hub listens on. The default is 48002.
Optional Attributes
You can specify values for these attributes as needed. This table also shows default values when they exist.
 
Optional Attribute
 
Description
Default
 
installdir
 
Path to the directory where the robot is installed on the target system.
C:\Program Files\Nimsoft or
C:\Program Files (x86)\Nimsoft
 (Windows)
 
/opt/nimsoft 
(Unix)
 
 
robot_mode
 
Mode of communication with the Hub:
  • Active (default) – Robot sends messages to its parent Hub when it receives them from the probes.
  • Passive – Robot sends data to the Hub at the Hub's request. Limits are placed on the amount of data the robot can send. 
  • Offline – Robot does not initiate or expect communications from its Hub.
Active
 
robotname
 
Unique name to be assigned to the deployed robot.
Target system hostname
 
rsakeyfile
 
Relative path to RSA private key certificate on the system hosting ADE in this format. Key files with pass phrases are not supported.
None
 
sudo_password
 
Password string for sudo. This password lets you use sudo over ssh during installation. The ssh password is still required. This parameter is not applicable to root users.
None
 
tempdir
 
Desired path for a temp directory on the target system. For example, 
C:\tmp\supertmp
 
(Windows)
 or
 /opt/tmp
 
(Unix).
 
 
ip_version
 
IP address schema version: 
IPv4
 or 
IPv6
.
IPv4
 
robotip
 
IP address of the robot. The robot communicates on this interface only. This value is propagated to its probes.
If no value is specified (default) the robot automatically finds its IP address. If the system has multiple interfaces, it is unpredictable which interface the robot will use.
 
robotip_alias
 
Robot IP address in a NAT environment.
 
tz_offset
 
Time zone offset override, in seconds, positive or negative.
0
 
autoremove
 
Specifies whether the robot should unregister itself from the Hub after it terminates. Value: 
yes 
or 
no
.
no
 
hub_dns_name
 
Fully qualified DNS name of the parent Hub. If specified, this value overrides the hubip, which is then used only as a cached value if the DNS lookup fails.
 
hub_update_interval
 
Interval, in seconds, at which the controller should send alive or probelist information to the hub.
900
 
hubdomain
 
Domain of the parent Hub.
 
secondary_domain
 
Domain of the Secondary Hub that manages the robot if its assigned parent Hub is unavailable.
 
secondary_hub
 
Hub that manages the robot if its assigned parent hub is unavailable.
None. Robot attaches to the first hub it locates if its own parent is unavailable.
 
secondary_hub_dns_name
 
Fully qualified DNS name of the Secondary Hub. If specified, this value overrides the secondary_hubip, which is then used only as a cached value if the DNS lookup fails.
 
secondary_hubip
 
IP address of the Secondary Hub. Overridden if the DNS name is specified.
 
secondary_hubport
 
Hub port of the secondary Hub.
48002
 
secondary_hubrobotname
 
Name of the secondary Hub’s robot.
 
secondary_robotip_alias
 
The NAT addresses the robot uses when connected to the secondary hub. Valid values are:
  •  
     same
    , which uses the parent hub NAT address (default)
  •  
     
     IP address
     
     
same
 
send_alive
 
Whether or not to send alive messages to the hub. Values:
  •  
     1
     – Send at each hubupdate interval
  •  
     0
     – Do not send alive messages (useful it the robot runs in an offline mode and you want to establish contact between the robot and hub only when needed)
  •  
     -1
     – Send the complete probe list; use with very old hubs that do not understand the alive message format
1
 
do_not_broadcast
 
Prevent the robot from broadcasting to locate any hub. By default, a robot that is not attached to a Hub will broadcast to locate a temporary hub. Value: 
yes 
or 
no
 
no
 
temporary_hub_broadcast
 
Prevent the robot from broadcasting to locate a temporary hub if its parent hub and secondary Hub are not available. This causes the robot spools its messages until its parent or Secondary Hub is available. By default, a robot that is not attached to a Hub will broadcast to locate a temporary Hub. Value: 
yes
 or 
no
.
no
 
unmanaged_security
 
Specifies which Hubs the robot can broadcast to in order to establish contact. Values:
  •  
     not_locked
    none
    , or 
    open 
    – any Hub
  •  
     domain_locked
     or 
    domain
     – only to Hubs in the robot’s domain
  •  
     hub_locked
     or 
    hub
     – no broadcast is allowed; controller can only contact its parent Hub.
domain_locked
 
controller_port
 
Port assigned to the controller probe.
48000
 
first_probe_port
 
First port assigned to a probe by the controller. Ports are assigned to subsequent probes in sequence. Use this option if you want the probes to have port numbers in a specific range for router or firewall purposes.
48000
 
port_alive_check
 
Interval, in seconds, for port alive checking.
330
 
port_alive_include_local
 
Specifies whether to include ports that are registered from local probes when performing the port check. Value: 
yes 
or 
no
.
yes
 
spooler_port
 
Port that is assigned to the spooler probe.
48001
 
logfile
 
Name for the log file.
controller.log
 
loglevel
 
Logging level for messages from the robot. Values: 
0
 through 
8
.
0
 
logsize
 
Maximum size, in kilobytes, for the controller.log file.
100
 
proxy_log
 
Logging level for proxy functions in the controller.log file. Typically set from 1 to 5.
Values: 0 through 8.
4
 
origin
 
Origin for messages that identifies the source of the message. Typically used to partition data in a multi-tenant environment. Value: any string. Typically a Hub or robot name.
Parent Hub name
 
os_user1
 
Tag added by the controller when sending internal messages directly to the Hub and by the spooler when any message is spooled.
 
os_user2
 
Tag added by the controller when sending internal messages directly to the Hub and by the spooler when any message is spooled.
 
capture_output
 
Creates pipes for each started probe to capture any output they send to stdout or stderr. This output is appended to the probe’s log file. Value: 
yes 
or 
no.
 
Enabling this functionality introduces extra overhead in the probe. On Windows systems, the probes must inherit resources from the controller. In some situations this might prevent the controller from terminating properly.
no
 
default_fail_window
 
Number of seconds a probe must run before its restart counter is reset. This setting applies to all probes managed by the robot. This value can be overridden for a particular probe by specifying a 
fail_window
 in that probe’s configuration.
15
 
default_priority_level
 
Numeric value that specifies the priority level for all probes that do not have this value set at the probe level. Probes with lower priority levels are started first, with a delay between each priority level.
Note that the 
start_after
 probe property gives you more control over the start order of probes.
None
 
max_restarts
 
Number of starts allowed before a probe is set to the error state. The restart counter is reset for a probe if it runs longer than its fail_window.
 
proxy_mode
 
Allows the controller to act as a proxy for probes. When on, all callback functions to the probes are performed through the controller port. Value: 
(off) or 
(on)
0
 
suspend_on_loopback_only
 
Suspend all probes if loopback is the only network. Windows only. Values: 
  •  
    yes
     – robot enters a "sleep" mode where all probes are suspended until a network connection is available
  •  
    no
     – alarm messages are spooled, then flushed when a network connection is again available
yes
 
set_qos_source
 
Specifies whether probes use the robot name as the QoS source instead of the host name. Not supported for all probes. Value: 
yes 
or 
no
.
no
 
system_uptime_qos
 
Specifies whether to send asynchronous QoS when the robot is up or down. Value: 
yes 
or 
no
.
no
 
alarm_level_comfail_restart
 
The alarm severity that is sent after the fourth unsuccessful attempt to communicate with a probe that has a registered port. Controller restarts the probe after alarm is sent. Values:
  •  
     no alarm
     
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
no alarm
 
alarm_level_dispatch_error
 
Severity level for an internal alarm indicating a socket system failure. Alarm is sent only if the log level is greater than 0. Values:
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
major
 
alarm_level_max_restarts
 
Severity level for the alarm that is sent when a probe is restarted and quickly terminates 10 times. Values:
  •  
    clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
major
 
alarm_level_postinstall
 
Severity level for the alarm that is sent when there is an error during probe distribution. This error occurs when the controller is unable to start a post-install script after distributing a package distribution, or if the post-install script does not return an "okay" (0) status. Values:
  •  
    no alarm
     
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
no alarm
 
alarm_level_request_error
 
Severity level for the alarm that is sent when the controller is unable to issue a request to distsrv. Values:
  •  
     no alarm
     
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
major
 
alarm_level_start_error
 
 Severity level for an alarm that is sent when unable to start a probe. Values:
  •  
     no alarm
     
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
major
 
alarm_level_suspended
 
Severity level for an alarm that is sent when a probe start is aborted because the robot state is suspended. Values:
  •  
     no alarm
     
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
no alarm
 
alarm_level_timed_error_return
 
Severity level for an alarm that is sent when a probe start is aborted because the robot state is suspended. Values:
  •  
     no alarm
     
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
warning
 
alarm_level_timed_not_finished
 
Severity level for an alarm that is sent when a timed probe is not completed at the next scheduled start time. The timed probe is restarted when this occurs. Values:
  •  
     clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
warning
 
alarm_level_unregister
 
Severity level for an alarm that is sent when a probe unregisters its port but does not terminate. Values:
  •  
    clear
     
  •  
     informational
     
  •  
     warning
     
  •  
     minor
     
  •  
     major
     
  •  
     critical
     
major
 
alarm_timeout
 
Interval, in minutes, at which alarms for probes in the error state are repeated.
 
wait_after_unregister
 
Wait time, in seconds, after a probe unregisters a port. If the process is still running, the unregister alarm is issued and the probe is set to the error state.
 
audit
 
 When and where to send audit messages. Values:
  •  
    post
     – Send audit message on controller events
  •  
    yes
     – Log controller events to local file
  •  
     post_detail
     – Send audit event on controller events and configuration file changes
  •  
     file_detail
     – Log controller events and file change events to local file
 
audit_checkpoint_count
 
Number of versions of configuration files to retain.
 
audit_max_config_size
 
Maximum size, in bytes, of the configuration file for content comparison.
 
config_locking
 
Signals the configuration tools that they should acquire a lock at startup and should relinquish it on termination. Value: 
yes 
or 
no
.
no
 
config_lock_timeout
 
Timeout, in seconds, for the configuration file lock.
360
 
startup_timeout
 
If the robot is a hub robot, specifies how long (in seconds) the controller waits for the hub probe to start before starting other probes. If the timeout is reached, the robot does a failover.
Deploy the XML File 
To deploy robots using USM, refer to the topic Deploy Robots in USM.
To deploy robots using automated_deployment engine, copy the host-profiles.xml file into the automated_deployment_engine probe directory. By default this directory is:
  •  
    Windows
     — C:\Program Files (x86)\Nimsoft\probes\service\automated_deployment_engine
  •  
    Linux
    Solaris
    AIX, and HP-UX
     — /opt/nimsoft/probes/service/automated_deployment_engine
Once host-profiles.xml is updated, deployment begins automatically. After processing host-profiles.xml, automated_deployment_engine renames it 
host-profiles-YYYY-MM-DD_HH-mm-ss
 to reflect the date and time of deployment. Renaming the file also ensures that if the automated_deployment_engine probe restarts, deployment does not automatically restart.
Deployment Notes
  • The automated_deployment_engine probe cannot deploy robots from an unchanged host-profiles.xml file. To restart a distribution, remove the date and time from the file name and change the file size by a nominal amount (for example, edit the file and add an extra line). Deployment begins within 30 seconds of the change.
  • After a robot is deployed, the scan waits for the robot to start before reporting its status in the history tab. The default wait time is set to 100 seconds. During this 100-second period, the automated_deployment_engine polls the robot every 25 seconds. If the robot does not respond within 100 seconds, the Hub declares the robot to be inactive.
    The delay time is controlled by the 
    verifyDelay
     key in the automated_deployment_engine configuration file (
    automated_deployment_engine.cfg
    ). Changing this value also changes the polling interval, which is always 1/4 of the delay time.
  • You can view the automated_deployment_engine log file (
    automated_deployment_engine.log
    ) for more information regarding robot deployment activity.
    You can use the 
    tail
     command on Unix-like systems to view the end of the text file.
  • The automated_deployment_engine probe installs robots in groups. The number of CPU cores on the Hub where the scan is running determines the group size.
  • If you are using 
    ADE REST 1.30
     calls and your passwords are encrypted, include the following line in the authentication portion of the REST XML:
    "nimcrypt" , "true"
  • If you deploy more than one instance of the automated_deployment_engine probe or specify a secondary Hub under 
    hubname
    , tasks are executed in this order:
    1. The primary instance of the automated_deployment_engine probe runs its deployment. 
    2. The primary automated_deployment_engine probe deploys any secondary instances. 
    3. The secondary probe instances execute their robot deployment tasks.