hub Release Notes

A hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection point. Hubs are commonly set up based on location (such as a lab or building) or by function (such as development). A hub can also connect other hubs into a hierarchy of hubs. Two types of hubs and robots are now available—secure (9.10S) and non-secure (9.10 and earlier). Hub and robot versions 9.10 and earlier use the legacy security model. Beginning with CA UIM 9 SP1, secure hub (9.10S) and robot (9.10S) are available, which further enhance the security mechanism in CA UIM.
uimpga-ga
hub_RN
A hub serves as the communication center for a group of robots. A hub binds robots into a logical group with the hub as the central connection point. Hubs are commonly set up based on location (such as a lab or building) or by function (such as development). A hub can also connect other hubs into a hierarchy of hubs. Two types of hubs and robots are now available—secure (9.10S) and non-secure (9.10 and earlier). Hub and robot versions 9.10 and earlier use the legacy security model. Beginning with CA UIM 9 SP1, secure hub (9.10S) and robot (9.10S) are available, which further enhance the security mechanism in CA UIM.
Support cases might not be visible to all customers.
3
Revision History
Version
Description
State
Date
9.33
(Released with UIM 20.3.3)
  • (9.32 HF2) Resolved an issue where users were able to see the cleartext passwords in the hub.log file when they were logging in using the Admin Console. (Support Case: 32475607)
  • Fixed an issue where the primary hub was restarting after every few minutes. The logs from controller and hub were not showing any relevant information about the issue. (Support Case: 32498752)
  • Fixed an issue where users were getting errors when they were trying to create tunnels on a hub. (Support Case: 32488645)
  • Fixed an issue where the enhanced security.cfg configurations were not propagating to one of the hubs in the environment. (Support Case: 32509796)
  • Fixed an issue where the AD/LDAP login through IM was failing. The hub was able to connect to the AD/LDAP server and fetch the group/user list, but the login was still failing. (Support Case: 32424406)
GA
March 2021
9.31
(Included in UIM 20.3.0)
What's New:
  • (7.97 HF9) Fixed a tunnel problem with robot 7.97 HF8 (2). (Support Case: 20325857)
  • (7.97 HF9) Fixed an issue where snmpgtw was interferring with hub. (Support Case: 20274225)
  • (9.20 HF11) Fixed an issue with LDAP Authentication being failed due to password hardness (characters set). (Support Case: 20302003)
  • (9.20 HF11) Fixed an issue with LDAP+SSL authentication while upgrading to UIM 20.1.0. (Support Case: 31829437)
  • (9.20 HF16) Fixed an issue where renaming a robot causes hub to send "robot inactive" alarms. (Support Case: 31888942)
GA
September 2020
9.30
(Included in UIM 20.1.0)
What's New:
  • (7.97 HF6) Fixed the following issues:
    • Fixed an issue in which the UIM primary hub was becoming unavailable. This issue was occurring because the CPU usage was higher due to continuous while loop. To resolve the issue, added sleep to avoid CPU consumption. (Support Case: 20032589)
    • Fixed an issue where the bulk size for a get queue was intermittently getting changed from configured amount to "blank". To fix the issue, on queue connection reset, used the configuration value for the queue bulk size. (Support Case: 01312205)
  • (9.10 HF4, 9.10S HF4, 9.20 HF6, and 9.20S HF6) Fixed an issue in which users were unable to log into IM and probe logins were also failing. The login information in UIM uses encryption mechanism that includes current date and time. In those scenarios where the encryption was producing a login string starting with NULL character '\0', the decryption was failing and the hub login was unsuccessful. This hotfix has resolved the issue. (Support Case: 20092472)
  • Fixed an issue where Perl nimalarm is blocked/suppressed by hub. (Support Case: 20083641)
  • Fixed an issue where the primary and secondary hubs connected via tunnels can no longer connect after SP1 - NOT SECURE update. (Support Case: 1353985)
  • Fixed an issue where UIM Primary Hub becomes unavailable. (Support Case: 20032589)
  • Fixed an issue with the hub not being able to import more than 100 groups. (Support Case: 20040934)
  • Fixed an issue with the hub which adjusts the  bulk size for a get queue from configured amount to blank. (Support Case: 1312205)
  • Fixed an issue with the LDAP groups which are not visible in admin console portlet. (Support Case: 20018982)
  • Fixed an issue with the tunnel server where it goes down when handshake failures occur repeatedly. (Support Case: 835880)
  • Fixed an issue with UIM going completely down. (Support Case: 20092773, 20092560)
  • Fixed an issue with the Passive Robots being showed up duplicate after restart of the HUB. (Support Case: 20067381)
  • A new configuration parameter epoll_wait_timeout has been introduced through which the user can set a different timeout. If the parameter is not specifically configured in hub.cfg then default value of 15 secs will be set. For Hub to Hub tunnel communication, this parameter needs to be configured in tunnel server hub (applicable for both Secure and Non-secure hubs) under Tunnel/server section of hub cfg. Valid values for this parameter are between 100 and 15000 (100 ms to 15 secs). (Support Case: 01353985)
