This topic describes two potential network configuration issues for s-Server, related to hostnames and firewalls.
The most important consideration is the host name. s-Server needs to be able to resolve its own hostname. For dedicated servers, this is usually not a problem, as they will be listed in the network’s DNS.
However, for development and test systems that use DHCP to obtain their IP addresses, you may need to configure these for local name resolution. With many Linux systems, the system installation sets up the network and prompts the user for a host name for the host. However, sometimes the installation only writes this to the network configuration (usually /etc/sysconfig/network), but not to the hosts file (/etc/hosts*). As a result, s-Server can’t figure out what IP address to bind itself to, and will fail. The s-Server installer attempts to check for this condition, and will refuse to install on a system that canmot resolve its own name. If that happens, you can check for yourself at the command line by typing either
One or both of those will probably return an error, such as hostname: Unknown host If you check the /etc/hosts file, you will likely find something like this:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
You will need to edit the /etc/hosts file to add the host name of your system. For example, if your system’s host name is myserver, you need to add that host name to the 127.0.0.1 line in /etc/hosts:
127.0.0.1 myserver localhost localhost.localdomain localhost4 localhost4.localdomain4
Note: You need administrative (root) privileges to change /etc/hosts, so you either need to log in as root or use sudo. You should now be able to get correct results from the hostname -i and hostname-f commands, and the s-Server installer should work correctly.
If you will be accessing your s-Server from another system, you need to make sure the server’s firewall permits access to the proper ports.
If your clients (s-Studio, sqllineClient, any agents) all run on the same system with s-Server, firewalls are not an issue. But if, for example, you want to run s-Studio on a Windows system to access s-Server, the firewall needs to allow access. Consult your system documentation for specific information on how to open ports.
Note: Only TCP ports need to be opened. UDP ports can be left alone.
The following describes the various ports you might need to open on your server. Keep in mind that these are the default ports. If you choose to run your server or utilities on non-default ports, you will need to open those ports for remote access.
The following diagram summarizes the ports that operate between Guavus SQLstream components:
Guavus SQLstream uses the following ports:
s-Server, the central component of the Guavus SQLstream system, listens on port 5570 (SDP2).
In order for applications (including s-Studio and webAgent) to access s-Server directly from a remote computer, the firewall on the host computer for s-Server must allow incoming traffic on port 5570. The firewall on the computer hosting the application must similarly allow outbound traffic on port 5570.
Clients receive data by means of SDP, on default port 5570. ( SDP is SQLstream’s streaming data protocol.) SDP connections use TCP transport and require a valid route from the client driver to the server. However, a server can be configured to use a different port, as described below.
Note that the JDBC connection string refers to the SQLstream s-Server using a particular SDP port: jdbc:sqlstream:sdp://host:port. The suffix port is optional, since the SQLstream client driver automatically supplies “5570” as the default SDP port value. However, if the server is actually using a different SDP port, its number must appear explicitly in the connect string.
webAgent, the HTTP server that exchanges data with s-Server, listens on port 5580. The firewall on its host computer must allow outbound traffic on port 5570.
In order for applications (including StreamLab and s-Dashboard) to access webAgent directly, the firewall on the host computer for webAgent must allow incoming traffic on port 5580. The firewall on the computer hosting the application must similarly allow outbound traffic on port 5580. Since webAgent handles connections to s-Server, these applications do not need to be open to s-Server (and likely should not be).
StreamLab listens on port 5585 (ROSE) and 5590. It uses webAgent to connect to s-Server. In order to communicate with webAgent, the firewall on its host computer must allow outbound traffic on port 5580.
In order for users to access StreamLab through a browser, the firewall on the host computer for StreamLab must allow outgoing traffic on ports 5585 and 5590.
s-Dashboard listens on port 5595. It uses webAgent to connect to s-Server. In order to communicate with webAgent, the firewall on its host computer must allow outbound traffic on port 5580.
In order for users to access s-Dashboard through a browser, the firewall on the host computer for s-Dashboard must allow outgoing traffic on port 5595.