Trento Docs :: Trento Documentation

Installing Trento Server

Kubernetes deployment

The subsection uses the following placeholders:

TRENTO_SERVER_HOSTNAME: the host name used by the end user to access the console.
ADMIN_PASSWORD: the password of the admin user created during the installation process.

The password must meet the following requirements:
- minimum length of 8 characters
- the password must not contain 3 identical numbers or letters in a row (for example, 111 or aaa)
- the password must not contain 4 sequential numbers or letters (for example, 1234, abcd, ABCD)

By default, the provided Helm chart uses Traefik as ingress class
Main usages are related to:

path rewriting
endpoint protection

Find traefik specific usages here, and in case another ingress controller is used, please adapt accordingly.

Installing Trento Server on an existing Kubernetes cluster

Trento Server consists of a several components delivered as container images and intended for deployment on a Kubernetes cluster. A manual production-ready deployment of these components requires Kubernetes knowledge. Customers without in-house Kubernetes expertise and who want to try Trento with a minimum of effort, can use the Trento Helm chart. This approach automates the deployment of all the required components on a single Kubernetes cluster node. You can use the Trento Helm chart to install Trento Server on a existing Kubernetes cluster as follows:

Install Helm:

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Connect Helm to an existing Kubernetes cluster.

Use Helm to install Trento Server with the Trento Helm chart:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

When using a Helm version lower than 3.8.0, an experimental flag must be set as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

