Getting Started with Trento #

Trento is the official version of the Trento community project. It is a comprehensive monitoring solution consisting of two main components, the Trento Server and the Trento Agent. It provides the following features:

The Trento Server is an independent, distributed system, designed to run on a Kubernetes cluster or as a regular systemd stack. The Trento Server interacts with users via a Web front-end. It consists of the following components:

The Trento Agent is a single background process (trento agent) running on each host of the SAP infrastructure that is monitored.

See Figure 1, “Architectural overview” for additional details.

Figure 1: Architectural overview #

  

Trento is available at no extra cost for SLES for SAP 15 subscribers. Particularly, Trento's two main components have the following product lifecycles:

This section describes requirements for the Trento Server and its Trento Agents.

Important: Expect changes in the installation procedure

The product is under active development. Expect changes in the described installation procedure.

Before you can install a Trento Agent, retrieve the API key of your Trento Server. Proceed as follows:

To install the Trento Agent on an SAP host and register it with the Trento Server, repeat the steps in Procedure 2, “Installing Trento Agents”:

Trento provides a local permission-based user management feature with optional multi-factor authentication. This feature allows for segregation of duties in the Trento console and ensures that only authorized users with the right permissions can access it.

User management actions are performed in the Users view in the left-hand side panel of the Trento Web console.

By default, a newly created user is granted display access rights except for the Users view. Whenever available, a user with default access can set up filters and pagination settings matching their preferences.

Additional permissions must be added to a user profile, so that the user can perform the corresponding protected activities. The following permissions are currently available:

Using the described permissions, it is possible to create the following types of users:

The default admin user created during the installation process is granted all:all permissions and cannot be modified or deleted. Use it only to create a first user manager. That is, a user with all:users permissions who creates all the other required users. Once a user with all:users permissions is created, the default admin user must be regarded as a fall-back user to be used only in case all other access to the console is lost. If the password of the default admin user is lost, it can be reset by updating the helm chart or the web component configuration, depending on which deployment method was used to install Trento Server.

User passwords, including the default admin user password, must follow the rules below:

The Create User and Edit User views provide a built-in generation password action button that allows user managers to easily generate secure and compliant passwords. The user manager must provide the user with their password through an authorized secure channel.

A user can reset their password in the Profile view. Here, they can also update their name and email address as well as activate multi-factor authentication using an authenticator app. Multi-factor authentication increases the security of a user account by requesting a temporary second password or code when logging in the console. User managers can disable multi-factor authentication for any given user that has it enabled. However, user managers cannot enable multi-factor authentication on their behalf. The default admin user cannot enable its own multi-factor authentication.

Note: Security Tip for Multi-Factor Authentication

Since multi-factor authentication cannot be enabled for the default admin user, keeping its password safe is imperative. If the default admin user's password is compromised, reset it immediately by updating the helm chart or the web component configuration, depending on which deployment method was used to install Trento Server.

User managers can enable and disable users. When a user logged in the console is disabled by a user admin, their session is terminated immediately.

Trento can be integrated for Single Sign-On with a third-party identity provider (IDP).

Note

Trento cannot start with multiple SSO options together, so only one can be chosen.

The following protocols are supported:

7.4 Using SAML #

  

Trento integrates with an IDP that uses the SAML protocol to authenticate users accessing the Trento web console. Trento will behave as a Service Provider (SP) in this case.

Commonly, SAML protocol messages are signed with SSL. This is optional using Trento, and the signing is not required (even though it is recommended). If the IDP signs the messages, and expect signed messages back, certificates used by the SP (Trento in this case) must be provided to the IDP, the public certificate file in this case.

To use an existing SAML IDP, follow the next instrunctions to met the specific requirements. You need:

1. Obtain metadata content from the IDP

2. Start Trento to generate the certificates and get them (SAML must be enabled for this)

3. Provide the generated certificate to the IDP

4. Configure SAML IDP and user profiles

See the following subsections for details.

7.4.1 Obtaining metadata content from the IDP #

  