GA
March 2020
9.20
(Included in CA UIM 9 SP1)
What's New:
  • (7.93 HF15) Fixed an issue in which alarms that were coming from a robot with no user tag were using the user tag that was specified in the primary hub's configuration. This was giving the incorrect information as messages that were not supposed to be processed were also getting processed because of the presence of the user tag that is used from the hub. To resolve this issue, a new configuration parameter (add_hub_user_tags_to_raw_data) has been introduced so that you can add user tags to the message only when you need. This parameter is added to the hub.cfg file. By default, this parameter is disabled (0). (Support Case: 01158176)
  • (7.93 HF16) Fixed an issue in which the hub spooler was not responding when the sysloggtw probe was sending the large amount of data and the error was of the type wsaewouldblock. To resolve this issue, a new parameter
    sock_write_retry_count
    has been introduced. This parameter lets you specify the number of tries the hub spooler must consider before it stops sending the message. Add this parameter to the hub section of the hub.cfg file. (Support Case: 01116951)
  • Fixed an issue in which the hub probe callback (hubsec_list) was not working with the pu utility. (Support Case: 01203568)
  • Fixed an issue in which when users were trying to create a tunnel server, using Infrastructure Manager on the secondary hub, the hub configuration window was not starting. Therefore, users could not configure the tunnel server using IM on UIM 9.0.2. (Support Case: 01258814)
  • (7.97 HF3 and 7.93 HF17) These hotfixes resolve the following issues:
    • Fixed an issue in which some hubs were being displayed as red in IM; however, when users clicked them, they were immediately getting displayed as green. This was creating a false sense of problem with users spending unnecessary time on trying to investigate the problem. (Support Case: 01220272)
    • Fixed an issue in which the QOS_POWER_STATE metric had missing values in the RN_QOS_DATA table. For example, the QoS interval of the power state metric was 5 minutes. So for a 24-hour window, the expectation was to collect 288 (24*12) metrics. However, only 280 records were added to the RN_QOS_DATA table. This was affecting the availability calculation. (Support case 01304869)
  • Fixed an issue in which hubs were sporadically going red in IM and AC after implementing tunnels. And, when you clicked them, they were displaying correctly. (Support Case: 01195957)
  • Fixed an issue in which users were getting the following error and the primary hub was repeatedly creating temporary connections: (Support Case: 01161603)
    The Hub <hub_name> has too many active subscribers (<count>). You should consider offloading some of the subscribers to another Hub.
  • Fixed an issue in which a user was facing problems with security settings in the primary hub. After upgrading to CA UIM 9.0.2, the user could not see remote hubs in IM. (Support Case: 01279980)
  • Supports MD5 and PBKDF2 hashing algorithms for encrypting the user password in the security.cfg file.
    • If you create any new user with hub 9.10 (or 9.10S), PBKDF2 is used to encrypt the user password. This implies that such users cannot work with the previous hub versions (7.97 and earlier), because previous hub versions support only MD5.
    • If users that are already created with previous hub versions (7.97 or earlier) try to log in to hub 9.10 (or 9.10S), they can log in without any issue, because the new hub versions support both the algorithms.
  • (7.95 HF1) Introduced a new configuration parameter validate_ip_suggestion to process the robotip field in the answer file. When you set the validate_ip_suggestion parameter value to 1, the parameter correctly finds the IP (from the list of IPs specified in the robotip field) that matches the computer IP. When you enable this parameter, you must disable the local_ip_validation parameter. The following issues have been fixed with this update:
    • Robot IP was not working in the answer file. (Support Case: 01189561)
    • Installer was not adding new configuration parameters on Linux and AIX. (Support Cases: 01221346 and 01221360)
    • All nimsoft utilities were failing when strict_ip_binding was set to TRUE. (Support Case: 01242592)
    • Controller was not handling the robotip value greater than 128 characters. (Support Case: 01263533)
    The value of the robotip parameter must not be higher than 2048 characters.
  • Fixed an issue in which the emailgtw probe was restarting the hub probe.The emailgtw probe was configured and deployed on the primary hub to send emails with alarms from nas (AO). The emails were going to the recipients defined on AO. However, because the emailgtw probe was active, the hub probe was restarting frequently. If the emailgtw probe was deactivated, the restarts were stopping. (Support Case: 01317795)
  • Fixed an issue in which hub 7.97 was not able to connect to the hub 7.80 with tunnels. (Support Case: 01311594)
  • CA UIM 9.2.0 has adopted OpenJDK 8u212 instead of Oracle JDK. Because of this change, CA UIM 9 SP1 (9.1.0) that was using Oracle JDK (JRE) 8u212 is no longer available and has been removed from the Support site. All the functionality that was included in 9.1.0 is now released as part of CA UIM 9.2.0. Consequently, all references to the 9.1.0 release and the probe version 9.10 (released with it) have also been removed from this probe documentation. We recommend that you move to this version 9.20 of this probe, as the previous version 9.10 is no longer available now. For more information about the OpenJDK usage in CA UIM, see  Adopting OpenJDK .
GA
August 2019
7.97
  • Updated to support the Microsoft Visual C++ Redistributable for Visual Studio 2017 package version 1.01 (vs2017_vcredist_x86 1.01 and vs2017_vcredist_x64 1.01). This support helps ensure that the minimum version of the VS 2017 package is equal to or greater than 1.01. With this dependency on version 1.01, the computer is no longer getting restarted automatically when installing the VS 2017 package. That is, with v1.01, no auto-restart of the computer happens.
  • Better handling of the spooler plug-in. For example, when hub 7.96 (compiled with vs2017_vcredist_x86 1.0 and vs2017_vcredist_x64 1.0) tries to load plugin_metric (compiled with Microsoft Visual C++ Redistributable for Visual Studio 2008), the hub stops responding. This happens because of the compiler incompatibility. Now, with this release of the probe, which is dependent on vs2017_vcredist_x86 1.01 and vs2017_vcredist_x64 1.01, hub no longer loads the plugin (plugin_metric) if it is not compatible.
