Network Configuration

Managing Ports

To connect to the CData Virtuality Server, it is important to know which ports are used for network communication. This is especially true if you have a secure environment and all network traffic must be firewall-enabled. Problems can arise if you either try to connect to the wrong port or if the port is not accessible through the firewall.

The CData Virtuality Server is shipped with some default ports, which you can find at the bottom of the %pathToDVserver%/standalone/configuration/dvserver-standalone.xml file on Linux or %pathToDVserver%\standalone\configuration\dvserver-standalone.xml on Windows. Here is an example:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <socket-binding name="dv-jdbc" port="31000"/>
    <socket-binding name="dv-jdbc-ssl" port="31001"/>
    <socket-binding name="dv-odbc" port="35432"/>
    <socket-binding name="dv-odbc-ssl" port="35433"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

As the snippet suggests, there are several ports for various purposes. The main ones are for JDBC and ODBC connections. For example, the CData Virtuality Studio uses JDBC or JDBC over SSL connections, whereas Tableau requires ODBC connections. You can find information on configuring secure ODBC connections further on this page. Please also ensure that no services or programs are running on the machine hosting the CData Virtuality Server, which may have conflict in socket bindings. If, for example, you already have a process running and this process uses port 9990, you might not be able to connect to the Server via this port. Even worse, sockets already in use may prevent the Server from starting.

Ensure no process other than the CData Virtuality Server uses one of the ports from dvserver-standalone.xml and ensure that the ports are open and no firewall blocks communication with the Server!

Port Offset

If you have any conflicts, change either the affected ports of the CData Virtuality Server or the ones of the other process. Alternatively, you can use the port-offset property to increment all used ports by a specific value. If you set the offset from 0 to 10000, your Server will now use ports 41000 (JDBC), 41001 (JDBC over SSL), 45432 (ODBC), and so forth. This is a simple way to prevent conflicts, but you should carefully adjust firewall rules and check the documentation on possible changes.

Configuring Proxy Settings

If you deployed the CData Virtuality Server within an environment using an HTTP proxy server, the CData Virtuality Server needs to be configured to use this proxy. This is also done via the dvserver-standalone.xml file. You can specify the IP address and the port of the proxy that CData Virtuality Server shall communicate with and a list of hosts that are directly contacted (without any proxy interference). Find the </extensions> end tag and place the configuration right after it:

...
</extensions>
 
<system-properties property name="http.proxyHost" value="ProxyIP"/>
<system-properties property name="http.proxyPort" value="ProxyPort"/>
<system-properties property name="http.nonProxyHosts" value="ListOfHostsThatAreDirectlyContacted"/>

Note that the value for http.nonProxyHosts can contain a list with multiple hosts (separated by '|') that are communicated with directly: for example, value="localhost|clr.mycomp.org|*.mycomp.local", where  '*' denotes the wildcard. There are also properties named https.proxyHost and https.proxyPort for configuring secure proxy connections.

Enabling ODBC over SSL Connections

To enable a secure ODBC connection, you need a certificate imported into a Java keystore. To point to this keystore and append a socket binding for the ODBC over SSL connection, add several lines in the dvserver-standalone.xml file. As with the default ports, enable firewall rules if necessary and do not specify ports already in use by some other process.

If you do not have a certificate, you can create one with the keytool tool shipped with the embedded Java SDK - it is found in the %dvDir%/JDK/bin subfolder. The following code creates a new certificate and stores it in a keystore that you specify:

• Creating a self-signed certificate on Linux:

keytool -genkey -alias teiid -keyalg RSA -validity 365 -keystore %pathToStore%/server.keystore -storetype JKS

• Creating a self-signed certificate  on Windows:

keytool -genkey -alias teiid -keyalg RSA -validity 365 -keystore %pathToStore%\server.keystore -storetype JKS

Once you have obtained the certificate, search in dvserver-standalone.xml for the following section and replace the %pathToKeystoreFile% and %keystorePassword% placeholders accordingly:

<transport name="odbc-ssl" socket-binding="dv-odbc-ssl" protocol="pg">
	<authentication security-domain="dv-security"/>
	<ssl mode="enabled" ssl-protocol="SSLv3">
		<keystore name="%pathToKeystoreFile%" password="%keystorePassword%"/>
	</ssl>
</transport>