Jump to content
SUSE Linux Enterprise Server 15 SP2

Repository Mirroring Tool Guide

Publication Date: October 23, 2020

Copyright © 2006– 2020 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 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 Edit source

1 Overview Edit source

The Repository Mirroring Tool (RMT) for SUSE Linux Enterprise 15 SP2 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.

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 Edit source

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 https://documentation.suse.com/.

3 Giving Feedback Edit source

Your feedback and contributions to this documentation are welcome! Several channels are available:

Service Requests and Support

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

To open a service request, you need a subscription 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, you can use the Report Documentation Bug links next to headlines in the HTML version of this document. These preselect the right product and category in Bugzilla and add a link to the current section. You can start typing your bug report right away. A Bugzilla account is required.


To contribute to this documentation, use the Edit Source links next to headlines in the HTML version of this document. They take you to the source code on GitHub, where you can open a pull request. A GitHub account is required.

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


Alternatively, you can report errors and send feedback concerning the documentation to <>. Make sure to include the document title, the product version and the publication date of the documentation. Refer to the relevant section number and title (or include the URL) and provide a concise description of the problem.

4 Documentation Conventions Edit source

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

  • AMD/Intel This paragraph is only relevant for the AMD64/Intel 64 architecture. 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.

  • 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 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 Notice

    Important information you should be aware of before proceeding.

    Note: Note Notice

    Additional information, for example about differences in software versions.

    Tip: Tip Notice

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

1 RMT Installation and Configuration Edit source

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

Warning: RMT Server 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.

1.1 Storage Requirements Edit source

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

1.2 Installation During System Installation Edit source

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.3 Installation on Existing System Edit source

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

tux > sudo zypper in rmt-server

1.4 RMT Configuration with YaST Edit source

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.

    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 doesn't 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 doesn't already exist. To regenerate this certificate, please reference Section 7.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 1.2: Enabling Ports in firewalld

    If firewalld is not enabled now and you plan to enable it later, you can always open relevant ports by running the yast2 rmt module.

    Tip: Fine-tuning firewalld Settings

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

    Continue with Next.

  6. To view the summary, click Next. Close YaST by clicking Finish. YaST then enables and starts all systemd services and timers.

1.5 Enabling SLP Announcements Edit source

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:

    tux > sudo firewall-cmd --permanent --add-port=427/tcp
    tux > sudo firewall-cmd --permanent --add-port=427/udp
    tux > sudo firewall-cmd --reload
  2. Verify that SLP server is installed and possibly install it:

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

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

2 Migrate from SMT to RMT Edit source

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

2.1 Important Notes Edit source

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 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 2.1: Feature Comparison




Available on SLES 11



Available on SLES 12



Available on SLES 15



Synchronize products with SUSE Customer Center



Mirror RPMs from repositories



Selective mirroring (specifying products to mirror)



Serve RPMs via HTTP



Registration of SLE 15 systems



Registration of SLE 12 systems



Registration of SLE 11 systems



Migration from SLE 12 to 15



Staging repositories



Offline mirroring



NTLM Proxy support



Custom repositories



YaST installation wizard



YaST management wizard



Client management



RedHat support (Extended Support)



Files deduplication



Data transfer from SMT to RMT



Transfer registration data to SUSE Customer Center






Custom TLS certificates for Web server



Web server






1) Functionality is offered by SUSE Manager.

2.2 Exporting SMT Data Edit source

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.TIMESTAMP.tar.gz. Copy the file to a location that can be accessed by the new RMT server.

2.3 Importing SMT Data to RMT Edit source

  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:

    tux > mkdir EMPTY_DIR
    tux > cd EMPTY_DIR
    tux > tar xf /PATH/TO/smt-export.TIMESTAMP.tar.gz
    tux > cd smt-export
  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.4, “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 /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.

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

    The path for storing custom repositories' 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


    its path on the RMT server will be

  9. Custom repositories on the SMT server are disabled be default. If you want to mirror them to the RMT enable them before mirroring.

    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 want 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 Edit source

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.

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

Note: Change 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 ln -sfn /usr/share/rmt/public/repo TARGET command (replace TARGET with the desired destination). Make sure that the target must have read and write permissions for the rmt user and nginx group. If you prefer to store mirrored repositories in a different directory, or on a different storage device,

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: SUSE Linux Enterprise Server 11 Clients

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

3.1 Mirroring Credentials Edit source

Before you create a local mirror of the SUSE Linux Enterprise 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 Edit source

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 Edit source

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 Edit source

Mirroring of repositories can be enabled or disabled individually or by stating a 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. 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 Edit source

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


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

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

tux > sudo rmt-cli products disable 1743
2 repo(s) successfully disabled.
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:

tux > sudo rmt-cli products enable 1743 SLES/15/x86_64 SLES/12

3.4.2 Using Repositories Edit source

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 a disabled but available repository, use the rmt-cli repos list --all command. To retrieve an ID for an enabled repository, use the rmt-cli repos list command.


tux > sudo rmt-cli repos list --all
| SCC ID | Name                    | Description                               |
| 3061   | SUSE-PackageHub-15-Pool | SUSE-PackageHub-15-Pool for sle-15-x86_64 |

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

tux > sudo rmt-cli repos disable 3061
Repository successfully disabled.
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:

tux > sudo rmt-cli repos disable 2526 3263

3.5 Deleting Mirrored Data Edit source

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 Edit source

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

    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 to be 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 Edit source

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 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: 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 server connected to the SUSE Customer Center (sun) can then import the exported settings. This ensures that sun downloads all data required by sirius.

4 Configuring Clients to Use RMT Edit source

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: 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: 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 Edit source

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:

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: 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 Edit source

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 Edit source

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 Edit source

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 Configuring Clients for Custom Stand-alone Repositories Edit source

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:

  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:

    tux > sudo zypper ar CUSTOM_REPO_URL CUSTOM_REPO_NAME

4.6 Listing Accessible Repositories Edit source

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.7 Online Migration of SUSE Linux Enterprise Clients Edit source

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 Edit source

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 Edit source

5.1.1 rmt-cli Overview Edit source

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 Edit source

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.

5.1.3 products Edit source

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.

5.1.4 repos Edit source

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 Edit source

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

5.1.6 mirror Edit source

rmt-cli mirror

This command starts the mirroring process manually.

5.1.7 import Edit source

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

5.1.8 export Edit source

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 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 will be stored in subdirectories of the same path.

5.1.9 version Edit source

Display the version of rmt-cli.

5.2 RMT systemd Commands Edit source

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


A systemd target that starts all required RMT components.


The RMT server.


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


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


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 Edit source

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 Edit source

The only supported way of doing the initial configuration is with yast2 rmt as described in Section 1.4, “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. Mirroring settings Edit source

The mirroring section lets you adjust mirroring behavior.


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


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. HTTP Client Settings Edit source

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


Enables additional debug output to the systemd journal.


The proxy server URL.


A list of domains that should NOT go through the proxy, separated by commas. Example: "localhost,.mylocaldomain"


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


The proxy server user name.


The proxy server password.


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


Time until a download gets aborted, when download speed is below low_speed_limit. Settings for Accessing SUSE Repositories Edit source

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:


Mirroring credentials user name.


Mirroring credentials password.

5.3.2 SSL Certificates and HTTPS Edit source

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 4.3, “Configuring Clients with rmt-client-setup.

6 Backing Up an RMT Server Edit source

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

6.1 Creating a Backup Edit source

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 Edit source

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 import repos ./repos/
  5. Synchronize your data and update your repositories.

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

7 Managing SSL/TLS Certificates Edit source

7.1 Regenerating HTTPS Certificates Edit source

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.4, “RMT Configuration with YaST”.

7.2 Regenerating CA Certificates and HTTPS Certificates Edit source

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

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 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.4, “RMT Configuration with YaST”.

Print this page