Setup


reelfx.render@...
 

We are setting up OpenCue and RQD without docker (centOS7 build)

I am running:

java -jar $JAR_PATH --datasource.cueDataSource.url=jdbc:postgresql://$DB_HOST/$DB_NAME --datasource.cueDataSource.username=$DB_USER --datasource.cueDataSource.password=$DB_PASS

However, it only seems to be listening on tcp6, not tcp

tcp6       0      0 :::8443                 :::*                    LISTEN

When I run  rqd I get: target_address":"ipv4:.....

Am I missing a config option to get it to listen on tcp instead of tcp6?


Donal McMullan
 

This might be expected (albeit confusing) behaviour.

Can you please run one of these commands on your cuebot host:
telnet 127.0.0.1 8443
nc 127.0.0.1 8443

I expect you'll get a connection, which suggests things are ok on the server side.

From the docs:

>> A dual stack includes implementations of both versions of the Internet Protocol, IPv4 and IPv6.
>> A general property of a dual-stack node is that an IPv6 socket can communicate both with an IPv4 and IPv6 peer at the transport layer

If that's working and cuebot is able to accept ipv4 connections, then is it possible that your rqd hosts are getting an ipv6 address when they try to resolve the hostname of your cuebot instance? If you ping 'cuebot' from the rqd host, what IP address do you get?

Thanks

DJM


On Tue, 29 Oct 2019 at 16:09, <reelfx.render@...> wrote:

We are setting up OpenCue and RQD without docker (centOS7 build)

I am running:

java -jar $JAR_PATH --datasource.cueDataSource.url=jdbc:postgresql://$DB_HOST/$DB_NAME --datasource.cueDataSource.username=$DB_USER --datasource.cueDataSource.password=$DB_PASS

However, it only seems to be listening on tcp6, not tcp

tcp6       0      0 :::8443                 :::*                    LISTEN

When I run  rqd I get: target_address":"ipv4:.....

Am I missing a config option to get it to listen on tcp instead of tcp6?


reelfx.render@...
 

No, I am getting connection refused.

nc 127.0.0.1 8443

Ncat: Connection refused.

I have firewalld disabled, I am not purposefully locking any ports. 
my /etc/services has the following
pcsync-https    8443/tcp                # PCsync HTTPS
pcsync-https    8443/udp                # PCsync HTTPS
pcsync-http     8444/tcp                # PCsync HTTP
pcsync-http     8444/udp                # PCsync HTTP
 


Donal McMullan
 

But that nc invocation works if you supply the ipv6 loopback address? These both work for me on a fairly vanilla centos with cuebot running.
nc 127.0.0.1 8443                                                                                  
nc ::1 8443

I'd be interested to see what effect this has (adding the -Djava.net.preferIPv4Stack=true argument):
java -jar $JAR_PATH -Djava.net.preferIPv4Stack=true --datasource.cueDataSource.url=jdbc:postgresql://$DB_HOST/$DB_NAME --datasource.cueDataSource.username=$DB_USER --datasource.cueDataSource.password=$DB_PASS

DJM


On Tue, 29 Oct 2019 at 18:19, <reelfx.render@...> wrote:

No, I am getting connection refused.

nc 127.0.0.1 8443

Ncat: Connection refused.

I have firewalld disabled, I am not purposefully locking any ports. 
my /etc/services has the following
pcsync-https    8443/tcp                # PCsync HTTPS
pcsync-https    8443/udp                # PCsync HTTPS
pcsync-http     8444/tcp                # PCsync HTTP
pcsync-http     8444/udp                # PCsync HTTP
 


reelfx.render@...
 

That worked perfectly.

So I am guessing I have something that must be disabling the dual-stack property of the tcp6


Donal McMullan
 

Is there anything in your environment variables that looks suspicious, e.g.
JAVAWS_VM_ARGS=-Djava.net.preferIPv6Addresses=true


On Wed, 30 Oct 2019 at 14:07, <reelfx.render@...> wrote:

That worked perfectly.

So I am guessing I have something that must be disabling the dual-stack property of the tcp6


reelfx.render@...
 

Not that I have found. My env variables look normal, and I have none that look like what you posted. I have found a suggestion somewhere that nmap may be an issue here, but I'm still digging in.