Robot connectivity issues on Redhat Linux 7.1
search cancel

Robot connectivity issues on Redhat Linux 7.1

book

Article ID: 35304

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

Linux Robot cannot connect to its hub and the controller GUI will not open and display data.

After working around various issues getting a Linux robot up and running, although the robot probes (controller/spooler and hdb), all had ports are were green, and the controller and remote hub showed no errors, we could not open the controller GUI or contact it via the hub (hub->Robot). In the IM Tools->Connect to the Robot was not successful. Only the connection from the robot to the hub worked as per telnet <hub> 48002.

This article may also help with other connectivity issues or errors related to port conflicts.

Environment

- UIM 8.3.1 or higher
- Redhat Linux 7.1 (as per cat /etc/release-info)
- Robot 7.80 or higher

Resolution

In this particular case, the cause was Linux security/iptables firewall configuration.

As it turns out, iptables rules was interfering even though we disabled it using the command:
service iptables stop

When that command was run, the next line showed that it was redirecting to the /bin/sysctl command. For example:

# service iptables stop
Redirecting to /bin/systemctl  status iptables.service
iptables.service - IPv4 firewall with iptables

When you listed the rules after disabling the Linux firewall, you still saw the list of rules:

Current running iptables rules can be viewed with the command iptables -L or use iptables -L -n to also see the port number.

[root@tpuimlnx01 robot]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state

RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp

dpt:ssh
REJECT     all  --  anywhere             anywhere             reject-with icmp-

host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere             reject-with icmp-

host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Once we ran the command that it was redirecting to, directly as per below, it disabled not only iptables but it also Flushed the rules.

[root@tpuimlnx01 robot]# /bin/systemctl stop iptables.service

[root@tpuimlnx01 robot]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Resolution

a) You can flush the rules manually during testing using iptables -F, but the rules are flushed when the iptables is 100% stopped by running the command using systemctl NOT 'service iptables stop.'

   /bin/systemctl stop iptables.service

   /bin/systemctl status iptables.service (displays the iptables status)

Otherwise if you run service iptables stop it will stop the service but the rules stay in effect as evidenced by seeing the redirection to /bin/systemctl, e.g., ....Redirecting to /bin/systemctl stop iptables.service despite disabling it with "service iptables stop"

Note that the behavior of the iptables stop command  may depend on the system/security configuration on the Linux machine.

b) You could add a firewall rule on the local Linux machine and keep the iptables enabled. For example:

ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp     dpt:48000-48100
Ease of configuration depends upon how many Linux machines you need to adjust. It may not be the same config for all so that would need to be checked.

Notes:
Make sure you restart the robot after making any changes. Once we disabled the firewall interference completely, we could connect to the robot from the hub as well as Infrastructure Manager (IM).

If the firewall/iptables service is truly disabled on the robot and you cannot deploy packages to the robot, but SELinux enforcing is enabled, then it may be necessary to disable SELinux on the robot.

How to disable SELinux:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux
 

Additional Information

Additional information
(Reference to using iptables command to add/delete rules)

https://fedoraproject.org/wiki/How_to_edit_iptables_rules