Jump to content
SUSE Linux Enterprise Server 15

Repository Mirroring Tool for SLES 15

Author: Sven Seeberg-Elverfeldt
Publication Date: February 27, 2019
List of Figures
1 RMT
1.1 RMT Pattern

Copyright © 2006– 2019 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 http://www.suse.com/company/legal/. All other 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.

About This Guide

1 Overview

The Repository Mirroring Tool (RMT) for SUSE Linux Enterprise 15 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: 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 2.1, “Feature Comparison”.

2 Additional Documentation and Resources

Chapters in this manual contain links to additional documentation resources that are available either on the system or on the Internet.

For an overview of the documentation available for your product and the latest documentation updates, refer to http://www.suse.com/documentation.

3 Feedback

Several feedback channels are available:

Bugs and Enhancement Requests

For services and support options available for your product, refer to http://www.suse.com/support/.

Help for openSUSE is provided by the community. Refer to https://en.opensuse.org/Portal:Support for more information.

To report bugs for a product component, go to https://scc.suse.com/support/requests, log in, and click Create New.

User Comments

We want to hear your comments about and suggestions for this manual and the other documentation included with this product. Use the User Comments feature at the bottom of each page in the online documentation or go to http://www.suse.com/documentation/feedback.html and enter your comments there.

Mail

For feedback on the documentation of this product, you can also send a mail to doc-team@suse.com. Make sure to include the document title, the product version and the publication date of the documentation. To report errors or suggest enhancements, provide a concise description of the problem and refer to the respective section number and page (or URL).

4 Documentation Conventions

The following notices and typographical conventions are used in this documentation:

  • /etc/passwd: directory names and file names

  • PLACEHOLDER: replace PLACEHOLDER with the actual value

  • PATH: the environment variable PATH

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

  • user: users or groups

  • package name : name of a 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

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

    System 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.

  • Dancing Penguins (Chapter Penguins, ↑Another Manual): This is a reference to a chapter in another manual.

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

    root # command
    tux > sudo command
  • Commands that can be run by non-privileged users.

    tux > command
  • 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.

1 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.

1.1 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 1.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.

1.2 Installation on Existing System

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

tux > sudo zypper in rmt-server

1.3 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.

    tux > sudo yast2 rmt

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

  2. Enter your organization credentials. To retrieve your credentials, refer to Section 3.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.

  5. To view a final summary, select Next. Then select Finish to close YaST. YaST then enables and starts all systemd services and timers.

  6. If you have a firewall enabled, allow access to ports 80 and 443. When using the default zone public, execute the following commands:

    tux > sudo firewall-cmd --zone=public --add-port=80/tcp --permanent
    tux > sudo firewall-cmd --zone=public --add-port=443/tcp --permanent
    tux > sudo firewall-cmd --reload

2 Migrate from SMT to RMT

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

2.1 Important Notes

Warning
Warning: Read This Section Carefully

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

Use 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 SUSE Linux Enterprise Server 12 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's 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 2.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

Migration from SLE 12 to 15

yes

yes

Staging repositories

yes

no1

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

RedHat support (Extended Support)

yes

no2

Files deduplication

yes

yes

Data transfer from SMT to RMT

-

yes

Transfer registration data to SUSE Customer Center

yes

no

Reporting

yes

no

Custom TLS certificates for web-server

yes

yes

Web-server

Apache2

Nginx

Platform

Perl

Ruby

1) Functionality is offered by SUSE Manager.

2) RES support is planned for SLES 15 SP1.

2.2 Exporting SMT Data

Procedure 2.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-export.XXXXXX.tar.gz. Copy the file to a location which can be accessed by the new RMT server.

2.3 Importing SMT Data to RMT

