How to Set Up a Local SUSE RMT Server (SMT Replacement)

If you are setting up a local server for current SUSE Linux Enterprise systems, use the Repository Mirroring Tool (RMT), not a new SMT installation. SUSE replaced the Subscription Management Tool (SMT) with RMT starting with SLE 15. RMT synchronizes product and repository information from SUSE Customer Center (SCC), mirrors selected packages, and lets supported clients register through your local server. This guide follows the SUSE Linux Enterprise Server 15 SP7 RMT documentation, checked on October 6, 2026. Commands and package availability can differ on other releases, so use the guide for the exact server version you deploy.

Should you use RMT or keep SMT?

Choose RMT for a new local registration and update service for SLES 12 and newer clients. RMT is included with SLES starting at version 15 and can mirror SUSE repositories and custom repositories. It reduces repeated downloads and can keep client machines from connecting directly to SCC.

SMT remains relevant to older environments, but SUSE identifies SLE 12 as the last codestream for SMT. RMT does not support SLE 11 and earlier clients, and SUSE warns that RMT is not a complete feature-for-feature replacement: for example, its migration guide lists staged repositories, SMT client management, and reporting as capabilities that do not carry over in the same way. If your estate includes SLE 11 or depends on SMT-only workflows, do not assume that a direct replacement is possible. Review the migration guide and SUSE support options before changing the service.

RMT is also different from an air-gapped package repository. A standard RMT server needs outbound access to SCC and SUSE update services to synchronize metadata and packages. A disconnected deployment requires a separate export/import or offline-mirroring process.

What should you prepare before installation?

• A supported host: Plan a SLES 15 server for the RMT service. For migration from SMT, SUSE recommends using a newly installed SLES 15 host.
• SCC organization credentials: RMT uses the organization’s mirroring credentials, not a normal client registration code. In SCC, choose the correct organization and open Proxies to find them.
• A stable DNS name and TLS plan: Choose the fully qualified domain name (FQDN) clients will use, such as rmt.example.com. Make sure it resolves from client networks and matches the name on the HTTPS certificate.
• Repository storage: Size storage for the products, modules, versions, and architectures you intend to mirror. SUSE gives about 1.5 times the total enabled repository size as a general planning guide and notes that this is roughly 200 GB per SLE release including extensions. Actual needs vary; monitor free space, especially temporary space under /tmp.
• Network access: Allow the RMT host to reach the SUSE endpoints required by your release. The SLES 15 SP7 guide lists scc.suse.com, updates.suse.com, and installer-updates.suse.com over ports 80 and 443. Limit client access to the RMT service to the networks that need it.

Do not combine the RMT role with the SLES installation-server role on the same machine without checking the SUSE warning: the two configurations use different web servers on port 80 and are not designed to be enabled together.

How do you install and configure RMT?

1. Install the RMT package

On an existing SLES 15 host with the required repositories available, install the server package and apply current maintenance updates:

sudo zypper in rmt-server
sudo zypper patch

The exact package set can differ for minimal images and deployment methods. Follow the installation section for your chosen SLES release rather than copying a command from a different platform.

2. Run the YaST RMT configuration

Start the configuration module:

sudo yast2 rmt

Enter the SCC organization mirroring username and password when prompted. YaST also asks for a MariaDB database and user, and for a certificate common name. Use the RMT server’s client-facing FQDN as the common name. Add any other names or IP addresses that clients will actually use as alternative names on the certificate. A client that connects by an unlisted name can report a certificate mismatch even if the service is reachable.

If firewalld is enabled, use the YaST option to open the required RMT ports. Where possible, scope access to the correct network interface or zone. Complete the wizard and review its summary; SUSE says YaST enables and starts the required systemd services and timers.

3. Confirm the server name, certificate, and service

From a client network, confirm that the chosen FQDN resolves to the RMT host and that HTTPS presents a certificate trusted by the client. RMT’s generated CA certificate is stored at /etc/rmt/ssl/rmt-ca.crt; the server certificate and key are stored at /etc/rmt/ssl/rmt-server.crt and /etc/rmt/ssl/rmt-server.key. Protect the private key and keep the CA certificate available for clients that need to trust it. Use the exact same FQDN for registration that appears in the server certificate.

How do you select and mirror only the repositories you need?

4. Synchronize product and repository metadata

After setup, synchronize the local RMT database with SCC:

sudo rmt-cli sync

This updates the product and repository information available to RMT; it does not mean that every package has already been downloaded. The automatic metadata synchronization is managed by rmt-server-sync.timer. Check its state with:

systemctl status rmt-server-sync.timer

5. Find the product identifiers for your estate

List available products and repositories before enabling anything:

sudo rmt-cli products list --all
sudo rmt-cli repos list --all

Use the IDs or product strings reported by your own server. IDs in online examples may be different because availability depends on subscriptions, product versions, architectures, and the metadata returned by SCC.

6. Enable the required products

Enable the products that clients actually use. For example, after confirming that the product string is present in your output, you might run:

sudo rmt-cli products enable SLES/15/x86_64

Enabling a product also enables its associated repositories, such as pool and update repositories. If your systems use additional modules or extensions, check that those products are available and enable the ones needed. Avoid mirroring every product “just in case”: it consumes storage and increases synchronization time.

7. Mirror packages and inspect the result

Start the initial mirror manually so you can observe completion and troubleshoot before relying on the schedule:

sudo rmt-cli mirror

RMT stores mirrored content under /var/lib/rmt/public/repo by default. Check the available disk space and review the command output. The daily mirror schedule is managed by rmt-server-mirror.timer; inspect its status with:

systemctl status rmt-server-mirror.timer

A successful metadata sync alone is not proof that clients can install updates. The selected repositories need to be mirrored, the client must be able to reach the server, and product access must be valid for the organization.

How do you register a client against the local server?

8. Test with one client first

On a supported SLES client, register it against the RMT hostname. SUSE documents this command form:

sudo SUSEConnect --url https://rmt.example.com

Replace the example host with the FQDN covered by your certificate. Clients normally do not need the SCC mirroring credentials; the RMT host uses those credentials to synchronize on behalf of the organization. For systems that need help importing the RMT CA, SUSE provides an rmt-client-setup script from the server. Review the current client guide and verify the certificate fingerprint or trust chain before accepting a certificate.

You can also configure registration during installation with the regurl=https://rmt.example.com boot parameter, or use YaST’s Product Registration module and choose the local registration server. For automated installations, SUSE documents an AutoYaST option. Pick one method that fits how your systems are provisioned.

9. Verify registration and package access

On the client, confirm that registration completes, the expected products and repositories appear, and repository metadata can be refreshed. For example, inspect repository definitions with zypper lr and refresh with sudo zypper refresh. Then test a package query or update in a maintenance window. If a module is missing, check whether it is enabled and mirrored on RMT before changing client-side repository files.

Test an ordinary update path on one representative client before redirecting a large fleet. After that test succeeds, update provisioning profiles, installation boot parameters, or configuration management so new and rebuilt systems use the same RMT URL.

What should you check when something fails?

What changes if you are migrating from SMT?

Treat migration as a data and workflow change, not a package upgrade in place. SUSE recommends a new SLES 15 host. Its documented export/import process uses smt-data-export on SMT and rmt-data-import on the new server after RMT has synchronized with SCC. Staged repository settings are not exported, only repositories marked for mirroring are carried over, and expired products are not available on RMT. SMT client jobs and patch status are not exported. Plan to re-create operational processes that depended on those features and validate registration records before redirecting production clients.

Keep the old service available during a controlled transition if your support and security policies allow it. Migrate a small client group, confirm registration, repositories, certificate trust, and update behavior, then expand. Do not retire the SMT host until legacy clients and any unsupported workflows have an explicit destination.

How do you know the setup is ready?

• The RMT FQDN resolves correctly and HTTPS uses a certificate trusted by clients.
• The RMT host synchronizes current SCC metadata and mirrors every product repository required by the pilot clients.
• A supported client registers to the local URL and sees the intended product repositories.
• A client can refresh repository metadata and complete a controlled package operation.
• Disk capacity, temporary space, timers, logs, backup, and certificate renewal have an owner and monitoring plan.

RMT centralizes registration and package delivery, but it does not remove the need to manage subscriptions, product selection, client lifecycle, certificate trust, backups, and update testing. For the exact procedures and release-specific differences, consult SUSE’s SLES 15 SP7 Repository Mirroring Tool Guide, the SMT-to-RMT migration chapter, the RMT client configuration chapter, and SUSE’s repository mirroring chapter.