GA
December 2018
7.96
Included in CA UIM 9.0.2
What's New:
  • Added the ability to monitor, at specific intervals, if robots deployed on a hub are powered on. You need to manually add specific parameters to the hub configuration to enable this. For more information, see Additional parameters in hub 7.96.
  • Provided support for Red Hat Directory Server 10 (RHDS 10) as an LDAP Server. (Support Case 00528637)
  • Provided support for communicating with an OpenLDAP server that is configured with TLS v1.2. This implies that if TLS v1.2 is enabled on an OpenLDAP server, hub 7.96 (or later) can now communicate with it.
    While providing information in the
    LDAP Authentication
    section (available under
    Hub Advanced Settings, LDAP, LDAP Settings
    ), ensure that you also select the
    Use SSL
    option.
  • Updated this probe as part of removing dependency on the end-of-life (EOL) Microsoft Visual C++ Redistributables in CA UIM 9.0.2. CA UIM 9.0.2 now uses Microsoft Visual C++ Redistributable for Visual Studio 2017.
  • Updated this probe as part of removing known security vulnerabilities in CA UIM 9.0.2 by using upgraded OpenSSL components.
  • (7.93HF12) Fixed the issue where USM was ignoring the severity of hub alarms. The alarms were showing up under hub in USM; however, the severity icon was not changing for these alarms to reflect the correct severity. With this fix, USM no longer ignores the severity of hub alarms; it now displays the correct severity icon for them. (Support Case 01115256)
  • Removed support for the following platforms:
    • RHEL 5 (32-bit and 64-bit)
    • Windows 2008
    • CentOS 5 (32-bit and 64-bit)
    • Debian 5 and 6
  • Removed support for the following 32-bit platforms:
    • Solaris 10 and 11
    • RHEL 6
    • CentOS 6 and 7
    • SUSE 11
    • OpenSUSE 12 and 13
  • Changed the default check_spooler_sessions setting in hub.cfg to 1 = ON.
  • Changed the default protocol_mode setting in the tunnel section of hub.cfg to 3 = ON.
  • Changed the default value of the max_heartbeat setting in the tunnel section of hub.cfg to 1800 ms.
  • Changed the default value of the postroute_interval setting in hub.cfg to 120.
  • Changed the default value of the postroute_reply_timeout setting in hub.cfg to 180.
  • Changed the default value of the postroute_passive_timeout setting in hub.cfg to 300.
  • Changed the default value of the hub_request_timeout setting in hub.cfg to 120.
  • Changed the default value of the setting tunnel_hang_timeout = 300 in hub.cfg.
  • Changed the default value of the setting tunnel_hang_retries = 3 in hub.cfg.
  • Updated this probe as part of adding support for TLS v1.2 in CA UIM. This support establishes secure communication with the UIM database: Microsoft SQL Server and Oracle in CA UIM. For more information about how to enable TLS v1.2 support in CA UIM, see TLS v1.2 Support for Microsoft SQL Server and TLS v1.2 Support for Oracle.
Fixed Defects:
  • The default queue bulk size no longer changes to 1 when other changes are made to the queue. (Support Case: 797687)
  • Fixed an issue in which a Linux hub was automatically restarting because of the number of open file descriptors reaching out the hard-coded maximum limit of 999. (Support Case: 00291708)
  • (7.93HF1) When the LDAP server is down and you restart the hub, the hub starts responding quickly; it no longer remains unresponsive. (Support Case 831283)
  • Fixed an issue in which qos_processor was intermittently failing to delete the queue properly, (Support Case: 00815516)
  • Corrected an issue in which hub was not closing the spooler connections. There were several open connections from spoolers on the hub that were not getting closed. (Support Cases: 00750385 and 00803374)
  • Fixed an issue where access to the admin console outside the primary hub server resulted in a HTTP status 408 error. (Support Case: 01195550)