Procedure 2.2: 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, then unpack it:

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

    tux > sudo cp ssl/cacert.key /etc/rmt/ssl/rmt-ca.key
    tux > sudo cp ssl/cacert.pem /etc/rmt/ssl/rmt-ca.crt
  4. Run the YaST RMT configuration module as described in Section 1.3, “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.

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

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

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

    tux > sudo cp -r /var/www/htdocs/repo/* /var/lib/rmt/public/repo
    tux > sudo chown -R _rmt:nginx /var/lib/rmt/public/repo
  9. In case your SMT server contains custom repositories, which you would also like to mirror to the RMT server, you need to activate them before mirroring, since they are disabled by default.

    1. Check for custom repositories by running:

      tux > 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 would like to mirror by running:

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

    tux > sudo rmt-cli mirror

3 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 bandwidth.

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

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 will be 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 below.

3.1 Mirroring Credentials

Before you create a local mirror of SUSE Linux Enterprise the repositories, you need appropriate organization credentials. 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 http://scc.suse.com and log in.

  2. If you are member of multiple organizations, chose 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, select the eye symbol.

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 5.3.1, “/etc/rmt.conf”.

3.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 done with the systemd timer rmt-server-sync.timer. To view the status, for example the next running time, use systemctl status:

root # 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.

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

3.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 done by the systemd timer rmt-server-mirror.timer. To show the status, for example the next running time, use systemctl status:

root # 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.

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

3.4 Enabling and Disabling Mirroring of Repositories

Mirroring of repositories can be enabled or disabled individually or by stating a product. When repositories are enabled, it's 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. In general, enabling or disabling a product is desired, because this automatically enables or disables all repositories associated with the product.

3.4.1 Using Products

To enable or disable all repositories of a product, use the rmt-cli product enable ID and rmt-cli product disable ID commands. To retrieve an ID for a disabled but available product, use the rmt-cli product list --all command. To retrieve an ID for an enabled product, use the rmt-cli product list command.

Example:

tux > sudo rmt-cli products list --all
+------+------------------+---------+--------------+----------------------+---------------+---------+---------------+
| ID   | Name             | Version | Architecture | Product string       | Release stage | Mirror? | Last mirrored |
+------+------------------+---------+--------------+----------------------+---------------+---------+---------------+
[...]
| 1743 | SUSE Package Hub | 15      | x86_64       | PackageHub/15/x86_64 | released      | false   |               |
[...]
+------+------------------+---------+--------------+----------------------+---------------+---------+---------------+

tux > sudo rmt-cli product enable 1743
2 repo(s) successfully enabled.

tux > sudo rmt-cli product disable 1743
2 repo(s) successfully disabled.

3.4.2 Using Repositories

To enable or disable mirroring of specific repositories, use the rmt-cli repo enable ID and rmt-cli repo disable ID commands. To retrieve an ID for a disabled but available repository, use the rmt-cli repo list --all command. To retrieve an ID for an enabled repository, use the rmt-cli repo list command.

Example:

tux > sudo rmt-cli repo list --all
+--------+-------------------------+-------------------------------------------+------------+---------+---------------+
| SCC ID | Name                    | Description                               | Mandatory? | Mirror? | Last mirrored |
+--------+-------------------------+-------------------------------------------+------------+---------+---------------+
[...]
| 3061   | SUSE-PackageHub-15-Pool | SUSE-PackageHub-15-Pool for sle-15-x86_64 | true       | false   |               |
[...]
+--------+-------------------------+-------------------------------------------+------------+---------+---------------+

tux > sudo rmt-cli repo enable 3061
Repository successfully enabled.

tux > sudo rmt-cli repo disable 3061
Repository successfully disabled.

3.5 Deleting Mirrored Data

After you disable mirroring of a repository or product as described in Section 3.4, “Enabling and Disabling Mirroring of Repositories”, the mirrored data still remains on your local hard disk. This includes the mirrored RPM packages. To remove the data, manually remove the corresponding directory:

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

3.6 Adding Custom Repositories

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

Custom repositories can be attached 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.

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

    root # 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.

    root # 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 attached to. If you need to retrieve the PRODUCT_ID, use the command rmt-cli products list --all.

  4. Enable mirroring of the new custom repository.

    root # rmt-cli repos custom enable REPOSITORY_ID

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

3.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 transferring 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 the 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. Connect the USB drive to sirius and mount it in /mnt/external.

    root@sirius # mount /dev/sdb1 /mnt/external
    1. Import the meta data 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/
  5. Enable repositories as required on the sirius. For details, see Section 3.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 to export the repository settings from this server.

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

4 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.

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.

4.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.

4.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.

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

    root # 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.

    root # 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 .

4.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.

4.5 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.

4.6 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”.

5 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.

5.1 RMT Command Line Interface

5.1.1 rmt-cli 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 import

Import commands for the offline mode.

rmt-cli export

Export commands for the offline mode.

rmt-cli version

Show RMT version.

The following sections explain each sub-command in detail.

5.1.2 sync

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

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

5.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]

Enables mandatory repositories of a product by its id or product string.

rmt-cli products disable [id | string]

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

5.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.

5.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]

Adds a new custom repository, for example: rmt-cli repos custom add https://download.opensuse.org/repositories/Virtualization:/containers/SLE_12_SP3/ Virtualization:Containers

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

5.1.6 mirror

rmt-cli mirror

This command starts the mirroring process manually.

5.1.7 import

This command is required for the offline mode. For details, see Section 3.7, “Exporting and Importing Repositories”.

rmt-cli import data [path]

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

rmt-cli import repos [path]

Run this on the offline RMT to import RPM packages.

5.1.8 export

This command is required for the offline mode. For details, see Section 3.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 it 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 given path as repos.json.

rmt-cli export repos [path]

Run this on the offline RMT to export RPM packages.

5.1.9 version

Display the version of rmt-cli.

5.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 server 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 control the RMT services and timers.

5.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.

5.3.1 /etc/rmt.conf

The only supported way of doing the initial configuration is with yast2 rmt as described in Section 1.3, “RMT Configuration with YaST”. Only the proxy configuration has 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.

5.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 hardlinks during mirroring when set to hardlink. If the file system does not support hardlinks, can be set to copy instead. Possible values: hardlink, copy.

5.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.

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.

5.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 3.1, “Mirroring Credentials”.

Valid configuration keys for the section are:

username

Mirroring credentials user name.

password

Mirroring credentials password.

5.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 SSL certificate and private key from the following locations:

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

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

YaST RMT module generates a custom certificate authority which is used to sign HTTPS certificates, which 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 4.3, “Configuring Clients with rmt-client-setup.

6 Backing Up an RMT Server

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

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

    root # 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.

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

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

6.2 Restoring a Backup

This procedure details how to restore your RMT server from a backup created in Section 6.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 1, RMT Installation and Configuration.

  2. Go to the backup directory.

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

    root # 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.

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

    root # rmt-cli sync
    root # rmt-cli mirror

7 Managing SSL/TLS Certificates

7.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 RMT server if only HTTPS certificates are regenerated.

  1. Stop nginx and rmt-server services:

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

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

7.2 Regenerating CA certificates and HTTPS certificates

CA certificates can be regenerated once 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 rmt-client-setup script on the client machines as described in Section 4.3, “Configuring Clients with rmt-client-setup.

  1. Stop nginx and rmt-server services.

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

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

A Documentation Updates

This chapter lists content changes and updates for this document.

A.1 SUSE Linux Enterprise Server 15 SP0

A.1.1 December 2018

Bugfixes

A.1.2 November 2018

Bugfixes
Print this page