The metadata.xml file defines the agreement between SP and IDP during SAML communications. It is used to identify the SAML client as well. The content of this file must be provided to Trento. Options SAML_METADATA_URL and SAML_METADATA_CONTENT are available for that.

If the SAML_METADATA_CONTENT option is being used, the content of this variable must be updated with the IDP metadata as single line string. On the other hand, if SAML_METADATA_URL is used, the new metadata is automatically fetched when Trento starts. If neither of these steps are completed, communication will fail because the message signatures will not be recognized.

If the used IDP has the endpoint to provide the metadata.xml file content, prefer the variable SAML_METADATA_URL. Trento will automatically fetch metadata when started.

7.4.2 Getting certificates from Trento #

  

Trento provides a certificates set created during the installation. Regardless of the installation mode, when Trento is installed the first time and SAML is enabled the certificates are created and the public certificate file content is available in the https://#{TRENTO_WEB_ORIGIN}/api/public_keys route.

Use the following command to get the certificate content:

curl https://#{TRENTO_WEB_ORIGIN}/api/public_keys

Copy the content of the certificate from there and provide it to the IDP. This way, the IDP will sign its messages and verify the messages received from Trento.

Note

To get the certificate using this route Trento must be configured to start with SAML enabled.

7.4.3 Configuring SAML IDP setup #

  

Configure the existing IDP with the next minimum options to be able to connect with Trento as a Service Provider (SP).

7.4.3.1 Providing certificates #

  

As commented previously, a set of certificates is needed to enable signed communication. Provide the certificate generated by Trento to the IDP (each IDP has a different way to do this). Make sure that the configured certificate is used for signing and encrypting messages.

7.4.3.2 Configuring SAML user profile #

  

Users provided by the SAML installation must have some few mandatory attributes to login in Trento. The required attributes are: username, email, first name and last name. All of them are mandatory, even though their field names are configurable.

By default, Trento expects the username, email, firstName and lastName attribute names. All these 4 attribute names are configurable using the next environment variables, following the same order: SAML_USERNAME_ATTR_NAME, SAML_EMAIL_ATTR_NAME, SAML_FIRSTNAME_ATTR_NAME and SAML_LASTNAME_ATTR_NAME.

Both IDP and Trento must know how these 4 fields are mapped. To do this, follow the next instructions:

1. Add the attributes if they don't exist in the IDP user profile. If they already exist, don't change the attributes and keep their original values.

2. Configure Trento to use the IDP attribute field names. To do this, set the SAML_USERNAME_ATTR_NAME, SAML_EMAIL_ATTR_NAME, SAML_FIRSTNAME_ATTR_NAME and SAML_LASTNAME_ATTR_NAME environment values with the values configured in the IDP. For example, if the IDP user profile username is defined as attr:username use SAML_USERNAME_ATTR_NAME=attr:username.

7.4.3.3 Checking SAML redirect URI #

  

After a successful login, the IDP redirects the user's session back to Trento and redirected at https://trento.example.com/sso/sp/consume/saml. To ensure seamless SSO, this URI must be configured as valid within the IDP.

7.4.4 Enabling SAML when using kubernetes deployment #

  

To enable SAML when using kubernetes deployment with helm, proceed as follows:

1. Add the following variables to the previously documented helm installation command:

   HELM_EXPERIMENTAL_OCI=1 helm ... \
      --set trento-web.saml.enabled=true \
      --set trento-web.saml.idpId=<SAML_IDP_ID> \
      --set trento-web.saml.spId=<SAML_SP_ID> \
      --set trento-web.saml.metadataUrl=<SAML_METADATA_URL>

   To use the SAML_METADATA_CONTENT option rather than SAML_METADATA_URL use:

   HELM_EXPERIMENTAL_OCI=1 helm ... \
      --set trento-web.saml.enabled=true \
      --set trento-web.saml.idpId=<SAML_IDP_ID> \
      --set trento-web.saml.spId=<SAML_SP_ID> \
      --set trento-web.saml.metadataContent=<SAML_METADATA_CONTENT>

   Additionally, the following optional values are available:

   HELM_EXPERIMENTAL_OCI=1 helm ... \
      --set trento-web.saml.idpNameIdFormat=<SAML_IDP_NAMEID_FORMAT> \
      --set trento-web.saml.spDir=<SAML_SP_DIR> \
      --set trento-web.saml.spEntityId=<SAML_SP_ENTITY_ID> \
      --set trento-web.saml.spContactName=<SAML_SP_CONTACT_NAME> \
      --set trento-web.saml.spContactEmail=<SAML_SP_CONTACT_EMAIL> \
      --set trento-web.saml.spOrgName=<SAML_SP_ORG_NAME> \
      --set trento-web.saml.spOrgDisplayName=<SAML_SP_ORG_DISPLAYNAME> \
      --set trento-web.saml.spOrgUrl=<SAML_SP_ORG_URL> \
      --set trento-web.saml.usernameAttrName=<SAML_USERNAME_ATTR_NAME> \
      --set trento-web.saml.emailAttrName=<SAML_EMAIL_ATTR_NAME> \
      --set trento-web.saml.firstNameAttrName=<SAML_FIRSTNAME_ATTR_NAME> \
      --set trento-web.saml.lastNameAttrName=<SAML_LASTNAME_ATTR_NAME> \
      --set trento-web.saml.signRequests=<SAML_SIGN_REQUESTS> \
      --set trento-web.saml.signMetadata=<SAML_SIGN_METADATA> \
      --set trento-web.saml.signedAssertion=<SAML_SIGNED_ASSERTION> \
      --set trento-web.saml.signedEnvelopes=<SAML_SIGNED_ENVELOPES>

7.4.5 Enabling SAML when using RPM packages #

  

To enable SAML when using RPM packages, proceed as follows:

1. Open the file /etc/trento/trento-web.

2. Add the following environment variables to this file. Required variables are:

   # Required:
   ENABLE_SAML=true
   SAML_IDP_ID=<SAML_IDP_ID>
   SAML_SP_ID=<SAML_SP_ID>
   # Only SAML_METADATA_URL or SAML_METADATA_CONTENT must by provided
   SAML_METADATA_URL=<SAML_METADATA_URL>
   SAML_METADATA_CONTENT=<SAML_METADATA_CONTENT>
   
   # Optional:
   SAML_IDP_NAMEID_FORMAT=<SAML_IDP_NAMEID_FORMAT>
   SAML_SP_DIR=<SAML_SP_DIR>
   SAML_SP_ENTITY_ID=<SAML_SP_ENTITY_ID>
   SAML_SP_CONTACT_NAME=<SAML_SP_CONTACT_NAME>
   SAML_SP_CONTACT_EMAIL=<SAML_SP_CONTACT_EMAIL>
   SAML_SP_ORG_NAME=<SAML_SP_ORG_NAME>
   SAML_SP_ORG_DISPLAYNAME=<SAML_SP_ORG_DISPLAYNAME>
   SAML_SP_ORG_URL=<SAML_SP_ORG_URL>
   SAML_USERNAME_ATTR_NAME=<SAML_USERNAME_ATTR_NAME>
   SAML_EMAIL_ATTR_NAME=<SAML_EMAIL_ATTR_NAME>
   SAML_FIRSTNAME_ATTR_NAME=<SAML_FIRSTNAME_ATTR_NAME>
   SAML_LASTNAME_ATTR_NAME=<SAML_LASTNAME_ATTR_NAME>
   SAML_SIGN_REQUESTS=<SAML_SIGN_REQUESTS>
   SAML_SIGN_METADATA=<SAML_SIGN_METADATA>
   SAML_SIGNED_ASSERTION=<SAML_SIGNED_ASSERTION>
   SAML_SIGNED_ENVELOPES=<SAML_SIGNED_ENVELOPES>

3. Restart the application.

