Jump to content
documentation.suse.com / RMT Guide
SUSE Linux Enterprise Server 15 SP4

Repository Mirroring Tool Guide

An administrator's guide to Repository Mirroring Tool—a proxy system for SUSE Customer Center with repository and registration targets.

Publication Date: December 13, 2024

Copyright © 2006–2024 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled GNU Free Documentation License.

For SUSE trademarks, see https://www.suse.com/company/legal/. All third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.

All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof.

Preface

1 Available documentation

Online documentation

Our documentation is available online at https://documentation.suse.com. Browse or download the documentation in various formats.

Note
Note: Latest updates

The latest updates are usually available in the English-language version of this documentation.

SUSE Knowledgebase

If you have run into an issue, also check out the Technical Information Documents (TIDs) that are available online at https://www.suse.com/support/kb/. Search the SUSE Knowledgebase for known solutions driven by customer need.

Release notes

For release notes, see https://www.suse.com/releasenotes/.

In your system

For offline use, the release notes are also available under /usr/share/doc/release-notes on your system. The documentation for individual packages is available at /usr/share/doc/packages.

Many commands are also described in their manual pages. To view them, run man, followed by a specific command name. If the man command is not installed on your system, install it with sudo zypper install man.

2 Improving the documentation

Your feedback and contributions to this documentation are welcome. The following channels for giving feedback are available:

Service requests and support

For services and support options available for your product, see https://www.suse.com/support/.

To open a service request, you need a SUSE subscription registered at SUSE Customer Center. Go to https://scc.suse.com/support/requests, log in, and click Create New.

Bug reports

Report issues with the documentation at https://bugzilla.suse.com/.

To simplify this process, click the Report an issue icon next to a headline in the HTML version of this document. This preselects the right product and category in Bugzilla and adds a link to the current section. You can start typing your bug report right away.

A Bugzilla account is required.

Contributions

To contribute to this documentation, click the Edit source document icon next to a headline in the HTML version of this document. This will take you to the source code on GitHub, where you can open a pull request.

A GitHub account is required.

Note
Note: Edit source document only available for English

The Edit source document icons are only available for the English version of each document. For all other languages, use the Report an issue icons instead.

For more information about the documentation environment used for this documentation, see the repository's README.

Mail

You can also report errors and send feedback concerning the documentation to <>. Include the document title, the product version, and the publication date of the document. Additionally, include the relevant section number and title (or provide the URL) and provide a concise description of the problem.

3 Documentation conventions

The following notices and typographic conventions are used in this document:

  • /etc/passwd: Directory names and file names

  • PLACEHOLDER: Replace PLACEHOLDER with the actual value

  • PATH: An environment variable

  • ls, --help: Commands, options, and parameters

  • user: The name of a user or group

  • package_name: The name of a software package

  • Alt, AltF1: A key to press or a key combination. Keys are shown in uppercase as on a keyboard.

  • File, File › Save As: menu items, buttons

  • AMD/Intel This paragraph is only relevant for the AMD64/Intel 64 architectures. The arrows mark the beginning and the end of the text block.

    IBM Z, POWER This paragraph is only relevant for the architectures IBM Z and POWER. The arrows mark the beginning and the end of the text block.

  • Chapter 1, Example chapter: A cross-reference to another chapter in this guide.

  • Commands that must be run with root privileges. You can also prefix these commands with the sudo command to run them as a non-privileged user:

    # command
    > sudo command
  • Commands that can be run by non-privileged users:

    > command
  • Commands can be split into two or multiple lines by a backslash character (\) at the end of a line. The backslash informs the shell that the command invocation will continue after the line's end:

    > echo a b \
    c d
  • A code block that shows both the command (preceded by a prompt) and the respective output returned by the shell:

    > command
    output
  • Notices

    Warning
    Warning: Warning notice

    Vital information you must be aware of before proceeding. Warns you about security issues, potential loss of data, damage to hardware, or physical hazards.

    Important
    Important: Important notice

    Important information you should be aware of before proceeding.

    Note
    Note: Note notice

    Additional information, for example about differences in software versions.

    Tip
    Tip: Tip notice

    Helpful information, like a guideline or a piece of practical advice.

  • Compact Notices

    Note

    Additional information, for example about differences in software versions.

    Tip

    Helpful information, like a guideline or a piece of practical advice.

4 Support

Find the support statement for SUSE Linux Enterprise Server and general information about technology previews below. For details about the product lifecycle, see https://www.suse.com/lifecycle.

If you are entitled to support, find details on how to collect information for a support ticket at https://documentation.suse.com/sles-15/html/SLES-all/cha-adm-support.html.

4.1 Support statement for SUSE Linux Enterprise Server

To receive support, you need an appropriate subscription with SUSE. To view the specific support offers available to you, go to https://www.suse.com/support/ and select your product.

The support levels are defined as follows:

L1

Problem determination, which means technical support designed to provide compatibility information, usage support, ongoing maintenance, information gathering and basic troubleshooting using available documentation.

L2

Problem isolation, which means technical support designed to analyze data, reproduce customer problems, isolate a problem area and provide a resolution for problems not resolved by Level 1 or prepare for Level 3.

L3

Problem resolution, which means technical support designed to resolve problems by engaging engineering to resolve product defects which have been identified by Level 2 Support.

For contracted customers and partners, SUSE Linux Enterprise Server is delivered with L3 support for all packages, except for the following:

  • Technology previews.

  • Sound, graphics, fonts, and artwork.

  • Packages that require an additional customer contract.

  • Some packages shipped as part of the module Workstation Extension are L2-supported only.

  • Packages with names ending in -devel (containing header files and similar developer resources) will only be supported together with their main packages.

SUSE will only support the usage of original packages. That is, packages that are unchanged and not recompiled.

4.2 Technology previews

Technology previews are packages, stacks, or features delivered by SUSE to provide glimpses into upcoming innovations. Technology previews are included for your convenience to give you a chance to test new technologies within your environment. We would appreciate your feedback. If you test a technology preview, please contact your SUSE representative and let them know about your experience and use cases. Your input is helpful for future development.

Technology previews have the following limitations:

  • Technology previews are still in development. Therefore, they may be functionally incomplete, unstable, or otherwise not suitable for production use.

  • Technology previews are not supported.

  • Technology previews may only be available for specific hardware architectures.

  • Details and functionality of technology previews are subject to change. As a result, upgrading to subsequent releases of a technology preview may be impossible and require a fresh installation.

  • SUSE may discover that a preview does not meet customer or market needs, or does not comply with enterprise standards. Technology previews can be removed from a product at any time. SUSE does not commit to providing a supported version of such technologies in the future.