GA
October 2018
7.93
What's New:
  • (7.92HF4) Added support for multiple LDAP Servers.
    • The hub can be configured to attempt to query one or more backup LDAP servers in the event the primary LDAP server fails to respond to requests.
    • In Infrastructure Manager, open the hub configuration. Select the
      Settings
      button on the
      General
      Tab, then select the
      LDAP
      tab. When
      LDAP Authentication
      is selected, you can supply a list of LDAP servers to be contacted, in order, for LDAP authentication requests.
    • The purpose of the search is for secondary LDAP server backup in the event that connection fails to the primary LDAP server.  If connection fails to the first LDAP server in the list within three seconds (non-configurable), connection to the next LDAP server in the list is attempted. Each server in the list has three seconds to respond. The overall timeout for all servers in the LDAP server list is ten seconds. This means that you can provide a maximum of three LDAP servers in your list, because the overall timeout of ten seconds will be exceeded before a fourth server can be contacted.
    • The first server in the list to respond before the three second timeout is queried to authenticate the requested user account. If the user cannot be authenticated by this LDAP server, no additional LDAP servers in the list are queried for authentication, and the user is not authenticated.
    • The format of the LDAP server list in the Server Name field is as follows:
      • <LDAPServer1>[:/ <port>],<LDAPServer2>[:/ <port>],...
      • If a port number is not supplied, the default LDAP port, 389, is used. The LDAP server name can be separated from a supplied port number with a colon or a space.
      • Separate multiple LDAP server entries with commas.
  • (7.92) In addition to the operating systems listed below, support for SuSE 11 or later secondary hubs and robots is added:
    • If you are installing your hub or robot on one of the following operating systems:
      • CentOS 7 or later
      • Red Hat 7 or later
      • SuSE 11 or later
      • openSuSE 13 or later
      • Debian 8 or later
    • You must enable the nimbus service after your
      nimldr
      installation is complete. To enable the nimbus service, execute:
      • systemctl enable nimbus.service
    • Once the service is enabled, execute the following command to start the nimbus service:
      • /opt/nimsoft/bin/niminit start
  • (7.92HF1) By default, changes to
    security.cfg
    are propagated from any hub. Two configuration keys affect this behavior:
    • Set
      secure_callbacks_from_primary_hub_only
      in
      security.cfg
      . Default: no
      • When the key is set to yes:
        • The primary hub propagates security changes to all hubs in the domain. When this value is set to no, a hub only propagates security changes to nearby hubs. Nearby hubs are hubs that are one level away.
        • A secondary hub rejects security updates from other version
          7.92HF1
          and above secondary hubs. Updates from
          pre-7.92HF1
          secondary hubs and primary hubs are accepted. Accepting updates from
          pre-7.92HF1
          hubs eases an incremental upgrade.
        • A user cannot make security-related callbacks on a secondary hub. Security-related callbacks include:
          • user_change_password
          • user_delete
          • user_edit
          • user_new
          • probe_delete
          • probe_new
          • profile_delete
          • profile_delete_ex
          • profile_put
          • profile_put_ex
          • profile_users_set
          • hubsec_delete
          • hubsec_edit
          • hubsec_new
          • hubsec_restore
          • hubsec_setup_put
          • hubsec_update
        • When a probe is installed, the secondary hub receives a request to add a probe to the security file, this request is forwarded to the primary hub. The primary hub then executes the request and propagates the security file update to all the other hubs in the domain.
        • When
          secure_callbacks_from_primary_hub_only
          is disabled, the primary hub propagates the change to all other hubs before disabling it in itself.
        • This value is changed with the
          hubsec_setup_put
          callback.
    • Set
      security_config_propagation
      in
      hub.cfg
      . Default: yes
      • When the key is set to yes, the hub can propagate updates to
        security.cfg
        to all other hubs in the domain.
      • When the key is set to no, the hub cannot propagate updates that it receives.
      • The primary hub ignores the value of this key, and propagates updates even when the key is set to no.
      • This value must be explicitly set in each
        hub.cfg
        file. Restart the hub for the change to take effect.
    • The following configuration is recommended for all domains:
      • Set
        secure_callbacks_from_primary_hub_only
        to yes.
      • Set
        security_config_propagation
        to no.
      • This combination ensures that:
        • Security updates propagate from the primary hub only.
        • Security updates propagate to all the hubs in the domain, regardless of the proximity to the primary hub.
  • (7.92HF6) To improve the throughput performance of tunnel communication between hubs in a high latency network, data compression can now be configured.
    • Hubs that send data can be configured to compress the data before it is sent through a tunnel to a receiving hub. Install this fix and configure the tunnel to enable compression on sending hubs where network latency is an issue.
    • Install this fix on every receiving hub connected by a tunnel to a sending hub that is running this fix with compression enabled.
    • You enable compression and configure the level of compression on
      sending
      hubs. When the fix is installed on receiving hubs, compression is automatically detected and messages are automatically decompressed.
    • To enable compression on a
      sending
      hub, take the following steps:
      1. In Infrastructure Manager or Admin Console, stop the sending hub.
      2. On the sending hub, edit the hub configuration file,
        $
        UIMHOME
        /hub/hub.cfg
        .
        1. Add the new key
          tunnel_compression
          in the
          /tunnel
          section of
          hub.cfg
          . Default, 0.
          • A value of 0 specifies that tunnel compression is off.
          • A value of 1 specifies that tunnel compression is on.
        2. (Optional) Add the new key
          compression_level
          in the
          /tunnel
          section of
          hub.cfg
          .
          • Set the value between 0 and 9. Default, 0.
            • A value of 0 specifies the least level of compression.
            • A value of 9 specifies the greatest level of compression. Higher levels of compression reduce network traffic, but take additional time to construct.
        3. (Optional) Add the new key
          min_compression_size
          in the
          /tunnel
          section of
          hub.cfg
          . The key specifies the  message size that will be compressed. Default, 1400b.
      3. Save your changes to
        hub.cfg
        .
      4. In Infrastructure Manager or Admin Console, start the hub.
      5. To verify that the compression is working, search both hub log files,
        hub.log
        .
        1. At log level 1, a log entry indicates the state of compression,
          compression=
          value
          . Compression is off when the value is 0, and compression is on when the value is 1.
        2. At log level 5, the log contains an entry for each compressed or decompressed PDS:
          1. Sender log message:
            • compressPDS:<num> bytes compressed to <num>
          2. Receiver log message:
            • decompressPDSs: HEAD <num> bytes decompressed to <num>
              • or
            • decompressPDSs: BODY <num> bytes decompressed to <num>
Fixed Defects:
  • (7.92HF1) A problem which caused the primary hub to crash with a segmentation fault is now fixed. (Support Case 00652137)
  • (7.92HF4) Fixed an issue where robot install fails on Windows but appears succeed when the
    PATH
    is not set in the
    <environment>
    section of
    robot.cfg
    . Robot install now fails when the
    PATH
    is not set. (Support Case 00732914)
  • (7.92HF4) Fixed the issue of being unable to save probe config changes after
    secure_callbacks_from_primary_hub_only
    is enabled (hub 7.80 HF23) (Support Case 00291708)
  • (7.92HF5) If you create a new Solaris zone, a robot installed in the global zone is not automatically deployed to the new zone. To install a robot in a new, non-global zone, install the robot into the non-global zone using the same steps that you use to install the robot in the global zone. (Support Case 746015)
  • (7.92HF5) Fixed a problem where false application down alarms were triggered during AIX startup because the robot started before the monitored application. (Support Case 707038)
  • (7.92HF8) When secure_callbacks_from_primary_hub_only is enabled, requests to add the probe to the security file are not forwarded to a primary hub in a different domain.
  • (7.92HF8) Fixed an issue where creating a queue with an empty
    Subject
    field caused the hub configuration UI in Admin Console to report an error and fail to open. (Support Case 00648129)
  • (7.92HF6) Fixed an issue where user_tags were overwritten by the hub spooler. Now, the hub spooler only sets the user_tags if they are empty.
  • (7.92HF7) An issue was fixed that caused robots to failover to the secondary hub sooner than expected, appearing to ignore the configured failover interval. Failover is now deferred until the following
    _status
    criterion is met. A failed
    robotup
    update now prints a log message and does not initiate robot failover until the
    robot_failover_count
    number of
    _status
    requests have failed. Specify
    robot_failover_count
    and
    robot_status_check_interval
    in
    robot.cfg
    to control the number of failures required to initiate failover, and the interval at which
    _status
    is checked.Failover occurs between
    [(robot_failover_count - 1) * robot_status_check_interval] and [robot_failover_count * robot_status_check_interval]
    The window allows for cases where the hub stops responding either just before or just after a
    _status
    check.
    • Before the fix, four other conditions triggered immediate failover. These conditions are no longer considered:
      • A failed
        alive
        message from the robot to the hub; controlled by the
        hub_update_interval
        and
        send_alive
        properties.
      • A failed
        robotup
        message from the robot to the hub.
      • A failed
        probelist
        or
        probeportlist
        message from the robot to the hub.
      • A
        check_hub
        callback to the controller, which occurs when the hub is not responding.
  • (7.92HF8) An issue was fixed that caused robots with plugins to not completely release memory on Windows. (Support Case 00791437, DE307126)
  • (7.92HF10) Improved performance between the hub spooler and controller. (Support Case 00687052, 00676791)
  • (7.92HF10) Corrected an issue where hubs intermittently show as yellow until selected in the GUI.
  • (7.92HF10) The nexec configuration no longer fails when LDAP is enabled. (Support Case 00245766, 00799227)
  • (7.92HF10) Alerts now clear for stopped probes once a probe starts running. (Support Case 00723878)
  • (7.92HF10) Hubs no longer overwrite the primary_hub status if the field is not supported by a hub version.
  • (7.92HF10) Added a variable to hub.cfg that provides a mechanism to periodically close spooler sessions that are in a half-closed state. The check_spooler_sessions variable is set to 0=off by default. When set to 1=on, the spooler sessions are closed.
  • Corrected a tunnel stability issue in which hubs would turn red and become unresponsive in Infrastructure Manager and Admin Console. (Support Case 00824936)