7.4.6 Enabling SAML when using Docker images #

  

To enable SAML when using Docker images, proceed as follows:

1. If trento-web container is already running stop and delete the container before continuing. For that run:

   docker stop trento-web
   docker rm trento-web

2. Use the following environment variables to the Docker container via the -e option:

   docker run -d \
   -p 4000:4000 \
   --name trento-web \
   --network trento-net \
   --add-host "host.docker.internal:host-gateway" \
   
   ...[other settings]...
   
   -e ENABLE_SAML=true
   -e SAML_IDP_ID=<SAML_IDP_ID> \
   -e SAML_SP_ID=<SAML_SP_ID> \
   # Only SAML_METADATA_URL or SAML_METADATA_CONTENT must by provided
   -e SAML_METADATA_URL=<SAML_METADATA_URL> \
   -e SAML_METADATA_CONTENT=<SAML_METADATA_CONTENT> \
   
   # Optional:
   -e SAML_IDP_NAMEID_FORMAT=<SAML_IDP_NAMEID_FORMAT> \
   -e SAML_SP_DIR=<SAML_SP_DIR> \
   -e SAML_SP_ENTITY_ID=<SAML_SP_ENTITY_ID> \
   -e SAML_SP_CONTACT_NAME=<SAML_SP_CONTACT_NAME> \
   -e SAML_SP_CONTACT_EMAIL=<SAML_SP_CONTACT_EMAIL> \
   -e SAML_SP_ORG_NAME=<SAML_SP_ORG_NAME> \
   -e SAML_SP_ORG_DISPLAYNAME=<SAML_SP_ORG_DISPLAYNAME> \
   -e SAML_SP_ORG_URL=<SAML_SP_ORG_URL> \
   -e SAML_USERNAME_ATTR_NAME=<SAML_USERNAME_ATTR_NAME> \
   -e SAML_EMAIL_ATTR_NAME=<SAML_EMAIL_ATTR_NAME> \
   -e SAML_FIRSTNAME_ATTR_NAME=<SAML_FIRSTNAME_ATTR_NAME> \
   -e SAML_LASTNAME_ATTR_NAME=<SAML_LASTNAME_ATTR_NAME> \
   -e SAML_SIGN_REQUESTS=<SAML_SIGN_REQUESTS> \
   -e SAML_SIGN_METADATA=<SAML_SIGN_METADATA> \
   -e SAML_SIGNED_ASSERTION=<SAML_SIGNED_ASSERTION> \
   -e SAML_SIGNED_ENVELOPES=<SAML_SIGNED_ENVELOPES> \
   
   ...[other settings]...

7.4.7 Available variables for SAML #

  

SAML_IDP_ID

SAML IDP id

SAML_SP_ID

SAML SP id

SAML_METADATA_URL

URL to retrieve the SAML metadata xml file. One of SAML_METADATA_URL or SAML_METADATA_CONTENT is required

SAML_METADATA_CONTENT

One line string containing the SAML metadata xml file content (SAML_METADATA_URL has precedence over this)

SAML_IDP_NAMEID_FORMAT

SAML IDP name id format, used to interpret the attribute name. Whole urn string must be used (default value: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)

SAML_SP_DIR

SAML SP directory, where SP specific required files (such as certificates and metadata file) are placed (default value: /etc/trento/saml)

SAML_SP_ENTITY_ID

SAML SP entity id. If it is not given, value from the metadata.xml file is used

SAML_SP_CONTACT_NAME

SAML SP contact name (default value: Trento SP Admin)

SAML_SP_CONTACT_EMAIL

SAML SP contact email (default value: admin@trento.suse.com)

SAML_SP_ORG_NAME

SAML SP organization name (default value: Trento SP)

SAML_SP_ORG_DISPLAYNAME

SAML SP organization display name (default value: SAML SP build with Trento)

SAML_SP_ORG_URL

