Support Forums : DataStax

DataStax Support Forums » OpsCenter

trouble connecting to agent

(10 posts) (5 voices)

Started 1 year ago by kireet
Latest reply from nickmbailey
This topic is resolved

Tags:

kireet
Member

I am trying to get datastax community (cassandra+opscenter) running all on one linux(centos) machine for testing purposes. I have everything installed and cassandra is running fine. Opscenter is communicating with cassandra fine, but it's having trouble with the agent. After debugging, I found this:

netstat -tulpn | less
~# netstat -tulpn | grep 616
tcp 0 0 127.0.0.1:61619 0.0.0.0:* LISTEN 22068/python2.6
tcp 0 0 127.0.0.1:61620 0.0.0.0:* LISTEN 22068/python2.6
~# netstat -tulpn | grep 9160
tcp 0 0 66.160.192.50:9160 0.0.0.0:* LISTEN 19926/java
~# netstat -tulpn | grep 7199
tcp 0 0 0.0.0.0:7199 0.0.0.0:* LISTEN 19926/java

I think the issue is cassandra is running with the public IP but somehow opscenter is opening ports using the loopback address. results from hostname -f and hostname -i look correct. How does opscenter pick an interface when it opens the agent ports?

Posted 1 year ago #
thobbs
Administrator

The opscenterd daemon tries to bind to 0.0.0.0:61620 by default to listen for agent communication. It seems odd that it's apparently only listening on 127.0.0.1.

You can try overriding the default by adding an [agents] section to opscenterd.conf:

[agents]
incoming_interface = 0.0.0.0

and changing 0.0.0.0 to the correct IP address of the machine.

If that works, let me know and we can perhaps try to figure out why it wasn't binding to the correct interface(s) in the first place.

Posted 1 year ago #
kireet
Member

yep that worked:

# netstat -tulpn | grep 616
tcp 0 0 127.0.0.1:61619 0.0.0.0:* LISTEN 30930/python2.6
tcp 0 0 66.160.192.50:61620 0.0.0.0:* LISTEN 30930/python2.6
tcp 0 0 ::ffff:66.160.192.50:61621 :::* LISTEN 31064/java

and i see in the agent log that communication was established.

Posted 1 year ago #
thobbs
Administrator

Cool, glad that worked.

Did you happen to disable SSL for communication with the agents, by chance? Did you change any other default config options?

Posted 1 year ago #
kireet
Member

yeah, i disabled ssl. i was debugging another issue and i was turning things off to see if it helped...

Posted 1 year ago #
thobbs
Administrator

Thanks, that confirms what I thought was happening. Looks like there's a bug where opscenterd binds to 127.0.0.1 if ssl is disabled and the default of 0.0.0.0 isn't overridden.

We should be able to fix this pretty easily in the next release.

Posted 1 year ago #
kireet
Member

cool, i will try it out and let you know if it works.

Posted 1 year ago #
jas
Member

thobbs,

I thank you as well. I was having this same problem just now on some EC2 nodes I setup up and the agents just kept getting the connection refused to the opscenter (1.4.1) system. I was playing around with the AWS security groups etc., not able to figure it out. Then I did netstat -n and noticed the localhost issue. I copied interface = 0.0.0.0 from [webserver] to agents [agents] and that did not work.

Anyway, your solution does work, and is showing up from my two DSE 2 nodes. :)

Posted 1 year ago #
conzar
Member

@jas, you need to set incoming-interface = <ip address> where ip address is the ip of the interface that opscenterd is running on and that the agents connect to. 0.0.0.0 isn't a valid address.

For instance, the interface that the agents connect to for me looks like this:
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:10.1.1.1 Bcast:10.1.255.255 Mask:255.255.0.0

The configuration for opscenterd.conf:
[agents]
use_ssl = false
incoming_interface = 10.1.1.1

Also, is there a patch to fix this problem in the code yet?

Posted 1 year ago #
nickmbailey
Key Master

The bug involved here has been fixed in the 2.0 release of OpsCenter which just came out. The workarounds mentioned above will still work fine, but shouldn't be necessary from now on.

Let us know if you have any issues.

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.