Corrections Made to the Fixed Defects Section
  • Removed the following incorrect information from the above
    Fixed Defects
    section. The following entries are not applicable for fixed defects in 7.93:
    • (7.92HF10) Duplicate host names across tenants no longer cause data leaks when the same metric is collected against a target with the same name.
    • (7.92HF8) Duplicate hosts names shared by multiple tenants are now correctly reported to all interested tenants.
  • The following section has been revised to correct the target configuration file. This configuration must be set in robot.cfg instead of hub.cfg:
    • (7.92HF7) An issue was fixed that caused robots to failover to the secondary hub sooner than expected, appearing to ignore the configured failover interval. Failover is now deferred until the following
      _status
      criterion is met. A failed
      robotup
      update now prints a log message and does not initiate robot failover until the
      robot_failover_count
      number of
      _status
      requests have failed. Specify
      robot_failover_count
      and
      robot_status_check_interval
      in
      hub.cfg
      to control the number of failures required to initiate failover, and the interval at which
      _status
      is checked.Failover occurs between
      [(robot_failover_count - 1) * robot_status_check_interval] and [robot_failover_count * robot_status_check_interval]
      The window allows for cases where the hub stops responding either just before or just after a
      _status
      check.
GA
October 2017
7.91
What's New:
  • To improve tunnel stability, set
    protocol_mode=1
    in the
    <tunnel>
    section of
    hub.cfg
    for all tunneled hubs.
  • Two new hub parameters specify the amount of time a queue waits for an acknowledgment before re-sending data to a subscriber.
    • postroute_reply_timeout
      specifies a global timeout setting that applies to all hub queues. Specify this value in the
      <hub>
      section of
      hub.cfg
      .
    • reply_timeout
      specifies the reply timeout setting on a per queue basis. This value overrides the global
      postroute_reply_timeout
      for the specific queue. Specify this setting in the
      <postroute>/<
      name_of_queue
      > section of
      hub.cfg
      .
The default reply timeout for a queue is 60 seconds. Setting the timeout value to zero (0) specifies no timeout (infinite wait). The settings apply to attach-get queues and post queues. If the value specified for an attach queue is not equal to the value set for the corresponding get queue, the value for the get queue is used. If the subscriber is a probe, the probe timeout value overrides the attach queue value.
  • A new property,
    robot_missed_update_count
    , specifies how many consecutive missed updates from the robot must occur before the hub begins issuing
    robot is inactive
    alarms. Specify the property in
    hub.cfg
    . Default, 2.
  • Updated Novell C LDAP libraries to the mid-2015 release. The version varies by platform. For Linux x64 the version is 098ZW.
  • If no
    min_bulk_size
    is specified by the subscriber, the
    min_bulk_size
    set on the attach queue is now used.
  • Support for Solaris as a primary hub is discontinued. Secondary hubs on Solaris are supported.
Fixed Defects:
  • Tunnel stability is improved. Hubs no longer appear to randomly switch between available and unavailable. Probe configuration UIs in Infrastructure Manager and Admin Console can be accessed across a tunnel. (Support Case 466247)
  • A problem with file descriptors for SSL, which could cause a hub to crash is now fixed.
  • Hub keep-alive heartbeat support is added for temporary queues.
  • Hub queue parameters
    min_bulk_size
    and
    min_bulk_wait
    are not working.
  • Support for LDAP anonymous simple binds is removed. LDAP anonymous simple binds are now explicitly denied. Valid credentials are required to query LDAP.
  • Added logic to prevent
    name-to-ip
    requests to an unresponsive hub.
  • Simplified the timeout logic for forwarded
    name-to-ip
    requests to the hub. (7.80HF9)
  • NAS subscription does not reset as expected when a problem is detected.
  • Allow UTF-8 characters in database login user name.
  • Hub crashes on restart if
    hub.cfg
    contains a static hub entry with the same name.
  • Invalid robot is inactive messages.
  • Hub and robot can crash when the logging level is set to 5 and a callback reply contains nested PDSs.
  • Logging is improved by moving some hub messages from log level 3 to log level 5. (Support Case 169553)
  • Queues and tunnels reestablish connections more reliably after a network outage.
  • Hub main thread blocks for seconds to minutes.
  • Hub does not attempt to reconnect to an unresponsive LDAP server when it comes back online.
  • Hub spooler experiences a catastrophic queue error when attempting to read a corrupt PDS file, and good PDS files are discarded. (Support Case 379065)
  • Volume of SSL Layer Error 5 messages is now reduced in the hub log file.
  • Extended_source is missing from QoS and Alarms from snmpcollector v3.2.
GA
April 2017
7.80
What's New
:
  • Added support for OpenSSL TLS cipher suites
    • When using TLS 1.1 or 1.2 cipher suites, include an alternative fallback to SSLv3. Fallback ensures backward compatibility between older robots and a new hub, or probes that connect to a robot using SSL. For example, AES128-SHA256:RC4-SHA, where AES128-SHA256 is TLS v1.2 and RC4-SHA is SSLv3.0
  • OpenSSL 1.0.1m implemented
  • Windows IA64 and RHEL/CentOS-5 are no longer supported
  • User tags are automatically copied from robot.cfg to hub.cfg when upgrading to hub v7.80.
    During a restart of the hub, user tags are copied:
    • If user tags do not exist in the
      hub.cfg
      file
    • If the
      os_user_retrieve_from_robot
      option is true (default)
      • After the user tags are copied, the
        os_user_retrieve_from_robot
        option is set to false in the
        hub.cfg
        file.
      • Clear the user tags in the
        hub.cfg
        file later by setting the os_user_retrieve_from_robot option to true, and restart the hub.
    • For alarms that the hub sends about robots, the default behavior for user tags is equivalent to hub v7.63. In hub v7.63, the user tags are set to the tags of the robot representing the alarm.  This behavior only applies to the special case of hub robot alarms, and not to other alarms and messages.
    • The output information contains the robot user tags in the
      user_tag_1
      and
      user_tag_2
      fields.
      Added
      context
      user tags represent the hub user tags.  Context user tags provide the user tags from the source of the alarm, and are included in the message.
    • A new configuration option in the
      hub.cfg
      file,
      os_user_robot_alarms_use_hub_tags
      , allows you to revert to the behavior of hub v7.70.
      • If the option is 0 or the option is not defined, hub v7.63 behavior applies to
        user_tag_1
        and
        user_tag_2
        .
      • If this option is set to 1, the behavior of hub v7.70 applies.
        User tag changes do not affect robot alarms that come directly from the robot. Hub generated robot alarms, which occur when a robot or probes start or stop,
        are
        affected.
  • Removed ability to set SIDs with pu command.
    In past releases, the
    -S
    option of the
    pu
    command could be used to set an explicit
    session identification
    (SID). This capability has been removed to prevent a security bypass through SID injection.
  • Output character limit extended in pu executable
    . In the
    pu
    executable before v7.80, field output from callbacks was limited to around 35 characters. A long output string might become unusable. To resolve the issue, the output limit is extended to 300 characters.
GA
June 2015
7.71
Hub v7.71 fixes an issue in hub v7.70 with assigning ports for tunnel client connections. Before v7.70, the tunnel client connections would consistently use the 48xxx port range (based on the controller default
first_probe_port
setting of 48000). An issue in hub v7.70 caused the tunnel client connections to use a system assigned port number. System assigned port numbers do not reliably fall in the 48xxx range. This caused issues with firewalls where the tunnel ports were explicitly allowed and expected to be in the specific range.
With hub v7.71, the default port range for tunnel client connections again falls in the 48xxx range. As in previous versions, the specific ports for tunnel connections can be overridden by enabling
Ignore Controller First Probe Port
(which enables the hub to use its own setting) and by specifying the desired port setting
tunnel/ignore_first_probe_port = 1
and
tunnel/first_tunnel_port =
portnumber
in the hub configuration file,
hub.cfg
:
  • In the Admin Console hub configuration UI, navigate to
    Advanced, Tunnel Settings
    . Under
    Tunnel Advanced Settings
    , enable
    Ignore Controller First Probe Port
    . Specify the desired
    First Tunnel Port
    .
  • In the Infrastructure Manager hub configuration UI, navigate to
    Tunnels
    . Enable
    Ignore first probe port setting from controller
    , and specify the desired
    First Tunnel Port
    .
GA
March 2015
7.70
Important:
We recommend that you connect hubs with tunnels (see Best Practices for Hub-to-Hub Communication). Hubs require tunnel connections. Without tunnels, hubs set to mode 0 (no encryption) cannot communicate with hubs set to mode 2 (SSL encryption). See Impact of Hub SSL Mode When Upgrading Nontunneled Legacy Hubs.
New Features:
  • SuSE10 and SLES11 are no longer supported.
  • Hubs allow robots to retain the origin of their designated parent hub when failing over to a secondary hub.
    The origin is attached to each QoS message generated by a probe and routed through its robot.
    • By default, the origin is the name of the designated parent hub of the robot. The origin is attached to messages by the hub spooler.
    • The default origin that is used upon hub failover has changed. When a robot with no specified origin failed over to another hub, the origin was changed to the failover hub. Now, the origin is the name of the robot designated parent. Specify the origin in the
      hub
      attribute in
      robot.cfg
      .
      Note: CA UIM administrators can override the default value by defining the origin in the robot configuration file
      robot.cfg
      . In multi-tenant environments, an admin can specify the origin for grouping data and control user access to the data.  If the origin attribute exists in robot.cfg, the robot spooler attaches it to the message. The hub spooler does not alter the origin. This behavior has not changed.
      The
      os_user_include
      option, which enabled the hub to read user tags from
      robot.cfg
      , has been removed. Now, the hub does not read user tags from
      robot.cfg
      . If the hub robot has defined user tags, they remain in
      robot.cfg
      after the upgrade, but the tags are ignored. To add user tags to hub probe alarms and messages, specify the user tags in
      hub.cfg
      .
    User tags are propagated by the hub and controller. User tags are now propagated in alarms and messages by both the hub and the controller. Previously, both the hub and controller read user tags os_user1 and os_user2 from
    robot.cfg
    . Now, the hub reads user tags from
    hub.cfg
    . The General Configuration section in the Admin Console hub configuration UI allows users to specify os_user1 and os_user2. On a hub system, the hub spooler adds these values to probe generated alarms and messages. On a robot system, the robot spooler adds the tags.
  • Hub v7.70 can be configured to send an alarm for dropped messages.
    Probe messages use the subject for routing in the message bus. The spooler drops messages If a subject is not configured in a hub attach or post queue.
  • If a subject is not configured in a hub attach queue or a post queue, the spooler drops the message. Hub v7.70 can send an alarm when a message is dropped. This behavior is disabled by default. To enable it, specify the following parameter in
    hub.cfg
    :
    subjects_no_destination_alarm_interval=
    seconds
  • Consistent enforcement of username and password limitations
    • The username must be 1 through 255 characters long.
    • .The username cannot contain control characters, right or left arrows (< or >), or forward slashes (/).
    • The password must be 5 through 254 characters long.
  • Improved behavior of SSL mode
    • If a hub controller sets SSL mode=0, the controller does not create a
      robot.pem
      file at startup. Any CA UIM components that are installed on that system do not accept SSL connections.
  • Improved DNS lookup during tunnel setup
    • DNS lookup, which maps the host name to an IP address, retries on DNS failures. Tunnels are more tolerant of temporary or intermittent network failures.