To verify that the Trento Server installation was successful, open the URL of the Trento Web (http://TRENTO_SERVER_HOSTNAME) from a workstation on the SAP administrator’s LAN.

Installing Trento Server on K3s

If you do not have a Kubernetes cluster, or have one but do not want to use it for Trento, SUSE Rancher’s K3s provides an alternative. To deploy Trento Server on K3s, you need a small server or VM (see [sec-trento-server-requirements] for minimum requirements) and follow steps in Manually installing Trento on a Trento Server host.

The following procedure deploys Trento Server on a single-node K3s cluster. Note that this setup is not recommended for production use.

Manually installing Trento on a Trento Server host

Install K3s either as root or a non-root user.

Installing as user root:

curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh

Installing as a non-root user:

curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh -s - --write-kubeconfig-mode 644

Install Helm as root.

curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

Set the KUBECONFIG environment variable for the same user that installed K3s:
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

With the same user that installed K3s, install Trento Server using the Helm chart:

helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

When using a Helm version lower than 3.8.0, an experimental flag must be set as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD

Monitor the creation and start-up of the Trento Server pods, and wait until they are ready and running:
watch kubectl get pods
All pods must be in the ready and running state.
Log out of the Trento Server host.
To verify that the Trento Server installation was successful, open the URL of the Trento Web (http://TRENTO_SERVER_HOSTNAME) from a workstation on the SAP administrator’s LAN.

Deploying Trento Server on selected nodes

If you use a multi-node Kubernetes cluster, it is possible to deploy Trento Server images on selected nodes by specifying the field nodeSelector in the helm upgrade command as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set prometheus.server.nodeSelector.LABEL=VALUE \
   --set postgresql.primary.nodeSelector.LABEL=VALUE \
   --set trento-web.nodeSelector.LABEL=VALUE \
   --set trento-runner.nodeSelector.LABEL=VALUE

Configuring event pruning

The event pruning feature allows administrators to manage how long registered events are stored in the database and how often the expired events are removed.

The following configuration options are available:

pruneEventsOlderThan: The number of days registered events are stored in the database. The default value is 10. Keep in mind that pruneEventsOlderThan can be set to 0. However, this deletes all events whenever the cron job runs, making it impossible to analyze and troubleshoot issues with the application
pruneEventsCronjobSchedule: The frequency of the cron job that deletes expired events. The default value is "0 0 * * *", which runs daily at midnight.

To modify the default values, execute the following Helm command:

helm ... \
    --set trento-web.pruneEventsOlderThan=<<EXPIRATION_IN_DAYS>> \
    --set trento-web.pruneEventsCronjobSchedule="<<NEW_SCHEDULE>>"

Replace the placeholders with the desired values:

EXPIRATION_IN_DAYS: Number of days to retain events in the database before pruning.
NEW_SCHEDULE: The cron rule specifying how frequently the pruning job is performed.

Example command to retain events for 30 days and schedule pruning daily at 3 AM:

helm upgrade \
  --install trento-server oci://registry.suse.com/trento/trento-server \
  --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
  --set trento-web.adminUser.password=ADMIN_PASSWORD \
  --set trento-web.pruneEventsOlderThan=30 \
  --set trento-web.pruneEventsCronjobSchedule="0 3 * * *"

Enabling email alerts

Email alerting feature notifies the SAP Basis administrator about important changes in the SAP Landscape being monitored by Trento.

The reported events include the following:

Host heartbeat failed
Cluster health detected critical
Database health detected critical
SAP System health detected critical

This feature is disabled by default. It can be enabled at installation time or anytime at a later stage. In both cases, the procedure is the same and uses the following placeholders:

SMTP_SERVER: The SMTP server designated to send email alerts
SMTP_PORT: Port on the SMTP server
SMTP_USER: User name to access SMTP server
SMTP_PASSWORD: Password to access SMTP server
ALERTING_SENDER: Sender email for alert notifications
ALERTING_RECIPIENT: Recipient email for alert notifications.

The command to enable email alerts is as follows:

HELM_EXPERIMENTAL_OCI=1 helm upgrade \
   --install trento-server oci://registry.suse.com/trento/trento-server \
   --set global.trentoWeb.origin=TRENTO_SERVER_HOSTNAME \
   --set trento-web.adminUser.password=ADMIN_PASSWORD \
   --set trento-web.alerting.enabled=true \
   --set trento-web.alerting.smtpServer=SMTP_SERVER \
   --set trento-web.alerting.smtpPort=SMTP_PORT \
   --set trento-web.alerting.smtpUser=SMTP_USER \
   --set trento-web.alerting.smtpPassword=SMTP_PASSWORD \
   --set trento-web.alerting.sender=ALERTING_SENDER \
   --set trento-web.alerting.recipient=ALERTING_RECIPIENT

Enabling SSL

Ingress may be used to provide SSL termination for the Web component of Trento Server. This would allow to encrypt the communication from the agent to the server, which is already secured by the corresponding API key. It would also allow HTTPS access to the Web console with trusted certificates.

Configuration must be done in the tls section of the values.yaml file of the chart of the Trento Server Web component.

For details on the required Ingress setup and configuration, refer to: https://kubernetes.io/docs/concepts/services-networking/ingress/. Particularly, refer to section https://kubernetes.io/docs/concepts/services-networking/ingress/#tls for details on the secret format in the YAML configuration file.

Additional steps are required on the Agent side.

systemd deployment

A systemd-based installation of the Trento Server using RPM packages can be performed manually on the latest supported versions of SUSE Linux Enterprise Server for SAP applications, from 15 SP4 up to 16. For installations on service packs other than the current one, make sure to update the repository URL as described in the relevant notes throughout this guide.

Supported versions:

SUSE Linux Enterprise Server for SAP applications 15: SP4–SP7
SUSE Linux Enterprise Server for SAP applications 16.0

List of dependencies

Install Trento dependencies

Install PostgreSQL

The current instructions are tested with the following PostgreSQL versions:

SUSE Linux Enterprise Server for SAP applications	PostgreSQL Version
15 SP4	14.10
15 SP5	15.5
15 SP6	16.9
15 SP7	17.5
16.0	17.6

Using a different version of PostgreSQL may require different steps or configurations, especially when changing the major number. For more details, refer to the official PostgreSQL documentation.

Install PostgreSQL server:
```
zypper in postgresql-server
```
Enable and start PostgreSQL server:
```
systemctl enable --now postgresql
```

Configure PostgreSQL

Start psql with the postgres user to open a connection to the database:
```
su - postgres
psql
```

Initialize the databases in the psql console:

CREATE DATABASE wanda;
CREATE DATABASE trento;
CREATE DATABASE trento_event_store;

Create the users:

CREATE USER wanda_user WITH PASSWORD 'wanda_password';
CREATE USER trento_user WITH PASSWORD 'web_password';

Grant required privileges to the users and close the connection:

\c wanda
GRANT ALL ON SCHEMA public TO wanda_user;
\c trento
GRANT ALL ON SCHEMA public TO trento_user;
\c trento_event_store;
GRANT ALL ON SCHEMA public TO trento_user;
\q

You can exit from the psql console and postgres user.

Allow the PostgreSQL database to receive connections to the respective databases and users. To do this, add the following to /var/lib/pgsql/data/pg_hba.conf:

host   wanda                      wanda_user    0.0.0.0/0     scram-sha-256
host   trento,trento_event_store  trento_user   0.0.0.0/0     scram-sha-256

The pg_hba.conf file works sequentially. This means that the rules on the top have preference over the ones below. The example above shows a permissive address range. So for this to work, the entires must be written at the top of the host entries. For further information, refer to the pg_hba.conf documentation.

Allow PostgreSQL to bind on all network interfaces in /var/lib/pgsql/data/postgresql.conf by changing the following line:
```
listen_addresses = '*'
```
Restart PostgreSQL to apply the changes:
```
systemctl restart postgresql
```

Install RabbitMQ

Install RabbitMQ server:
```
zypper install rabbitmq-server
```
Allow connections from external hosts by modifying /etc/rabbitmq/rabbitmq.conf, so the Trento-agent can reach RabbitMQ:
```
listeners.tcp.default = 5672
```

If firewalld is running, add a rule to firewalld:

firewall-cmd --zone=public --add-port=5672/tcp --permanent;
firewall-cmd --reload

Enable the RabbitMQ service:
```
systemctl enable --now rabbitmq-server
```

Configure RabbitMQ

To configure RabbitMQ for a production system, follow the official suggestions in the RabbitMQ guide.

Create a new RabbitMQ user:

rabbitmqctl add_user trento_user trento_user_password

Create a virtual host:
```
rabbitmqctl add_vhost vhost
```

Set permissions for the user on the virtual host:

rabbitmqctl set_permissions -p vhost trento_user ".*" ".*" ".*"

Install Trento using RPM packages

The trento-web and trento-wanda packages are available by default on supported SUSE Linux Enterprise Server for SAP applications distributions.

Install Trento web, wanda and checks:

zypper install trento-web trento-wanda

Create the configuration files

Both services depend on respective configuration files. They must be placed in /etc/trento/trento-web and /etc/trento/trento-wanda respectively, and examples of how to modify them are available in /etc/trento/trento-web.example and /etc/trento/trento-wanda.example.

You can create the content of the secret variables such as SECRET_KEY_BASE, ACCESS_TOKEN_ENC_SECRET and REFRESH_TOKEN_ENC_SECRET using openssl:

openssl rand -out /dev/stdout 48 | base64

Also ensure that a valid hostname, FQDN, or IP address is configured in TRENTO_WEB_ORIGIN when using HTTPS. Otherwise, WebSocket connections will fail, preventing real-time updates in the web interface.

trento-web configuration

# /etc/trento/trento-web
AMQP_URL=amqp://trento_user:trento_user_password@localhost:5672/vhost
DATABASE_URL=ecto://trento_user:web_password@localhost/trento
EVENTSTORE_URL=ecto://trento_user:web_password@localhost/trento_event_store
ENABLE_ALERTING=false
CHARTS_ENABLED=false
ADMIN_USER=admin
ADMIN_PASSWORD=trentodemo
ENABLE_API_KEY=true
PORT=4000
TRENTO_WEB_ORIGIN=trento.example.com
SECRET_KEY_BASE=some-secret
ACCESS_TOKEN_ENC_SECRET=some-secret
REFRESH_TOKEN_ENC_SECRET=some-secret
CHECKS_SERVICE_BASE_URL=/wanda
OAS_SERVER_URL=https://trento.example.com

The ADMIN_PASSWORD variable must must meet the following requiements:

minimum of 8 characters
the password not contain 3 consecutive identical numbers or letters (for example, 111 or aaa)
the password must not contain 4 consecutive numbers or letters (for example, 1234, abcd, ABCD)

The ENABLE_ALERTING enables the alerting system to receive email notifications. Set ENABLE_ALERTING to true and add additional variables to the /etc/trento/trento-web, to enable the feature.

# /etc/trento/trento-web
ENABLE_ALERTING=true
ALERT_SENDER=<<SENDER_EMAIL_ADDRESS>>
ALERT_RECIPIENT=<<RECIPIENT_EMAIL_ADDRESS>>
SMTP_SERVER=<<SMTP_SERVER_ADDRESS>>
SMTP_PORT=<<SMTP_PORT>>
SMTP_USER=<<SMTP_USER>>
SMTP_PASSWORD=<<SMTP_PASSWORD>>

trento-wanda configuration

# /etc/trento/trento-wanda
CORS_ORIGIN=http://localhost
AMQP_URL=amqp://trento_user:trento_user_password@localhost:5672/vhost
DATABASE_URL=ecto://wanda_user:wanda_password@localhost/wanda
PORT=4001
SECRET_KEY_BASE=some-secret
OAS_SERVER_URL=https://trento.example.com/wanda
AUTH_SERVER_URL=http://localhost:4000

Start the services

In some SUSE Linux Enterprise Server for SAP applications environments, SELinux may be enabled and set to enforcing mode by default. If Trento services fail to start or show permission-related errors, check the SELinux status:

getenforce

If SELinux is set to enforcing, switch it to permissive mode either temporarily or permanently:

Temporary change (until reboot):
```
setenforce 0
```
Permanent change (persists after reboot):

Edit /etc/selinux/config and set:
```
SELINUX=permissive
```

Enable and start the services:

systemctl enable --now trento-web trento-wanda

Monitor the services

Use journalctl to check if the services are up and running correctly. For example:

journalctl -fu trento-web

Check the health status of trento web and wanda

You can check if Trento web and wanda services function correctly by accessing accessing the healthz and readyz API.

Check Trento web health status using curl:

curl http://localhost:4000/api/readyz

curl http://localhost:4000/api/healthz

Check Trento wanda health status using curl:

curl http://localhost:4001/api/readyz

curl http://localhost:4001/api/healthz

If Trento web and wanda are ready, and the database connection is set up correctly, the output should be as follows:

{"ready":true}{"database":"pass"}

Install and configure NGINX

Install NGINX package:
```
zypper install nginx
```

If firewalld is running, add firewalld rules for HTTP and HTTPS:

firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload

Start and enable NGINX:
```
systemctl enable --now nginx
```

Create a /etc/nginx/conf.d/trento.conf Trento configuration file:

map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}

upstream web {
  server 127.0.0.1:4000 max_fails=5 fail_timeout=60s;
}

upstream wanda {
  server 127.0.0.1:4001 max_fails=5 fail_timeout=60s;
}

server {
    # Redirect HTTP to HTTPS
    listen 80;
    server_name trento.example.com;
    return 301 https://$host$request_uri;
}

server {
    server_name trento.example.com;
    listen 443 ssl;

    ssl_certificate /etc/nginx/ssl/certs/trento.crt;
    ssl_certificate_key /etc/ssl/private/trento.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Wanda rule
    location /wanda/  {
        allow all;

        # Proxy Headers
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Cluster-Client-Ip $remote_addr;

        # Important Websocket Bits!
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Add final slash to replace the location path value by the value in proxy_pass
        # https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
        proxy_pass http://wanda/;
    }

    # Web rule
    location / {
        # this endpoint should not be accessible publicly
        # it is internally used by wanda to introspect access tokens and personal access tokens
        location /api/session/token/introspect {
            deny all;
            return 404;
        }

        allow all;

        # Proxy Headers
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Cluster-Client-Ip $remote_addr;

        # The Important Websocket Bits!
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_pass http://web;
    }
}

Prepare SSL certificate for NGINX

Create or provide a certificate for NGINX to enable SSL for Trento.

Create a self-signed certificate

Generate a self-signed certificate:

Adjust subjectAltName = DNS:trento.example.com by replacing trento.example.com with your domain and change the value 5 to the number of days for which you need the certificate to be valid. For example, -days 365 for one year.

openssl req -newkey rsa:2048 --nodes -keyout trento.key -x509 -days 5 -out trento.crt -addext "subjectAltName = DNS:trento.example.com"

Copy the generated trento.key to a location accessible by NGINX:
```
cp trento.key /etc/ssl/private/trento.key
```
Create a directory for the generated trento.crt file. The directory must be accessible by NGINX:
```
mkdir -p /etc/nginx/ssl/certs/
```
Copy the generated trento.crt file to the created directory:
```
cp trento.crt /etc/nginx/ssl/certs/trento.crt
```
Check the NGINX configuration:
```
nginx -t
```
If the configuration is correct, the output should be as follows:
```
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
If there are issues with the configuration, the output indicates what needs to be adjusted.
Enable NGINX:
```
systemctl restart nginx
```

Create a signed certificate with Let’s Encrypt using PackageHub repository

Only available for SLE 15 SP4-SP7, for SLE 16.0 use alternatives or the Self-signed certificate option.

Enable the PackageHub repository (replace x.x with your OS version, for example 15.7):
```
SUSEConnect --product PackageHub/x.x/x86_64
zypper refresh
```

Install Certbot and its NGINX plugin:

Service Packs include version-specific Certbot NGINX plugin packages, for example python311-certbot-nginx or python3-certbot-nginx. Install the package available in the Service Pack you currently use.

zypper install certbot python311-certbot-nginx

Obtain a certificate and configure NGINX with Certbot:

Replace example.com with your domain. For more information, refer to Certbot instructions for NGINX
```
certbot --nginx -d trento.example.com
```
Certbot certificates are valid for 90 days. Refer to the above link for details on how to renew certificates.

Accessing the trento-web UI

Pin the browser to https://trento.example.com. You should be able to login using the credentials specified in the ADMIN_USER and ADMIN_PASSWORD environment variables.

Automated deployment with Ansible

An automated installation of Trento Server using on RPM packages or Docker images can be performed with a Ansible playbook. For further information, refer to the Trento Ansible project.