non-secure OC Wasp does not start if primary hub is secure hub: Database Information is null

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

We have upgraded our DX UIM primary hub to secure hub and robot as per Secure Hub and Robot (broadcom.com)

The OC robot is running a normal non-secure robot, and after restating, the wasp is no longer able to connect the Primary hub.

Seems like the OC Wasp cannot obtain data_engine connection if OC Robot is non-secure and the primary hub is a Secure hub.

May 21 15:59:31:102 ERROR [main, com.nimsoft.nimbus.probe.service.wasp.Probe] (1) error, Database Information is null

at com.nimsoft.nimbus.probe.service.wasp.Probe.doit(Probe.java:332)

at com.nimsoft.nimbus.probe.service.wasp.Probe.main(Probe.java:124)

May 21 15:59:39:524 ERROR [main, com.nimsoft.nimbus.probe.service.wasp.Probe] main() Fatal error!

May 21 16:00:10:393 [4684] Controller: Max. restarts reached for probe 'wasp' (command = <startup java>)

Does OC non-secure robot support primary hub with secure robot and hub?

Environment

DX UIM 20.4.* / 23.4.*

Cause

In a secure hub environment, the goal is to ensure that all communication with the primary hub occurs through secure channels, without exposing public IP addresses and ports. This approach enhances security by minimizing the attack surface.

External entities must use secure channels to communicate with the primary hub.

When OC is not secured (not using secure channels), it attempts to communicate directly with the data_engine probe. The data_engine probe's port is not exposed to public communication, causing connectivity issues.

That is why the OC will not get the connection string and the probe will fail to start.

Resolution

Ensure you upgrade the OC Robot to Secure as described here: Secure Hub and Robot (broadcom.com)

Upgrade Operator Console

After upgrading your secondary hubs, you can convert your Operator Console to a secure state.

Follow these steps:

Log in to the primary hub Admin Console or IM (only on Windows using the loopback IP).
Follow the instructions in the Secure Transmission of Certificates article to securely transfer the certificates from the hub to the robots pointing to the hub.
From the primary hub archive, upgrade the Operator Console robot version to the secure robot version.
Run the Operator Console installer to upgrade your Operator Console instance.

Your Operator Console is now upgraded and is secure.

If your Operator Console Robot is already upgrade to Secure and you still experience this issue, this may indicate that the secure robot upgrade was not fully successful. Although the robot still displays the "S" in the version number, it may be running the old executable.

To verify this, look into the \Nimsoft\robot\ folder and check whether you see "controller.exe.old" in the folder.

If so, take the following steps:

delete the controller.exe.old and any other file in this folder with the .old extension
make note of the "Date modified" timestamp for the remaining "controller" (controller.exe)
redeploy the robot_update_secure package.
Ensure that the timestamp on the controller.exe updates to the current time.
Another controller.exe.old may appear. It is safe to delete.

Additional Information

Secure Transmission of Certificates

Note: even though the secure communication between the primary hub and the secure oc is establish, for the wasp probe to start, the cryptkey key in the robot.cfg must be correctly pointing to the certificate.pem. as per Configure the robot.cfg File (broadcom.com)