The Fabasoft app.telemetry Server consists of multiple Processes providing different Services.
The Fabasoft app.telemetry Server service is responsible for the Communication with all Fabasoft app.telemetry Agents, which includes the collection of counter, service-check and telemetry data. Counter and service-check data are processed to provide a system status view and are persisted on a database as configured. Telemetry data are persisted, analyzed to provide a log pool based view of requests. These request data are persisted to the database as configured.
The Fabasoft app.telemetry Worker is responsible for providing Information to the Fabasoft app.telemetry Client through the Fabasoft app.telemetry Webservice. The Fabasoft Worker Service reads telemetry data from disk written by the Fabasoft app.telemetry Server and it can load requests in memory.
The Fabasoft app.telemetry Webservice receives the requests form the Fabasoft app.telemetry Clients and passes them to the worker for further processing.
The Fabasoft app.telemetry Ecomm Service is responsible for handling outgoing communication requests using http/https transfer (e.g. sending a session to a service desk).
The Fabasoft app.telemetry Agent collects counter- and servicecheck-data and receives telemetry data from local applications. All data is buffered and streamed to the Fabasoft app.telemetry Server service on request.
The Fabasoft app.telemetry SNMP Agent provides access to agent and status information through the use of the SNMP-daemon to allow for example another Fabasoft app.telemetry Agent to query the information.
The Fabasoft app.telemetry Client connects vie http/https to the Fabasoft app.telemetry Webserver. It loads static resources from the Webserver and dynamic data through JSON requests, which the Webserver forwards to the Fabasoft app.telemetry Worker.
The communication between all the Fabasoft app.telemetry services is encrypted using TLS protocol with ciphers currently stated as secure. The communication between the Fabasoft app.telemetry Client and the Fabasoft app.telemetry Webserver uses http or https as provided by the webserver in use (Microsoft Internet Information Server or Apache Webserver). Configure http/https security as required using the webserver configuration parameters.
By default, all Fabasoft app.telemetry Services create 2048 bit RSA self-signed certificates for secure communication. The certificates are stored locally as cli_certificate.pem and/or srv_certificate.pem on the machine under /etc/app.telemetry/<servicename> respectively “C:\ProgramData\Fabasoft app.telemetry\<servicename>”. Validation of client certificates is being implemented by checking the sha2 hash of the client certificate against those permitted in the trusted_certificates.cfg file. The client certificates are automatically added to the trusted certificate of all Fabasoft app.telemetry server services.
Be careful when updating the Fabasoft app.telemetry Server service client certificate, because the trusted_certificates.cfg file on all agents has to be removed or rolled out, because the agent only adds the hash of the client certificate of the first server connecting to the app.telemetry Agent to the trusted_certificates.cfg. All connections with different certificates will be denied.
To generate new certificates, simply remove the certificate from the file system and restart the respective service.
To create a new self-signed for the use as a client certificate:
openssl genrsa -out key.pem 2048
openssl req -new -key key.pem -out key.csr
… provide organization parameters requested
openssl x509 -req -days 3650 -in key.csr -signkey key.pem -out certificate.pem
cat key.nopass.key certificate.pem > cli_certificate.pem
To compute the hash needed for the trusted_certificates.cfg file:
openssl x509 -fingerprint -in cli_certificate.pem -noout -sha256
Insert the fingerprint value at the beginning of a new line in the trusted_certificates.cfg file of the service that should trust that client certificate.
When setting the trusted_certificates.cfg manually make sure to provide the following trusts:
Each service has to include the hashes of the cli_certificates.pem of all trusted servers in their trusted_certificates.cfg. For example, the server/trusted_certificates.cfg has to include the hashes of worker/cli_certificate.pem, ecomm/cli_certificate.pem and webserver/cli_certificate.pem.
The default way to provide this is, that each service checks its own certificates on startup. If the certificate is absent or invalid it creates a new self-signed certificate and adds the hash of it to the trusted_certificates.cfg files of all required services.
The remote agents automatically trust the first service connecting to the agent by adding its client certificate hash to the new trust file. When changing the server/cli_certificate.pem, the agent/trusted_certificates.cfg has to be deleted or patched on all remote agents.
When setting up a Standby server, you have to deal with the problem, that your agents will only accept one server identified by its client certificate. So you either copy your server client certificate to the failover server or you have to distribute a trusted_certificates.cfg file containing all hashes of the server/cli_certificates.pem of all servers to all agents. The most common way to deal with this is to replace all certificates and trusted_certificates.cfg of the backup server with those of the original server.