Applies to SUSE Linux Enterprise Server 15 SP5

2 RMT installation and configuration #

RMT is included in SUSE Linux Enterprise Server starting with version 15. Install RMT directly during the installation of SUSE Linux Enterprise Server or install it on a running system. After the packages are installed, use YaST to do an initial configuration.

Warning: RMT server conflicts with installation server

Configuring a server to be an RMT server installs and configures the NGINX Web server, listening on port 80.

However, configuring a machine to be an installation server automatically installs the Apache Web server and configures it to listen on port 80.

Do not try to enable both these functions on the same server. It is not possible for a single server to host both simultaneously.

2.1 Storage requirements #

Downloaded packages are stored in /usr/share/rmt/public/repo, which is a symbolic link to /var/lib/rmt/public/repo/.

The amount of storage your RMT server requires depends on several variables: the number of repositories and architectures that you mirror, and the number of products that are enabled. As a general guide, 1.5 times the total size of all enabled repositories should be sufficient. This is about 200 GB per SUSE Linux Enterprise release, including all extensions.

2.2 Installation during system installation #

To install it during installation, select the rmt-server package. Package selection can be found in Installation Settings when selecting Software.

Figure 2.1: RMT pattern #

Check for available RMT updates immediately after installing SUSE Linux Enterprise Server using the zypper patch command because SUSE continuously releases maintenance updates for RMT.

2.3 Installation on an existing system #

To install RMT on a running SUSE Linux Enterprise Server installation, use zypper:

> sudo zypper in rmt-server

2.3.1 Installation on SLES Minimal VM #

SLES Minimal VM is a minimal customizable operating system that is designed for specific usage scenarios, for example, to be run as:

A container host
A virtual machine guest
An appliance base system
A small server image

SLES Minimal VM image is a good choice for being used as an RMT server. You can download SLES Minimal VM images for KVM, Xen, Microsoft Hyper-V, VMware, and OpenStack from the public SUSE Linux Enterprise Server download page at https://www.suse.com/download/sles/. Find more information on SLES Minimal VM at https://documentation.suse.com/sles/html/SLES-all/article-minimal-vm.html.

Installing RMT on SLES Minimal VM is the same as installing it on an existing system (see Section 2.3, “Installation on an existing system”. To install RMT on SLES Minimal VM, run the following command from the SLES Minimal VM command line as root:

# zypper install rmt-server yast2-rmt nginx mariadb

Important: Hardware requirements

When installing RMT on SLES Minimal VM, be aware that it requires a minimum of 100 GB disk space, depending on the products you select to mirror. Another requirement is a CPU with at least two cores and 2 GB of RAM.

2.4 Deploying RMT on top of the Kubernetes cluster #

This section describes how to deploy RMT on top of the Kubernetes cluster. It uses Helm as the package manager to interact with the Kubernetes cluster. Find more details about using Helm at https://helm.sh/docs/intro/using_helm/.

2.4.1 Prerequisites #

Running Kubernetes cluster
helm command configured to interact with the cluster

2.4.2 Application components #

Each component of the RMT application is deployed in its own container. RMT consists of the following components:

RMT server: Containerized version of the RMT application server with the ability to pass its configuration via Helm values. Storage is done on a volume that is allocated to the Kubernetes cluster. You need to adjust the size of the storage depending on the number of repositories you need to mirror.
MariaDB: The database back-end for RMT. No post-installation task is needed since RMT creates the required database and tables at start-up. If passwords are not specified in the values.yaml file, they are generated automatically.
Nginx: A Web server configured for RMT routes. Having a properly configured Web server allows you to target your Ingress traffic (for RMT) to this Nginx service directly. You do not need to configure Ingress for RMT specific paths handling, as Nginx is configured to take care of this itself.

2.4.3 The `values.yaml` file #

The RMT chart includes the values.yaml file where all parameters are documented and their default values are defined. You can override these values by providing your own values file, for example:

> cat << EOF > rmt-config.yaml
---
app:
  storage:
    class: local-path1
  scc:
    username: "UXXXXXXX"
    password: "PASSXXXX"
    products_enable:
      - SLES/15.3/x86_64
      - sle-module-python2/15.3/x86_64
    products_disable:
      - sle-module-legacy/15.3/x86_64
      - sle-module-cap-tools/15.3/x86_64
db:
  storage:
    class: local-path2
ingress:
  enabled: true
  hosts:
    - host: chart-example.local
      paths:
        - path: "/"
          pathType: Prefix
  tls:
    - secretName: rmt-cert
      hosts:
        - chart-example.local
EOF

1 2

The local-path storage class is only available in Rancher workloads. To make the helm chart succeed, you need to install the local-path storage provisioner by running the following command:

> kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.26/deploy/local-path-storage.yaml

And to install RMT, run:

> helm install rmtsle oci://registry.suse.com/suse/rmt-helm -f rmt-config.yaml

2.4.3.1 Required values #

Key: app.scc.password

Type: string

Default: nil

Description: SUSE Customer Center proxy password. The password string needs to be put inside quotes. If the quote character " is part of the string, it has to be escaped with \.

Key: app.scc.username

Type: string

Default: nil

Description: SUSE Customer Center proxy user name. The user name string needs to be put inside quotes. If the quote character " is part of the string, it has to be escaped with \.

Key: app.scc.products_enable

Type: list

Default: []

Description: list of products to enable for mirroring

Key: app.scc.products_disable

Type: list

Default: []

Description: list of products to disable for mirroring

Key: app.storage.class

Type: string

Default: ""

Description: Kubernetes storageclass.

Key: db.storage.class

Type: string

Default: ""

Description: Kubernetes storageclass.

Key: ingress.enabled

Type: bool

Default: false

Description: Ingress Enabled

Key: ingress.hosts[0]

Type: object

Default: {"host":"chart-example.local","paths":[{"path":"/","pathType":"Prefix"}]}

Description: DNS name at which the RMT service will be accessible from clients

Key: ingress.tls[0].hosts[0]

Type: string

Default: "chart-example.local"

Description: DNS name at which the RMT service will be accessible from clients

Key: ingress.tls[0].secretName

Type: string

Default: "rmt-cert"

Description: TLS Ingress Certificate

2.5 RMT configuration with YaST #

Configure RMT with YaST as described in the following procedure. It is assumed that this procedure is executed on a newly installed system.

Start YaST with the rmt module.
```
> sudo yast2 rmt
```
Alternatively, start YaST and select Network Services › RMT Configuration.
Enter your organization credentials. To retrieve your credentials, refer to Section 4.1, “Mirroring credentials”.
Enter credentials for a new MariaDB user and database name, and confirm with Next.
If a password for the MariaDB root user is already set, you are required to enter it. If no password is set for root, you are asked to enter a new one.
Enter a common name for the SSL certificates. The common name should be the fully qualified domain name (FQDN) of the server. Enter all domain names and IP addresses with which you want to reach the RMT server as alternative common names.
When all common names are entered, select Next.
Tip: Certificate locations for RMT
- /etc/rmt/ssl/rmt-ca.crt
  This is the CA certificate bundle that yast2 rmt uses to certify the RMT server certificate. yast2 rmt only creates this file if it does not already exist.
- /etc/rmt/ssl/rmt-server.crt and /etc/rmt/ssl/rmt-server.key
  yast2 rmt only generates a new server certificate and private key if one does not already exist. To regenerate this certificate, refer to Section 8.1, “Regenerating HTTPS certificates”.
If firewalld is enabled on this system, enable the check box to open the required ports.
Figure 2.2: Enabling ports in firewalld #

If firewalld is not enabled now and you plan to enable it later, you can always open relevant ports by running the yast2 rmt module.
Tip: Fine-tuning firewalld settings
By clicking Firewall Details, you can open the relevant ports for specific network interfaces only.
Continue with Next.
To view the summary, click Next. Close YaST by clicking Finish. YaST then enables and starts all systemd services and timers.

2.6 Enabling SLP announcements #

RMT includes the SLP service description file /etc/slp.reg.d/rmt-server.reg. To enable SLP announcements of the RMT service, follow these steps:

If firewalld is running, open relevant ports and reload the firewalld configuration:

> sudo firewall-cmd --permanent --add-port=427/tcp
success
> sudo firewall-cmd --permanent --add-port=427/udp
success
> sudo firewall-cmd --reload

Verify that the SLP server is installed and install it if it is not:
```
> sudo zypper install openslp-server
```

Enable and start the SLP service:

> sudo systemctl enable slpd.service
> sudo systemctl restart slpd.service

2 RMT installation and configuration #

2.1 Storage requirements #

2.2 Installation during system installation #

2.3 Installation on an existing system #

2.3.1 Installation on SLES Minimal VM #

2.4 Deploying RMT on top of the Kubernetes cluster #

2.4.1 Prerequisites #

2.4.2 Application components #

2.4.3 The values.yaml file #

2.4.3.1 Required values #

2.5 RMT configuration with YaST #

2.6 Enabling SLP announcements #

2.4.3 The `values.yaml` file #