SAML SP organization url (default value: https://www.trento-project.io/)

SAML_USERNAME_ATTR_NAME

SAML user profile "username" attribute field name. This attribute must exist in the IDP user (default value: username)

SAML_EMAIL_ATTR_NAME

SAML user profile "email" attribute field name. This attribute must exist in the IDP user (default value: email)

SAML_FIRSTNAME_ATTR_NAME

SAML user profile "first name" attribute field name. This attribute must exist in the IDP user (default value: firstName)

SAML_LASTNAME_ATTR_NAME

SAML user profile "last name" attribute field name. This attribute must exist in the IDP user (default value: lastName)

SAML_SIGN_REQUESTS

Sign SAML requests in the SP side (default value: true)

SAML_SIGN_METADATA

Sign SAML metadata documents in the SP side (default value: true)

SAML_SIGNED_ASSERTION

Require to receive SAML assertion signed from the IDP. Set to false if the IDP doesn't sign the assertion (default value: true)

SAML_SIGNED_ENVELOPES

Require to receive SAML envelopes signed from the IDP. Set to false if the IDP doesn't sign the envelopes (default value: true)

Trento collects system events and user actions in the Activity Log. It can be accessed from the left-hand side panel of the Trento console.

Each entry in the Activity Log includes the following:

The right chevron icon in the activity log entry opens a modal with the activity metadata.

The Activity Log allows to filter by the type of event or user action, commonly refered to as resource type, and by the user that triggered the event or performed the action. Only active users are available for filtering. The Activity Log also allows to filter out entries that are newer and/or older than an specific date and time (server time).

Once a filter has been set, the user must click Apply to filter out the undesired entries and Reset to remove all the filters.

Entries related to user management can only be displayed by users that have the all:all or all:users permissions. This includes:

Entries in the Activity Log are sorted from newer to older. By clicking Refresh, the user can update the Activity Log view with entries generated since they accessed the view, or after the last refresh.

The pagination features at the bottom of the Activity Log allow the user to specify the number of entries to display in a page, scroll back and forth through the different pages of the view, and jump directly to the last page and back to first one.

The default retention time for entries in the Activity Log is one month. This can be changed in the Activity Log section under Settings. Changing the retention time requires the all:settings permissions. Entries expired after the specified retention time are deleted every day at midnight (server time).

One of Trento's main features is to provide configuration checks that ensure your infrastructure setup adheres to our Best Practices, or other vendor's Best Practices, and does not drift away in time. Configuration checks ara available for HANA clusters, ASCS/ERS clusters and hosts. The following procedure is specific to a HANA cluster. The procedure for an ASCS/ERS cluster or a host would be exactly the same, only starting from the corresponding Details view:

Once a check selection for a given cluster has been made, Trento executes them automatically every five minutes, and results are updated accordingly. A check execution result icon spinning means that an execution is running.

The left sidebar in the Trento Web console contains the following entries:

10.1 Getting the global health state #

  

The dashboard allows you to determine at a glance the health status of your SAP environment. It is the home page of the Trento Web console, and you can go back to it any time by clicking on Dashboard in the left sidebar.

The health status of a registered SAP system is the compound of its health status at three different layers representing the SAP architecture:

• Hosts: it reflects the heartbeat of the Trento Agent and, when applicable, the compliance status.

• Pacemaker Clusters: the status here is based on the running status of the cluster and the results of the configuration checks.

• Database: it collects the status of the HANA instances as returned by sapcontrol.

• Application instances: it summarizes the status of the application instances as returned by sapcontrol.

Complementing the operating system layer, you also have information about the health status of the HA components, whenever they exit:

• Database cluster: the status here is based on the running status of the database cluster and the results of the selected configuration checks.

• Application cluster: the status here is based on the running status of the ASCS/ERS cluster and, eventually, the results of the selected configuration checks.

The dashboard groups systems in three different health boxes (see Figure 6, “Dashboard with the global health state”):

Figure 6: Dashboard with the global health state #

  

The three different health states #

  

Passing

It shows the number of systems with all layers in passing (green) status.

Warning

It shows the number of systems with at least one layer in warning (yellow) status and the rest in passing (green) status.

Critical

It shows the number of systems with at least one layer in critical (red) status.

The health boxes in the dashboard are clickable. By clicking on one particular box, you filter the dashboard by systems with the corresponding health status. In large SAP environments, this feature facilitates the SAP administrator knowing which systems are in a given status.

The icons representing the health summary of a particular layer contain links to the views in the Trento console that can help determine where an issue is coming from:

• Hosts health icon:Link to the Hosts overview, filtered by SID equal to the SAPSID and the DBSID of the corresponding SAP system.

• Database cluster health icon:Link to the corresponding SAP HANA Cluster Details view.

• Database health icon:Link to the corresponding HANA Database Details view.

• Application cluster health icon:Link to the corresponding ASCS/ERS Cluster Details view.

• Application Instances health icon:Link to the corresponding SAP System Details view.

A grey status is returned when either a component does not exist, or it is stopped (as returned by sapcontrol), or its status is unknown (for instance, if a command to determine the status fails).

Grey statuses are not yet counted in the calculation of the global health status.

When the heartbeat of an agent fails, an option to clean-up the corresponding host will show up both in the Hosts overview and the corresponding Host details view.

Figure 15: Clean up button in Hosts overview #

  

Figure 16: Clean up button in Host details view #

  

When the user clicks on the cleanup button, a box will open asking for confirmation. If the user grants it, all the components discovered by the agent in that particular host, including the host itself and other components that might depend on the ones running on the host, will be removed from the console. For example, if the user cleans up the host where the primary application server of an SAP System is registered, the entire SAP System will be removed from the console.

Similarly, when a registered application or SAP HANA instance is no longer discovered, an option to clean it up will show up both in the corresponding overview and the corresponding details view.

Figure 17: Clean up button SAP systems overview #

  

Figure 18: Clean up button in SAP system details view #

  

When the user clicks the cleanup button, a box will open asking for confirmation. If the user grants it, the instance will be removed from the console along with any possible dependencies For example, if the user cleans up the ASCS instance of an SAP system, the entire SAP system will be removed from the console.

Tags are a means to label specific objects with a purpose, location, owner, or any other property you like. Such objects can be hosts, clusters, databases, or SAP systems. Tags make it easier to distinguish and show all these different objects, making your lists more readable and searchable. You can use any text you like to create your tags except blank spaces and special characters other than + - = . , _ : and @.

The following subsection shows how you can add, remove, and filter objects based on your tags.

Trento integrates with SUSE Manager to provide the SAP administrator with information about relevant patches and upgradable packages for any host that is registered with both applications.

The user must enter the connection settings for SUSE Manager in the Settings view:

Figure 19: SUSE Manager settings #

  

Once the SUSE Manager settings are configured, the SAP Basis administrator can test the connection by clicking the Test button. If the connection is successful, the Host Details view of each host managed by SUSE Manager displays a summary of available patches and upgradable packages:

Figure 20: Availale software updates in the Host Details view #

  

Click on Relevant Patches to open the Relevant Patches overview containing a list of patches available for that particular host:

Figure 21: Available Patches overview #

  

Click Upgradable Packages to open the Upgradable Packages overview containing a list of packages that can be upgraded on that particular host:

Figure 22: Upgradable Packages overview #

  

By clicking on an advisory or patch link, the user will access the corresponding details view, with relevant information about it such us whether it requires a reboot or not, associated vulnerabilities, or a list of affected hosts:

Figure 23: Advisory Details view #

  

There are three types of patches or advisories: security advisories, bug fixes and feature enhancements. Security advisories are regarded as critical. If one is avaiable, the health of the host will be set to critical. If there are available patches but none of them is a security one, the health of the host will switch to warning. When a host cannot be found in SUSE Manager or there is a problem retrieving the data for it, its health is set as unknnown.

At any time, the user can clear the SUSE Manager settings from the Settings view. As a result, all information about available software updates disappears from the console and the status of the hosts is adjusted accordingly.

The communication from the Trento Agent to the Trento Server is secured by a API key which must be provided in the agent configuration file.

By default, the API key does not have an expiration date. To increase the overall security of the setup, meet internal security requirements, or both, the user can set up a custom expiration date.

To do that, go to the Settings view and click the Generate Key button in the API Key section:

Figure 24: Checks catalog #

  

Whenever a new key is generated, the configuration of all the reporting agents must be updated accordingly.

The procedure to update Trento Server depends on the chosen deployment option: Kubernetes, systemd or containerized.

Consider the following when performing an update:

In a Kubernetes deployment, you can use Helm to update Trento Server:

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

If you have configured options, such as email alerting, the Helm command must be adjusted accordingly. Additional considerations in this scenario:

In a system deployment, you can use zypper to update Trento Server:

 zypper refresh
 zypper update trento-web
 zypper update trento-wanda
 systemctl restart trento-web
 systemctl restart trento-wanda

In a containerized deployment, you can use the same docker commands as for the installation. Keep in mind that the volume for the Trento checks already exists, so there is no need to create it again. Also, the web and wanda containers must be stopped and removed before they can be redeployed with the latest version. In addition, make sure to include in the docker commands any other options that you have enabled after the original installation.

To update the Trento Agent, do the following:

Configuration checks are an integral part of the checks engine, but they are delivered separately from it. This allows customers to update the checks catalog in their setup whenever updates to existing checks and new checks are released, without waiting for a new version release cycle.

The procedure of updating the configuration checks depends on the Trento Server deployment type: Kubernetes, systemd or containerized.

In a k8s; deployment, checks are delivered as a container image and you can use Helm with the following options to pull the latest one available into your setup:

    helm ... \
   --set trento-wanda.checks.image.tag=latest \
   --set trento-wanda.checks.image.repository=registry.suse.com/trento/trento-checks  \
   --set trento-wanda.checks.image.pullPolicy=Always \
   ...

In a systemd deployment, checks are delivered as an RPM package, and you can use zypper to update your checks catalog to the latest version:

> sudo zypper ref
> sudo zypper update trento-checks

In a containerized deployment, checks are delivered as a container image, and you can user Docker to pull the latest version into the trento-checks volume that was created during the installation process:

> docker run \
  -v trento-checks:/usr/share/trento/checks \
  registry.suse.com/trento/trento-checks:latest

The procedure to uninstall the Trento Server depends on the deployment type: Kubernetes, systemd or containerized. The section covers Kubernetes deployments.

If Trento Server was deployed manually, then you need to uninstall it manually. If Trento Server was deployed using the Helm chart, you can also use Helm to uninstall it as follows:

helm uninstall trento-server

To uninstall a Trento Agent, perform the following steps:

Any SUSE customer, with a registered SUSE Linux Enterprise Server for SAP Applications 15 (SP3 or higher) distribution, experiencing an issue with Trento, can report the problem either directly in the SUSE Customer Center or through the corresponding vendor, depending on their licensing model. Problems must be reported under SUSE Linux Enterprise Server for SAP Applications 15 and component trento.

When opening a support case for Trento, provide the chosen deployment option for Trento Server: Kubernetes, systemd or containerized.

In case of a Kubernetes deployment, provide the output of the Trento support plugin and the scenario dump, as explained in section Section 21, “Problem Analysis”.

In case of a systemd deployment, provide the status and the journal of the trento-web and trento-wanda services.

In case of a containerized deployment, provide the logs of the trento-web and trento-wanda containers. Use docker ps to retrieve the IDs of both containers, then docker logs CONTAINER_ID to retrieve the corresponding logs.

For issues with a particular Trento Agent, or a component discovered by a particular Trento Agent, also provide the following:

This section covers some common problems and how to analyze them.

> sudo systemctl status trento-agent

The following list shows the most important user-facing features in the different versions of Trento. For a more detailed information about the changes included in each new version, visit the GitHub project at https://github.com/trento-project. Particularly: