DX Unified Infrastructure Management

I've got the same issue. How could I manually install probes if I was able to ssh/scp into the box?

Usually Nimsoft uses a range of ports to communicate, so your best option is to exclude that range from your firewall or run the robot in proxy mode, which uses only one port. I usually have customers allow at least the range from 48000 to 48020 to make sure the robot and hub can communicate.

As mentioned above, set the first_probe_port to 48000 as well which will force the robot to use the 48000 port range instead of dynamic ports for probes.

Robot to Hub communicates on port 48002

Hub to Robot communicates on port 48000

We've allowed ports 48000-48020 bi-directionaly tcp/udp from hub ip to robot ip on the DMZ. We can see the boxes in nimsoft but cannot open the probes - get a communication error.

Another problem is when we try to deploy a probe the distsrv (on the core) it starts somewhere around port 2000 and keeps trying to find an open port. It times out before it gets to the 48000's. We know this from watching the traffic on the firewall. 

Do we need to add a FW rule for the distsrv as well? Can we somehow tell the distsrv to start looking at 48000?

Any idea why we are able to see the robot/probes in IM but not open the probes?

First_probe_port has been set to 48000 on all probes cfg files on the box in the dmz and show ports 48000-03 being used in IM.

If the robots are in a DMZ, where is the hub to which they connect? It is in the DMZ with them or do they connect directly to a hub outside the DMZ?

Where are you running Infrastructure Manager? Into which hub do you login when starting Infrastructure Manager. (It should be displayed in the status bar at the bottom.)

Try to telnet from the computer running Infrastructure Manager to TCP 48000 on one of the robots. My guess is that will fail to connect. Unless you have a hub-to-hub tunnel between Infrastructure Manager and the robots, Infrastructure Manager will try to connect directly to the robots.

Hello all,

I have the same error, on a multiple linux robots, communication error. the robots deployment was successful, but when I am getting to the IM on a robot only the controller probe seems to be working, the hdb and spooler are with error. When I am going to the OS, I cannot see the hdb.log and the spooler.log files.

I have tried to restart the robot (from IM and from nimbus restart) and I see the same result. If I try to access log files from the IM I get a communication error.

I have checked the ADE log and the deployment is with no errors.

I can access from the IM system with telnet the 48000 port on the robot and the IM is seeing the linux machines as robots (as it should) but I cannot do anything else on these robots.

What can I do to start without error the two probes (hdb and spooler). I have tried also to reinstall the robots from the IM and got an error that it cannot do the commant removerobot.

Thanks,

Alina

Hi,

In almost 100% of these cases, something is blocking the traffic from the hub.  If you are sure the firewall(s) are configured correctly, have you checked the Linux IPTables?

An item to keep in mind is that if the robot reports into the IM and shows green, it is able to send the heartbeat.  When connecting to that robot it then fails, there is something blocking that traffic (either network firewall, local firewall, or anti-virus firewall).  We see this issue hundreds of times and it always boils down to one of the above.

I would re-check the inbound capabilities to that system.

Hello,

the firewall allows traffic, also the iptable is down or has the 48000-48200 set.

I have deployed bulk on 10 linux systems. 7 of them have this issue, and 3 of them are ok.

I have found a workaround but it is handy for a small number of robots.

If I edit the robot.cfg and enter the IP address on the robotip entry, after restarting the nimbus is working fine. I have checked the other robot.cfg files (on the systems where everything was fine) and they are were the same on every robot. Still, after this workaround the robot is working properly.

Does anybody know why is this happening?

Thank you,

Alina

Ahh...that could be another problem.  Many times, the Linux installer will pull the loopback address (or an address of an adapter that the hub cannot route to).  Being that you have to change the IP address manually, probably points to that issue.

The installer (more on Linux than Windows) looks at the HOSTS file to see what the IP address is...

Hello,

this is odd, since the behavior is not consistent. I have checked the hosts file and they are the same on all systems (same order), but in deed the first record is for the loopback address.

OK, then thanks. I can work with sometimes

Have a nice evening/day!

Thanks and Regards,

Alina

The approach we use is to use the nimldr/NimBUS Infrastructure.exe to install the core Nimsoft pieces and distsrv.

Then create a super package with all the setup you need.

Copy from the archive on your primary hub the zip file for the package and any dependencies and put those in the archive directory on your new server.

Put a request.cfg file in the Nimsoft directory.

Something like:

.

<distribution request>

packages = MyPackageName

</distribution request>

Then restart the Nimsoft service.

The controller will pick up the .cfg file and install that super package. You can use this to bootstrap all kinds of things from that point.

I agree with the others here that this issue generally points to a firewall or network-related issue.

Should you have static or strict firewall rules, this can make it difficult to keep distsrv in an appropriate range.

You may, however, force distsrv to use a specific port of your choosing with the '-p <portnumber>' argument.

First, right-click the distsrv probe in IM and select Edit.

In the ‘Arguments’ add “-p <your port number>'.

Finally, select ‘OK’ and then re-start the distsrv probe.

From now on, when the probe comes up it will be assigned to the port you indicated.
Please note that this does not work for all probes - distsrv is one of the few.