For an overview of technology previews shipped with your product, see the release notes at https://www.suse.com/releasenotes.

1 Overview

The Repository Mirroring Tool (RMT) for SUSE Linux Enterprise 15 SP4 allows enterprise customers to optimize the management of SUSE Linux Enterprise software updates and subscription entitlements. It establishes a proxy system for SUSE® Customer Center with repositories and registration targets. This helps you to centrally manage software updates within a firewall on a per-system basis, while maintaining your corporate security policies and regulatory compliance.

RMT allows you to provision updates for all of your devices running a product based on SUSE Linux Enterprise. By downloading these updates once and distributing them throughout the enterprise, you can set more restrictive firewall policies. This also reduces bandwidth usage, as there is no need to download the same updates for each device. RMT is fully supported and available as a download for customers with an active SUSE Linux Enterprise product subscription.

Repository Mirroring Tool provides functionality that can be useful in many situations, including the following:

  • You want to update SUSE Linux Enterprise servers.

  • Not all machines in your environment can be connected to SUSE Customer Center to register and retrieve updates for bandwidth or security reasons.

  • There are SUSE Linux Enterprise hosts that are restricted and difficult to update without putting in place a custom update management solution.

  • You need to integrate additional external or internal repositories.

RMT
Figure 1.1: RMT

RMT replaces SMT (Subscription Management Tool) which was used for SLE 11 and SLE 12. For a feature comparison between RMT and SMT, see Table 3.1, “Feature comparison”.

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
Warning: RMT server will conflict 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. The package selection is available in the Installation Settings step of the installation when selecting Software.

RMT pattern
Figure 2.1: RMT pattern

We recommend to check for available RMT updates immediately after installing SUSE Linux Enterprise Server using the zypper patch command. SUSE continuously releases maintenance updates for RMT, and newer packages are likely to be available.

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/15-SP4/html/SLES-all/article-minimal-vm.html.

The installation of RMT on SLES Minimal VM works identical to installing it on an already installed 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
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 will be allocated on 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. RMT creates the required database and tables at start-up, therefore no specific post-installation task is required. 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:
    enabled: false
    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.

  1. Start YaST with the rmt module.

    > sudo yast2 rmt

    Alternatively, start YaST and select Network Services › RMT Configuration.

  2. Enter your organization credentials. To retrieve your credentials, refer to Section 4.1, “Mirroring credentials”.

  3. Enter credentials for a new MariaDB user and database name. This user will then be created. Then select 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.

  4. Enter a common name for the SSL certificates. The common name should usually 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
    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 will only create this file if it does not already exist.

    • /etc/rmt/ssl/rmt-server.crt and /etc/rmt/ssl/rmt-server.key

      yast2 rmt will only generate 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”.

  5. If firewalld is enabled on this system, enable the check box to open the required ports.

    Enabling ports in firewalld
    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
    Tip: Fine-tuning firewalld settings

    By clicking Firewall Details, you can open the relevant ports for specific network interfaces only.

    Continue with Next.

  6. 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:

  1. 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
  2. Verify that SLP server is installed and possibly install it:

    > sudo zypper install openslp-server
  3. Enable and start the SLP service:

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

3 Migrate from SMT to RMT

This chapter describes the migration from SMT on SLES 11 or 12 to RMT on SLES 15.

3.1 Important notes

Warning
Warning: Read this section carefully

Carefully read this section. It contains vital information about the migration process.

Use a new host

We recommend that you install RMT on a newly-installed SLES 15 host. RMT is not a complete replacement for SMT. It has a different workflow than SMT and only supports registering SUSE Linux Enterprise Server 12 systems and newer.

Repository metadata and settings

The settings of staged repositories will not be exported from SMT. Repositories that have been marked to be mirrored will be exported.

Custom repositories

It is only possible to export repositories that are marked for mirroring.

Expired subscriptions

Products no longer available on the organization subscriptions will not be available on RMT.

Client information

Systems and their activated products will be exported. SMT client jobs and patch status will not be exported from SMT.

Table 3.1: Feature comparison

Feature

SMT

RMT

Available on SLES 11

yes

no

Available on SLES 12

yes

no

Available on SLES 15

no

yes

Synchronize products with SUSE Customer Center

yes

yes

Mirror RPMs from repositories

yes

yes

Selective mirroring (specifying products to mirror)

yes

yes

Serve RPMs via HTTP

yes

yes

Registration of SLE 15 systems

yes

yes

Registration of SLE 12 systems

yes

yes

Registration of SLE 11 systems

yes

no

Red Hat 6 and earlier support

yes 1

no

Red Hat 7+ support

yes 1

yes 1

Support for migrating SLE 12 to 15

yes 2

yes

Support for migrating SLE 15 SPx to 15 SPx+1

yes 2

yes

Staging repositories

yes

no 3

Offline mirroring

yes

yes

NTLM Proxy support

yes

yes

Custom repositories

yes

yes

YaST installation wizard

yes

yes

YaST management wizard

yes

no

Client management

yes

no

Files deduplication

yes

yes

Data transfer from SMT to RMT

n/a

yes

Transfer registration data to SUSE Customer Center

yes

yes

Reporting

yes

no

Custom TLS certificates for Web server

yes

yes

Clean up data from repositories that are not used any longer

yes

yes

Bash completion

no

yes

Available on openSUSE Leap 15

no

yes 4

Easy development setup + contribution guide

no

yes

100% test coverage

no

yes

Plugin functionality

no

yes

Web server

Apache2

Nginx

Platform

Perl

Ruby

Clean up data from repositories that are no longer used

yes

yes

Bash completion

no

yes

Option to deploy on Kubernetes

no

yes 5

  1. Support via SUSE Liberty Linux, find more details in https://www.suse.com/products/suse-liberty-linux/.

  2. SMT only partially supports migrating systems to SLE 15. SLE 15 is composed of multiple modules and extensions. Some modules are not required, as they provide additional functionality. RMT fully supports migrations into and within SLE 15, therefore it only adds the minimum of required modules. SMT does not fully support these migrations, and it enables all available modules on the system.

  3. Functionality is offered by SUSE Manager.

  4. Only available with self-support.

  5. Find more details in Section 2.4, “Deploying RMT on top of the Kubernetes cluster”.

3.2 Exporting SMT data

Procedure 3.1: Export SMT data
  1. Update your SMT server installation by running zypper up.

  2. If you want to export your SSL certificates along with the rest of the data, run smt-data-export. Remember to keep your certificates in a safe place.

    If you do not want to export the SSL certificates from SMT, run smt-data-export --no-ssl-export.

  3. The exported configuration is now saved to smt-data-export.TIMESTAMP.tar.gz. Copy the file to a location that can be accessed by the new RMT server.

3.3 Importing SMT data to RMT

  1. To make sure your RMT installation is up to date, run zypper up.

  2. Copy the exported .tar.gz file to an empty directory and unpack it. Then enter the new directory:

    > mkdir EMPTY_DIR
    > cd EMPTY_DIR
    > tar xf /PATH/TO/smt-data-export.TIMESTAMP.tar.gz
    > cd smt-data-export
  3. If you chose to export the SSL certificates from SMT, copy the CA private key and certificate to /etc/rmt/ssl/:

    > sudo cp ssl/cacert.key /etc/rmt/ssl/rmt-ca.key
    > sudo cp ssl/cacert.pem /etc/rmt/ssl/rmt-ca.crt
  4. Run the YaST RMT configuration module as described in Section 2.5, “RMT configuration with YaST”. If you imported the SMT CA certificate, add the domain of the SMT server to the common names of the new SSL certificate.

  5. Run the RMT synchronization to get the products and repositories data from SUSE Customer Center.

    > sudo rmt-cli sync
  6. Import the data from the SMT server.

    > sudo rmt-data-import -d ./
  7. Optional: If the URL of the RMT server changed, change the URL parameter of clients in /etc/SUSEConnect to point to the new RMT server. Alternatively, change the DNS records to re-assign the host name to the RMT server.

  8. Optional: Move the mirrored repository data from SMT to RMT, and adjust the ownership of the copied data.

    > sudo cp -r /var/www/htdocs/repo/* /usr/share/rmt/public/repo/
    > sudo chown -R _rmt:nginx /usr/share/rmt/public/repo
    Tip
    Tip

    The path for storing custom repository data on the RMT server is different from that of SMT. With RMT, it replicates the directory structure of the source server's URL into a top level directory. For example, if the URL of the custom repository is

    http://download.opensuse.org/debug/distribution/leap/15.4/repo/oss

    its path on the RMT server will be

    /usr/share/rmt/public/repo/debug/distribution/leap/15.4/repo/oss
  9. Custom repositories on the SMT server are disabled by default. If you want to mirror them to the RMT, enable them before mirroring.

    1. Check for custom repositories by running:

      > sudo rmt-cli repos custom list

      A table of all custom repositories will be shown. The first column contains the ID of each repository and the Mirror? column will show false.

    2. Enable each custom repository you want to mirror by running:

      > sudo rmt-cli repos custom enable ID
  10. Update the packages in the repositories by starting the mirroring process:

    > sudo rmt-cli mirror

4 Mirroring repositories on the RMT server

You can mirror the installation and update repositories on the RMT server. This way, you do not need to download updates on each machine, which saves time and capacity.

In its default configuration, RMT mirrors enabled product repositories automatically once every night.

By default, the mirrored repositories are stored in /var/lib/rmt/public/repo.

Note
Note: Change the default location of the mirrored repositories

To change the default location of the mirrored repositories, point the /usr/share/rmt/public/repo symbolic link to the desired directory. This can be done using the command:

ln -sfn TARGET /usr/share/rmt/public/repo

(Replace TARGET with the desired destination). Make sure that the target has read and write permissions for the rmt user and nginx group.

When enabled repositories are fully mirrored, you can register your client systems against RMT by running SUSEConnect --url https://RMT_HOSTNAME on the client machine. After successful registration, the repositories from the RMT server are used by Zypper on the client machine.

Important
Important: SUSE Linux Enterprise Server 11 clients

RMT does not support clients with SUSE Linux Enterprise Server versions 11 and older.

4.1 Mirroring credentials

You need organization credentials to create a local mirror of the SUSE Linux Enterprise repositories. You can obtain the credentials from SUSE Customer Center.

To get the credentials from SUSE Customer Center, follow these steps:

  1. Visit SUSE Customer Center at https://scc.suse.com and log in.

  2. If you are a member of multiple organizations, select the organization you want to work with from the sidebar on the left.

  3. Select Proxies in the top menu.

  4. The credentials are displayed in the top right corner.

  5. To see the password, click the Eye icon icon.

The obtained credentials should be set with the YaST RMT Server Configuration module or added directly to the /etc/rmt.conf file. For more information about the /etc/rmt.conf file, see Section 6.3.1, “/etc/rmt.conf”.

4.2 Synchronizing repository metadata

The local RMT database needs to be updated periodically with the information downloaded from SUSE Customer Center. This includes information about available products and repositories.

The synchronization is activated by the systemd timer rmt-server-sync.timer. To view its status, for example, the next running time, use systemctl status.

> sudo systemctl status rmt-server-sync.timer
● rmt-server-sync.timer - RMT Sync timer
   Loaded: loaded (/usr/lib/systemd/system/rmt-server-sync.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Fri 2018-06-22 04:22:34 EDT; 2h 34min ago
  Trigger: Sat 2018-06-23 03:53:00 EDT; 20h left

Jun 22 04:22:34 d31 systemd[1]: Started RMT Sync timer.

If the timer is not enabled or started, start it manually.

> sudo systemctl enable --now rmt-server-sync.timer

To update the RMT database manually, use the rmt-cli sync command. For details, see Section 6.1.2, “sync.

4.3 Mirroring packages

Packages for enabled repositories are mirrored on your RMT server. Packages are downloaded periodically once a day. But the download can also be triggered manually at any time.

The periodic mirroring is activated by the systemd timer rmt-server-mirror.timer. To show its status, for example, the next running time, use systemctl status.

# systemctl status rmt-server-mirror.timer
● rmt-server-mirror.timer - RMT Mirror timer
   Loaded: loaded (/usr/lib/systemd/system/rmt-server-mirror.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Fri 2018-06-22 04:22:34 EDT; 2h 34min ago
  Trigger: Sat 2018-06-23 02:17:57 EDT; 19h left

Jun 22 04:22:34 d31 systemd[1]: Started RMT Mirror timer.

If the timer is not enabled or started, start it manually.

> sudo systemctl enable --now rmt-server-mirror.timer

To update the mirrored packages manually, use the rmt-cli mirror command. For details, see Section 6.1.6, “mirror.

4.4 Enabling and disabling mirroring of repositories

You can enable or disable the mirroring of repositories individually or by product. You can specify one or more repositories or products at once. When repositories are enabled, their packages are downloaded and updated during the mirroring process. To enable or disable mirroring of repositories, you either need the product string or ID, or the repository name or ID. Enabling or disabling a product is desired, because this automatically enables or disables all repositories associated with the product.

4.4.1 Using products

To enable or disable all repositories of a product, use the rmt-cli products enable ID and rmt-cli products disable ID commands. To retrieve an ID for an enabled product, use the rmt-cli products list command. To get the ID of a disabled product that is still available, run the rmt-cli products list --all command.

Example:

> sudo rmt-cli products list --all
+------+----------------------+---------+--------+--------------+---------------
| ID   | Product              | Version | Arch   | Mirror?      | Last mirrored
+------+----------------------+---------+--------+--------------+---------------
[...]
| 1743 | SUSE Package Hub     | 15      | x86_64 | Don't Mirror |
|      | PackageHub/15/x86_64 |         |        |              |
[...]

> sudo rmt-cli products enable 1743
Found product by target 1743: SUSE Package Hub 15 x86_64.
Enabling SUSE Package Hub 15 x86_64:
  SUSE Package Hub 15 x86_64:
    Enabled repository SLE-Module-Packagehub-Subpackages15-Pool.
    Enabled repository SLE-Module-Packagehub-Subpackages15-Updates.
    Enabled repository SUSE-PackageHub-15-Pool.
    Enabled repository SUSE-PackageHub-15-Standard-Pool..

> sudo rmt-cli products disable 1743
Found product by target 1743: SUSE Package Hub 15 x86_64.
Disabling SUSE Package Hub 15 x86_64:
  SUSE Package Hub 15 x86_64:
    Disabled repository SLE-Module-Packagehub-Subpackages15-Pool.
    Disabled repository SLE-Module-Packagehub-Subpackages15-Updates.
    Disabled repository SUSE-PackageHub-15-Pool.
    Disabled repository SUSE-PackageHub-15-Standard-Pool.

 To clean up downloaded files, run 'rmt-cli repos clean'
Tip
Tip: Enabling and disabling multiple products at once

To enable or disable multiple products at once, specify a space-delimited list of their IDs or product strings, for example:

> sudo rmt-cli products enable 1743 SLES/15/x86_64 SLES/12
Found product by target 1743: SUSE Package Hub 15 x86_64.
Enabling SUSE Package Hub 15 x86_64:
  SUSE Package Hub 15 x86_64:
    Enabled repository SLE-Module-Packagehub-Subpackages15-Pool.
    Enabled repository SLE-Module-Packagehub-Subpackages15-Updates.
    Enabled repository SUSE-PackageHub-15-Pool.
    Enabled repository SUSE-PackageHub-15-Standard-Pool.
Found product by target SLES/15/x86_64: SUSE Linux Enterprise Server 15 x86_64.
Enabling SUSE Linux Enterprise Server 15 x86_64:
  SUSE Linux Enterprise Server 15 x86_64:
    Enabled repository SLE-Product-SLES15-Pool.
    Enabled repository SLE-Product-SLES15-Updates.
    Enabled repository SLE15-Installer-Updates.
  Basesystem Module 15 x86_64:
    Enabled repository SLE-Module-Basesystem15-Pool.
    Enabled repository SLE-Module-Basesystem15-Updates.
  Server Applications Module 15 x86_64:
    Enabled repository SLE-Module-Server-Applications15-Pool.
    Enabled repository SLE-Module-Server-Applications15-Updates.
Found product by target SLES/12: SUSE Linux Enterprise Server 12 x86_64.
Enabling SUSE Linux Enterprise Server 12 x86_64:
  SUSE Linux Enterprise Server 12 x86_64:
    Enabled repository SLES12-Pool.
    Enabled repository SLES12-Updates.

4.4.2 Using repositories

To enable or disable mirroring of specific repositories, use the rmt-cli repos enable ID and rmt-cli repos disable ID commands. To retrieve an ID for an enabled repository, use the rmt-cli repos listcommand. If you need to get the ID of a disabled but accessible repository, execute the command rmt-cli repos list --all.

Example:

> sudo rmt-cli repos list --all
+--------+-------------------------+-------------------------------------------+
| ID     | Name                    | Description                               |
+--------+-------------------------+-------------------------------------------+
[...]
| 3061   | SUSE-PackageHub-15-Pool | SUSE-PackageHub-15-Pool for sle-15-x86_64 |
[...]
+--------+-------------------------+-------------------------------------------+

> sudo rmt-cli repos enable 3061
Repository by ID 3061 successfully enabled.

> sudo rmt-cli repos disable 3061
Repository by ID 3061 successfully disabled.

To clean up downloaded files, please run 'rmt-cli repos clean'
Tip
Tip: Enabling and disabling multiple repositories at once

To enable or disable multiple repositories at once, specify a space-delimited list of their IDs, for example:

> sudo rmt-cli repos enable 2526 3263
Repository by ID 2526 successfully enabled.
Repository by ID 3263 successfully enabled.

> sudo rmt-cli repos disable 2526 3263
Repository by ID 2526 successfully disabled.
Repository by ID 3263 successfully disabled.

To clean up downloaded files, run 'rmt-cli repos clean'

4.5 Deleting mirrored data

After you disable the mirroring of a repository or product as described in Section 4.4, “Enabling and disabling mirroring of repositories”, the mirrored data remains on your local hard disk. This includes the mirrored RPM packages.

To delete disabled repository data, use the command rmt-cli repos clean. With this command, RMT verifies that only enabled repositories are mirrored and provides a way to delete invalid data.

Before removing any data, the command lists the affected repositories and requires the user to input yes to continue.

> sudo rmt-cli repos clean
RMT found locally mirrored files from the following repositories which are not marked to be mirrored:

SLE-Product-SLES15-Updates for sle-15-x86_64
SLE-Product-SLES15-Pool for sle-15-x86_64
SLE15-Installer-Updates for sle-15-x86_64

Would you like to continue and remove the locally mirrored files of these repositories?
Only 'yes' will be accepted.

Enter a value:  yes

Deleted locally mirrored files from repository 'SLE-Product-SLES15-Updates for sle-15-x86_64'.
Deleted locally mirrored files from repository 'SLE-Product-SLES15-Pool for sle-15-x86_64'.
Deleted locally mirrored files from repository 'SLE15-Installer-Updates for sle-15-x86_64'.

Clean finished. An estimated 157 MB were removed.
Tip
Tip: Manually remove repository data

To delete disabled repository data, manually remove its corresponding directory:

> sudo rm -r /usr/share/rmt/public/repo/SUSE/Products/PRODUCT/VERSION/ARCHITECTURE/

4.6 Adding custom repositories

You can mirror custom repositories with the RMT server. These repositories are not provided by SUSE Customer Center. Repositories can be provided by, for example, the Open Build Service, third-party vendors, or created with createrepo.

Custom repositories can either be stand-alone, or you can attach them to products. This allows you to connect multiple repositories with one command on a client registered to the RMT server.

The following example procedure illustrates the mirroring of a third-party repository.

  1. Add the remote repository to the RMT server. Replace URL with the URL to the repository. Replace NAME with a name of your choice for the repository.

    # rmt-cli repos custom add URL NAME
  2. List all custom repositories to get the ID of the new repository.

    # rmt-cli repos custom list
  3. Optionally attach the new custom repository to a product. For example, if the new custom repository is required by all desktop clients, it can be attached to the SUSE Linux Enterprise Desktop product.

    # rmt-cli repos custom attach REPOSITORY_ID PRODUCT_ID

    Replace REPOSITORY_ID with the ID of the new custom repository. Replace PRODUCT_ID with the ID of a product you want the repository to be attached to. If you need to retrieve the PRODUCT_ID, use the command rmt-cli products list --all.

    Important
    Important

    When custom repositories are associated with a product, clients registering with that product see it as disabled. To enable the repository, find its ID with the command zypper lr and run:

    # zypper mr -e REPO_ID
  4. Enable mirroring of the new custom repository.

    # rmt-cli repos custom enable REPOSITORY_ID

To get a list of all available custom repositories commands, see Section 6.1.4, “repos.

4.7 Exporting and importing repositories

RMT has built-in functions to import and export data about available repositories and the mirrored packages. For example, this can be used to speed up the setup of a new RMT server by locally copying already mirrored RPM packages.

Another use case is the offline mode. It allows the transfer of data to a disconnected RMT server, for example, to provide updates to computers in an air-gapped network.

The following procedure describes the transfer of data and mirrored RPMs between two RMT servers with a USB drive. The server sun is connected to SUSE Customer Center, while sirius is a server in an air-gapped network.

  1. Log in on the server sun.

    root@sun # rmt-cli sync
    root@sun # rmt-cli mirror
  2. Connect a USB drive, assumed to be /dev/sdb and mount it, for example, in /mnt/external.

    root@sun # mount /dev/sdb1 /mnt/external
    1. Export the data about available repositories and products.

      root@sun # rmt-cli export data /mnt/external/
    2. Export the list of enabled repositories. The exported file is required for exporting the repositories in the next step.

      root@sun # rmt-cli export settings /mnt/external/
    3. Export mirrored RPM packages. Depending on the size of mirrored repositories, this can take a long time.

      root@sun # rmt-cli export repos /mnt/external/
  3. Unmount and unplug the disk from sun and go to sirius.

    root@sun # umount /mnt/external
  4. If not yet done, set up RMT on sirius by running the yast2 rmt. In case of an offline RMT setup, select Skip on the Organization Credentials screen.

  5. Connect the USB drive to sirius and mount it in /mnt/external.

    root@sirius # mount /dev/sdb1 /mnt/external
    1. Import the metadata about available repositories and products.

      root@sirius # rmt-cli import data /mnt/external/
    2. Import mirrored RPM packages. Depending on the size of mirrored repositories, this can take a long time.

      root@sirius # rmt-cli import repos /mnt/external/
  6. Enable repositories as required on the sirius. For details, see Section 4.4, “Enabling and disabling mirroring of repositories”.

Note
Note: Exporting enabled settings from air-gapped server

If your air-gapped server (sirius) has many enabled repositories, or if the enabled repositories change frequently, we recommend exporting the repository settings from this server.

The server connected to SUSE Customer Center (sun) can then import the exported settings. This ensures that sun downloads all data required by sirius.

5 Configuring clients to use RMT

Any machine running SUSE Linux Enterprise 12 or newer can be configured to register against RMT and download software updates from there, instead of communicating directly with the SUSE Customer Center.

Tip
Tip: Register with RMT server over HTTP

We recommend registering with the RMT server over a secured HTTPS protocol (all examples in this documentation use it). However, you can also register with the RMT server over an insecure HTTP protocol. Use this approach only if your setup benefits from it and only in a trusted environment where security is not crucial.

To configure clients to use the RMT server, use one of the following methods:

Tip
Tip: CA certificate

If you need the CA certificate of the RMT server, find it at /etc/rmt/ssl/rmt-ca.crt and https://RMT_SERVER/rmt.crt.

5.1 Configuring clients with boot parameters

Any client can be configured to use RMT by providing the regurl parameter during machine boot.

The parameter needs to be entered as regurl=RMT_SERVER_URL. The URL needs to be in the following format: https://FQDN with FQDN being the fully qualified host name of the RMT server. It must be identical to the FQDN of the server certificate used on the RMT server. Example:

regurl=https://rmt.example.com
Warning
Warning: Beware of typing errors

Make sure the values you enter are correct. If regurl has not been specified correctly, the registration of the update source will fail.

Note
Note: Change of RMT server certificate

If the RMT server gets a new certificate from an untrusted CA, the clients need to retrieve the new CA certificate file. YaST displays a dialog for importing a new certificate. If you confirm importing the new certificate, the old one is replaced with the new one.

5.2 Configuring clients with AutoYaST profile

Clients can be configured to register with RMT server via AutoYaST profile. For general information about creating AutoYaST profiles and preparing automatic installation, refer to the AutoYaST Guide. In this section, only RMT specific configuration is described.

To configure RMT specific data using AutoYaST, follow the steps for the relevant version of RMT client.

  1. As root, start YaST and select Miscellaneous › Autoinstallation to start the graphical AutoYaST front-end.

    From a command line, you can start the graphical AutoYaST front-end with the yast2 autoyast command.

  2. Open an existing profile using File › Open, create a profile based on the current system's configuration using Tools › Create Reference Profile, or work with an empty profile.

  3. Select Software › Product Registration. An overview of the current configuration is shown.

  4. Click Edit.

  5. Check Register the Product, set the URL of the RMT server in Use Specific Server URL Instead of the Default, and you can set the Optional SSL Server Certificate URL. The possible values for the server URL are the same as for the kernel parameter regurl. For the SSL certificate location, you can use either HTTP or HTTPS based URLs.

  6. Perform all other configuration needed for the systems to be deployed, then click Finish to return to the main screen.

  7. Select File › Save As and enter a file name for the profile, such as autoinst.xml.

5.3 Configuring clients with rmt-client-setup

The /usr/share/rmt/public/tools/rmt-client-setup script is provided in the package rmt-server. This script allows you to configure a client machine to use an RMT server. It can also be used to reconfigure an existing client to use a different RMT server.

To configure a client machine to use RMT with rmt-client-setup, follow these steps:

  1. Download rmt-client-setup from the RMT server:

    # curl http://RMT_SERVER/tools/rmt-client-setup --output rmt-client-setup
  2. Run the script with the URL of the RMT server as parameter.

    # sh rmt-client-setup https://RMT_SERVER/

    Executing this script will import the RMT CA's certificate into the trusted store.

    Alternatively, you can specify the correct fingerprint or path to the server certificate. For details, see sh rmt-client-setup --help.

  3. The script downloads the server's CA certificate. Accept it by pressing Y. The tool now performs all necessary modifications on the client.

  4. Use SUSEConnect to add more products. For details, run SUSEConnect --help .

5.4 Configuring clients with YaST

To configure a client to perform the registration against an RMT server use the YaST Product Registration module yast2 registration.

On the client, the credentials are not necessary and you may leave the relevant fields empty. Click Local Registration Server and enter its URL. Then click Next until the exit from the module.

5.5 Configuring clients for custom stand-alone repositories

If you created a custom stand-alone repository on the RMT server, it will not be registered on client machines with SUSEConnect because it has no parent product.

To add the repository manually, follow these steps:

  1. Point your Web browser to the following RMT server URL:

    https://RMT_SERVER_HOSTNAME/repo/
  2. Navigate the browser through the directory structure to your custom repository's repodata/ subdirectory.

  3. On the client machine, add the discovered repository URL:

    > sudo zypper ar CUSTOM_REPO_URL CUSTOM_REPO_NAME

5.6 Listing accessible repositories

To list available modules and repositories, use SUSEConnect --list-extensions. Alternatively, you can also browse the directory listing of the RMT server by visiting https://RMT_SERVER/repo/ and its subdirectories.

5.7 Online migration of SUSE Linux Enterprise clients

SUSE Linux Enterprise clients registered against RMT can be migrated online to the latest service pack of the same major release the same way as clients registered against SUSE Customer Center. Before starting the migration, make sure that RMT has the required products available and mirrored.

For detailed information on the online migration, see Book “Upgrade Guide”, Chapter 1 “Upgrade paths and methods”.

6 RMT tools and configuration files

This chapter describes the most important scripts, configuration files and certificates shipped with RMT.

The rmt-cli command and its sub-commands are used to manage the mirroring of repositories, registration of clients, and reporting. systemd is used for starting, stopping, restarting the RMT service and for checking its status.

The basic configuration for RMT is stored in the /etc/rmt.conf.

6.1 RMT command line interface (rmt-cli)

6.1.1 Overview

The key command to manage the RMT is rmt-cli (/usr/bin/rmt-cli). The rmt-cli command should be used together with the sub-commands described in this section. If the rmt-cli command is used alone, it prints a list of all available sub-commands. To get help for individual sub-commands, use man rmt-cli or rmt-cli help [subcommand].

The following sub-commands are available:

rmt-cli sync

Synchronize database with SUSE Customer Center.

rmt-cli products

List and modify products.

rmt-cli repos

List and modify repositories.

rmt-cli mirror

Mirror repositories.

rmt-cli systems

List and modify systems.

rmt-cli import

Import commands for offline mode.

rmt-cli export

Export commands for offline mode.

rmt-cli version

Show RMT version.

The following sections explain each sub-command in detail.

6.1.2 sync

This command triggers synchronization with the SUSE Customer Center instantly. The command has no further options. Synchronization is also triggered each night by the systemd timer rmt-server-sync.timer.

During synchronization, no data is uploaded to the SUSE Customer Center. This command for example updates local product definitions and repository data.

6.1.3 products

List and modify products.

rmt-cli products list [--all] [--csv]

Lists the products that are enabled for mirroring. Use the --all flag to list all available products. Use the --csv flag to output the list in CSV format. ls can be used as a shortcut for list.

rmt-cli products enable [id | string] [--all-modules]

Enables mandatory repositories of a product by its ID or product string. The --all-modules flag enables all modules of a product instead of only the recommended ones.

rmt-cli products disable [id | string]

Disables all repositories of a product by its ID or product string.

6.1.4 repos

rmt-cli repos list [--all] [--csv]

Lists the repositories that are enabled for mirroring. Use the --all flag to list all available repositories. Use the --csv flag to output the list in CSV format. ls can be used as a shortcut for list.

rmt-cli repos enable [id]

Enables mirroring of a single repository by its ID.

rmt-cli repos disable [id]

Disables mirroring of a single repository by its ID.

rmt-cli repos clean

Removes locally mirrored files of repositories that are not marked to be mirrored.

6.1.5 repos custom

rmt-cli repos custom list [--csv]

Lists all your custom repositories. Use the --csv flag to output the list in CSV format. ls can be used as a shortcut for list.

rmt-cli repos custom add [url] [name] [--id]

Adds a new custom repository. Use the --id flag to specify a custom alphanumeric ID.

rmt-cli repos custom enable [id]

Enables mirroring of a custom repository.

rmt-cli repos custom disable [id]

Disables mirroring of a custom repository.

rmt-cli repos custom remove [id]

Removes a custom repository.

rmt-cli repos custom products [id]

Lists the products attached to the custom repository with the given ID.

rmt-cli repos custom attach [id] [product id]

Attaches an existing custom repository to a product.

rmt-cli repos custom detach [id] [product id]

Detaches an existing custom repository from a product.

6.1.6 mirror

rmt-cli mirror

Starts the mirroring process manually.

rmt-cli mirror all

Mirrors all enabled repositories.

rmt-cli mirror repository [IDs]

Mirrors enabled repositories by a list of IDs.

rmt-cli mirror product [IDs]

Mirrors enabled repositories for a product by a list of IDs.

6.1.7 systems

rmt-cli systems list

This command lists registered systems.

rmt-cli systems scc-sync

This command forwards registered systems' data to SCC.

rmt-cli systems remove [TARGET]

This command removes a system from RMT as identified by the Login column of the output of the rmt-cli systems list command.

rmt-cli systems purge

This command lists and optionally deletes inactive systems. It has the following options:

  • --before DATE—lists systems that have been inactive since DATE until now. Default is the last 3 months.

  • --no-confirmation—allows the administrator to delete matching systems without confirmation.

# rmt-cli systems purge --before 2021-06-16
+------------+----------+---------------------+---------------------+----------+
| Login      | Hostname | Registration time   | Last seen           | Products |
+------------+----------+---------------------+---------------------+----------+
| SCC_c5b0.. | 6e485e48b| 2021-06-11 13:38:07 | 2021-06-11 13:52:01 | SLES/15..|
| SCC_5fcf.. | node52   | 2021-06-15 13:29:24 | 2021-06-15 13:31:25 | SLES/15..|
+------------+----------+---------------------+---------------------+----------+
Do you want to delete these systems? (y/n) y
Purged systems that have not contacted this RMT since 2021-06-16.

6.1.8 import

This command is required for the offline mode. For details, see Section 4.7, “Exporting and importing repositories”.

rmt-cli import data [path]

Run this on the offline RMT to read the JSON files from the given path and fill the local database with data.

rmt-cli import repos [path]

Run this on the offline RMT to import RPM packages.

6.1.9 export

This command is required for the offline mode. For details, see Section 4.7, “Exporting and importing repositories”.

rmt-cli export data [path]

Run this on an online RMT to get the latest data from SUSE Customer Center and save the result as JSON files at the specified path.

rmt-cli export settings [path]

Run this on the offline RMT to save the settings for enabled repositories at a given path as repos.json.

rmt-cli export repos [path]

Run this regularly on the online RMT to mirror the set of repositories specified in the repos.json at the given path. The mirrored repository files are stored in subdirectories of the same path.

6.1.10 clean packages

The rmt-cli clean packages command removes locally mirrored dangling files and their database entries. A file is considered to be dangling if it matches all the following characteristics:

  • It exists in a repository directory with primary and metadata repomd.xml files.

  • It is no longer referenced in the metadata files.

  • It is at least 2 days old.

You can pass the following options to the rmt-cli clean packages command:

--dry-run

Generates a report of all affected files without actually cleaning them or their database entries.

--verbose

Prints detailed information about each cleaned file.

--non-interactive

Skips confirmation before proceeding with the cleaning process.

6.1.11 version

Display the version of rmt-cli.

6.2 RMT systemd commands

You can manage RMT-related services with the standard systemd commands. The RMT server has the following services and timers:

rmt-server.target

A systemd target that starts all required RMT components.

rmt-server.service

The RMT server.

rmt-server-migration.service

This service migrates the database to the newest schema, if required. There is no need to manually interact with this service.

rmt-server-sync.timer

This timer is responsible for periodically synchronizing all repository product data from the SUSE Customer Center.

rmt-server-mirror.timer

This timer is responsible for periodically synchronizing all RPMs from the SUSE Customer Center.

Use systemctl to manage the RMT services and timers.

6.3 RMT configuration files

The main RMT configuration file is /etc/rmt.conf. You can set most of the options with the YaST RMT Server module.

6.3.1 /etc/rmt.conf

The only supported way of doing the initial configuration is with yast2 rmt as described in Section 2.5, “RMT configuration with YaST”. Only the proxy configuration needs to be entered manually. The other configuration parameters are documented for reference.

All available configuration options can be found in the /etc/rmt.conf file.

6.3.1.1 Mirroring settings

The mirroring section lets you adjust mirroring behavior.

mirror_src

Decides whether to mirror source RPM packages (architecture is src).

dedup_method

Creates hard links during mirroring when set to hardlink. If the file system does not support hard links, it can be set to copy instead. Possible values: hardlink, copy.

6.3.1.2 HTTP client settings

The http_client section defines the global HTTP connection settings of RMT.

verbose

Enables additional debug output to the systemd journal.

proxy

The proxy server URL including the protocol and the port number. For example: http://proxy_url:8080.

noproxy

A list of domains that should not go through the proxy, separated by commas. For example: localhost,.mylocaldomain.

proxy_auth

This setting determines the proxy authentication mechanism. Possible values are: none, basic, digest, gssnegotiate, ntlm, digest_ie, ntlm_wb.

proxy_user

The proxy server user name.

proxy_password

The proxy server password.

low_speed_limit

Lower speed limit when a download should be aborted in bytes/sec.

low_speed_time

Time until a download gets aborted, when download speed is below low_speed_limit.

6.3.1.3 Settings for accessing SUSE repositories

The scc section contains your mirroring credentials for contacting the SUSE Customer Center. To obtain your mirroring credentials, see Section 4.1, “Mirroring credentials”.

Valid configuration keys for the section are:

username

Mirroring credentials user name.

password

Mirroring credentials password.

6.3.1.4 Web server settings

The web_server section lets you tune the performance of your RMT server.

min_threads

Specifies the minimum number of threads that an RMT server worker should spawn.

Acceptable values: Integer greater than or equal to 1.

max_threads

Specifies the maximum number of threads that an RMT server worker should spawn.

Acceptable values: Integer greater than or equal to 1.

workers

Specifies the number of Web workers for RMT.

Acceptable values: Integer greater than or equal to 1.

6.3.2 SSL certificates and HTTPS

By default access to API endpoints consumed by SUSEConnect is limited to HTTPS only. nginx is configured to use an SSL certificate and a private key from the following locations:

  • Certificate: /etc/rmt/ssl/rmt-server.crt

  • Private key: /etc/rmt/ssl/rmt-server.key

The YaST RMT module generates a custom certificate authority which is used to sign HTTPS certificates. This means that to register, this certificate authority must be trusted by the client machines:

  • For registrations during installation from the media or with YaST Registration module, a message will appear, prompting to trust the server certificate.

  • For registering a client system on the command line, use the rmt-client-setup script. For details, see Section 5.3, “Configuring clients with rmt-client-setup.

7 Backing up an RMT server

This chapter explains how to create a backup of your RMT server and how to restore from it.

7.1 Creating a backup

This procedure details how to create a full backup of your RMT server. It is assumed that you have an external disk or network share mounted in /mnt/backup which serves as a target for the backup.

  1. Change to the backup directory.

    # cd /mnt/backup
  2. Create a file containing a dump of your SQL database. You need to provide the password you set for the rmt database user during the installation.

    # mysqldump -u rmt -p rmt > rmt_backup.sql
  3. Optionally, create a copy of your mirrored data.

    # mkdir repos
    # rmt-cli export repos ./repos/

7.2 Restoring a backup

This procedure details how to restore your RMT server from a backup created in Section 7.1, “Creating a backup”. It is assumed that the backup is mounted in /mnt/backup. It is also assumed that you are restoring the server on a newly installed SLES.

  1. Install and configure the RMT server as described in Chapter 2, RMT installation and configuration.

  2. Go to the backup directory.

    # cd /mnt/backup/
  3. Use mysql to remove the newly created database and import the data.

    # mysql -u rmt -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    [...]
    
    MariaDB [(none)]> DROP DATABASE rmt;
    Query OK, 14 rows affected (0.84 sec)
    
    MariaDB [(none)]> CREATE DATABASE rmt;
    Query OK, 1 row affected (0.00 sec)
    
    MariaDB [(none)]> use rmt;
    Database changed
    
    MariaDB [rmt]> source rmt_backup.sql;
    [...]
    
    MariaDB [rmt]> quit
  4. Optionally, import the exported repositories.

    # rmt-cli import repos ./repos/
  5. Synchronize your data and update your repositories.

    # rmt-cli sync
    # rmt-cli mirror

8 Managing TLS/SSL certificates

8.1 Regenerating HTTPS certificates

HTTPS certificates should be regenerated before they expire or to include additional common alternative names. No additional actions are required on the client machines registered to the RMT server if only HTTPS certificates are regenerated.

  1. Stop nginx and rmt-server services:

    # systemctl stop nginx
    # systemctl stop rmt-server
  2. Remove previously generated certificates.

    # rm /etc/rmt/ssl/rmt-server.*
  3. Run the yast rmt module as described in Section 2.5, “RMT configuration with YaST”.

8.2 Regenerating CA certificates and HTTPS certificates

CA certificates can be regenerated after they have expired or in case of security issues.

Warning
Warning: Import CA certificate on all clients

The newly generated CA certificate must be imported on all clients registered to the RMT server. This can be done by running the rmt-client-setup script on the client machines as described in Section 5.3, “Configuring clients with rmt-client-setup.

  1. Stop nginx and rmt-server services.

    # systemctl stop nginx
    # systemctl stop rmt-server
  2. Remove previously generated CA and HTTPS certificates.

    # rm /etc/rmt/ssl/rmt-ca.*
    # rm /etc/rmt/ssl/rmt-server.*
  3. Run the yast rmt module as described in Section 2.5, “RMT configuration with YaST”.

9 Deploying a SUSE Linux Enterprise Server instance to support RMT in the public cloud

You can deploy a SUSE Linux Enterprise Server instance to support RMT in Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. RMT is included in SLES starting with version 15.

The following example shows a generic cloud architecture for the RMT deployment. Your deployment may look different based on your networking requirements.

An example of cloud architecture for RMT deployment
Figure 9.1: An example of cloud architecture for RMT deployment

9.1 Using a bring-your-own-subscription image

SUSE provides images for SLES in Amazon Web Services, Google Cloud and Microsoft Azure. There are two types of images available: PAYG (Pay-As-You-Go) and BYOS (Bring-Your-Own-Subscription). These images are updated at regular intervals and it is suggested that you deploy new instances from the latest version of the image to ensure the most recent security updates are in place. To support RMT deployment, we recommend deploying an RMT instance from a BYOS image.

9.1.1 Finding images in the cloud marketplace

The location of the relevant image in each of the cloud provider is shown below:

Google Cloud
Figure 9.2: Google Cloud
Amazon Web Services
Figure 9.3: Amazon Web Services
Microsoft Azure
Figure 9.4: Microsoft Azure

It is recommended to start with an instance type that has at least two vCPUs and a minimum of 8 GB RAM to support the RMT deployment. For example, on Amazon EC2, this could be a t3.large instance type, and in Microsoft Azure, it could be a B2as_v2 The instance can be rightsized as needed and depends on the number of clients being managed and updated by the RMT server.

9.1.2 Registering the SLES instance

After the SLES instance deployment, you must register the instance with the SUSE Customer Center.

Note
Note: SUSE account

Registering with the SUSE Customer Center requires a SUSE account. If you do not have a SUSE account yet, go to the SUSE Customer Center home page (https://scc.suse.com/) to create one.

To connect your instance:

AWS:

>  ssh -i SSH_KEY EC2_USER_ID@SERVER_IP

Google Cloud:

>  gcloud compute ssh GCE_INSTANCE_IP

Azure:

>  ssh AZURE_USER_ID@SERVER_IP

To register the SLES instance with SCC:

> sudo  SUSEConnect -e EMAIL_ADDRESS -r REGISTRATION_CODE 

The registration code is available once you log in to SCC.

9.2 Considerations when using RMT

You must consider the following requirements when you use RMT:

Disk space

The RMT server requires sufficient disk space to mirror the repositories. Downloaded packages are available in /var/lib/rmt/public/repo/. Disk space is dependent on the number of repositories you mirror. We recommend a minimum of 1.5 times the total size of all enabled repositories. It is a best practice to provision an additional disk volume to support this requirement. You can either mount the volume to /var/lib/rmt/public/repo/ on instance creation or immediately after the launch. For Azure, this is an additional disk volume. For AWS, it is an Amazon EBS volume and for GCP, it is a persistent disk volume .

IP or DNS resolution

A static IP address or a DNS name is required in order for clients to connect to the RMT server. In Azure, AWS and GCP, a DNS provided by the Cloud Service Provider (CSP) is assigned when the instance is launched. This IP or DNS may change if the instance is re-created. For Azure, consider using a static IP address to provide a consistent connection point for your clients. In AWS, this would be an elastic IP or Route53. In GCP, this would be a cloud DNS record that uses a static IP address.

Connectivity for the RMT server

The RMT server can connect to SCC on ports 80 and 443. There are many ways to provide connectivity. For example, in AWS, connectivity to SCC can be provided via an AWS Internet Gateway, an AWS NAT Gateway, or via a local data center (VPN/DX Connection) but this is depends on whether the RMT instance is in a public or private subnet. GCP provides direct access to the Internet via the VPC routes or Cloud NAT services. Azure offers similar services.

Connectivity for clients

Clients can connect to RMT on ports 80 and 443. When launching the SLES instance to support RMT, check if network connectivity allows inbound access to the RMT server from your clients (HTTP/HTTPS). For AWS, when a SLES instance is launched to support RMT, it is possible to use an existing AWS security group or a new one. The security group must be configured to allow inbound access to the RMT server from your clients. For GCP, the firewall rules must be configured to allow inbound access to the RMT server from your clients.

9.3 More information