Fixed defects:
  • General stability and robustness are improved.
  • The original configuration is retained when changes to the hub configuration cannot be saved because the file system is full.
  • Hub support for LDAP over SSL is improved.
  • Files and directories in
    hub/q
    are properly cleaned up when queues are removed.
  • The
    tunnelsetup
    command properly imports tunnel client certificates.
  • The controller does not assign probes to ports used by hub tunnels. Ports are assigned to the correct interfaces based on strict binding mode.
  • Proxy_mode
    routes all callbacks to the probes through the controller port. Robots which are configured for
    proxy_mode
    , return to the designated parent hub after failover.
December 2014
7.63
  • OpenSSL 1.0.0m is implemented
  • LDAP reliability is Improved when an SSL connection to the LDAP service is required.
  • Stability for long queue names is Improved (
    Salesforce case 00145363)
  • The CA UIM Server 8.1 distribution includes the package.
Fixed defects:
    • Circular message queues caused memory resource leaks (
      Salesforce
      case 00147673)
    • If the
      baseline_engine
      and the
      prediction_engine
      are deployed to a hub, a file descriptor resource leak can occur.
    • A potential crash condition that is caused by invoking the
      tunnel_get_info
      callback.
    • A potential crash condition when stopping a robot
August 2014
7.61
  • Improved tunnel stability
  • Package included in CA UIM Server 8.0 distribution
June 2014
7.60
  • Improved socket management between two hubs that are connected by a tunnel
  • Long-running callbacks over a tunnel connection cause fewer communication errors
  • Queue status alarming has been refined to reduce false positives
  • LDAP directories with large numbers of groups are handled more efficiently when paired with UMP 7.6
  • Package included in NMS 7.6 distribution
March 2014
7.50
  • Tunnel and queue connect and disconnect alarms are retroactively reset to the Information level matching their actual meaning and impact.
  • The hub detects when the total resources in use threaten tunnel or hub viability. The hub reacts by either resetting the tunnel or restarting the process, without data loss.
  • The origin for probes local to a hub can be set independently from the origin of the hub.
  • Enhanced LDAP and user level security and improved support of LDAP environments with large numbers of groups
  • Improved tunnel stability
Fixed defects:
    • A core dump on Solaris when
      hubup
      response contents are malformed
    • A significant number of sockets are temporarily left in the
      CLOSE_WAIT
      state when hubs communicate with many child robots
    • Duplicate tunnel connections between the same client and server permanently disconnect the tunnels due to the exhaustion of threads
January 2014
7.11
  • Improved the method for determining the status of get-attach queues that carry low volumes of data
  • Tunnel server TCP sockets are more efficient
  • A problem that could cause the number of sockets to grow unbounded is addressed
Fixed defects:
    • High-volume deployments when the hub is used as an LDAP proxy hub
    • High-volume deployment when hub is used with the snmpcollector probe
Upgrading to hub 7.97
If you are upgrading to hub 7.97, ensure that you first upgrade the robot to 7.97, and then upgrade hub to 7.97.
Best Practices
While most hubs perform well with little interaction from the administrator, you can modify various configuration settings for better performance.
    • Hub and robot version
      • Update to the latest version of hub and robot on all the hub servers. We recommend maintaining the same version on all hubs and robots.
    • Hub-to-hub communication
      • Use tunnels to keep the communication connectivity intact between hubs.
    • Tunnels
      • Caching the SSL sessions can significantly speed up the server to client connection time.
    • Queues
      • Increasing the
        Bulk Size
        of the queue allows the hub to transfer multiple messages in one packet. Increase the
        Bulk Size
        when:
        • The size of a get or a post queue never shrinks to zero
        • Too many messages are queued
Known Issues
    • The ppm probe provides functionality for the Admin Console probe configuration UIs. The ppm probe does not run on AIX hubs. To configure robots and probes on AIX hubs, use the Raw Configure utility in Admin Console, or use Infrastructure Manager.
    • If the communication with a robot fails in Linux, review your network configuration:
      • A valid entry for the local system in the
        /etc/hosts
        file for a robot, hub, server, or UMP system
      • The entry for the local system must be a fully qualified host name and IP address.
      • If only the loopback address is defined, for example, localhost 127.0.0.1, the controller is unaware of its own IP address.
      • IP address problems result in network communication failure.
    • The automated_deployment_engine robot distribution to Windows targets sometimes fails to activate the hdb and spooler probes. To resolve the issue, do a validate security on the affected probes (hdb and spooler)
    • Origin issue on failover in hub v7.1 through v7.63:
      • Robots do not retain the configured origin when they connect to a failover hub
    • If robots are added to the inventory by automated discovery, USM cannot auto-deploy the robots to AIX or z/Linux systems. Use one of the following alternative methods:
    • In high-volume deployments, hub v7.10 might have issues when the hub is used in the following situations:
      • As an LDAP proxy hub
      • When used with the snmpcollector probe
      • These problems are addressed in hub v7.11 and later
    • Inactive queues might negatively affect hub v7.10. when the hub is used as a tunnel server:
      • The number of Windows file handles and Unix file descriptors might grow over time
      • The growth rate increases greatly when the tunnel server is servicing get queues that carry little or no data
      • Get queues can reset regularly
      • As the number of resources in use becomes large, the hub might automatically restart. The hub returns to normal operation, and no data loss is expected. These problems are addressed in hub v7.11 and later.
Additional parameters for robot availability in hub 7.96
You can now create an ad hoc report in CA Business Intelligence (CABI) to monitor the availability of robots that are deployed on a hub.
You need to add the following new parameters to the hub configuration which checks if the robots deployed on that hub are powered on, at specified intervals.
    • robot_power_state_metric_enable
      = default value is 1 (enabled)
    • robot_power_state_metric_interval
      = default value is 5 mins
The primary assumption for this ad hoc report is that if the robot is down then the target system where the robot is deployed is also down.
Impact of Hub SSL Mode When Upgrading Nontunneled Hubs
The 7.70 release of the CA UIM hub and robot improve the robustness of SSL communication. The hub SSL mode specifies the communication mode of hub-managed components. SSL mode is primarily used for robot-to-hub communication. SSL mode is used for hub-to-hub communication when hubs are not connected with tunnels.
Before hub v7.70, in a nontunneled domain, hubs that are configured for unencrypted communication can decode encrypted messages. In a multiple hub domain, upgrading to v7.70 breaks this communication.
Note:
  Any tunnels set up between hubs will remain after you upgrade, and communication will continue.
We strongly recommend that you connect all CA UIM hubs with tunnels to ensure the integrity of hub-to-hub communication.
SSL Communication Mode
CA UIM hubs have three communication mode options:
    • SSL mode 0
      — No encryption
      • The OpenSSL transport layer is not used
    • SSL mode 1
      — Compatibility mode
      • The hub and robot communicate either without encryption or with OpenSSL encryption
    • SSL mode 2
      — OpenSSL
      • OpenSSL Encryption only
When the hub is set to
mode 1
, the managed components first attempt to communicate through SSL. If a request is not acknowledged, the component sends unencrypted requests to the target.
SSL communication is enabled through the
UIM_HOME
/robot/robot.pem
certificate file. The controller creates the
robot.pem
file during startup. The
robot.pem
file contains the key to decode encrypted CA UIM messages.
  • The primary hub must be at SSL mode 0.  Beginning with v7.70, a hub at SSL mode 0 cannot communicate directly with a hub at SSL mode 2.
  • Java probes do not support SSL mode 1 or SSL mode 2.
Changes to Legacy SSL Communication in Controller v7.70
SSL communication modes are more meaningful in controller v7.70 because of changes to the treatment of the
robot.pem
certificates.
The following information about controller v7.63 also applies to previous versions.
    • Controller v7.63 always creates
      robot.pem
      and always acknowledges receipt of encrypted communication, regardless of the parent hub mode.
      • The first SSL encrypted request from a v7.63 controller in mode 1 to a v7.63 hub in mode 0 succeeds. The hub uses the
        robot.pem
        file to decode the message.
      • An unencrypted request from the hub to the controller also succeeds because the compatibility controller accepts it.
      • Components that are configured for unencrypted communication, and lack the OpenSSL transport layer, can decode encrypted messages, and can encrypt responses.
    • Controller v7.70 creates
      robot.pem
      only
      when the hub communication mode is 1 or 2.
      • An encrypted request from a v7.70 controller in mode 1 to a v7.70 hub in mode 0 fails. The hub cannot decode the message. The controller sends subsequent requests unencrypted.
      • An unencrypted request from the hub to the controller succeeds.
      • Controller v7.70 honors the meaning of no encryption and of SSL:
        • All communication for mode 0 components is unencrypted
        • Mode 0 components cannot decrypt messages from mode 2 (SSL only) components.
Communication Issues Between v7.70 and v7.63 and Earlier
If the parent hub is set to
mode=0
(unencrypted), controller v7.70:
    • The controller does not create the
      robot.pem
      file
    • If the
      robot.pem
      file exists, the controller deletes it
When hubs that are upgraded to v7.70 communicate with earlier versions, and hubs are set to the same mode:
    • Hubs set to
      mode 0
      communicate unencrypted
    • Hubs set to mode 1 use SSL encryption
    • Hubs set to mode 2 also use SSL encryption
The following diagram illustrates communication when all hubs are at or below v7.63, and when all hubs are v7.70. In the diagram:
    • Blue lines in the diagram represent SSL communication
    • Red lines in the diagram represent unencrypted communication
    • Solid lines in the diagram indicate successful communication
    • Dashed lines in the diagram are unacknowledged
    • Arrow direction indicates the initiator and receiver relationship.
      • A v7.63 hub in
        mode 0
        cannot initiate communication with a
        mode 2
        hub. Two-way communication is enabled once the relationship is established.
Hub SSL Mode
Hub SSL Mode
The behavior when the modes are mixed is as follows:
    • Version 7.63 and earlier:
      • Encrypted messages from hubs in mode 1 and 2 are decrypted
      • Hubs in mode 1 acknowledge unencrypted messages from hubs in mode 0
      • Hubs in mode 2 discard unencrypted messages from hubs in mode 0
    • Version 7.70 and later:
      • Hubs in mode 1 decrypt encrypted messages from hubs in mode 2
      • All requests between hubs in mode 0 and hubs in mode 2 are not acknowledged and are discarded
      • Encrypted requests from a mode 1 hub to a mode 0 hub are ignored. Unencrypted requests between the hubs are acknowledged.