Synopsis
One of the benefits of using SUSE Products is that you get regular, tested and supposed updates via your registered products. This is great and works very well when you have a handful of servers. However, when you move into tens of servers or more, it becomes quote tedious to download from SUSE directly, as speed might vary greatly depending on the release importance. The other problem is if you have servers in a closed network and don’t want them accessing the internet for any reason. For these cases SUSE built a service called RMT or Repository Mirroring Tool or Repository Management Tool, depending who you ask. The software, free of charge in SUSE Enterprise Linux, allows you to select specific repositories and channels and pull them to a local server that then serves as a local registration and update server. This is what Microsoft used to do with Windows Update Services, except RMT works and it is very easy to use. In this article we will go through the quick steps to in stall an RMT server with a SLES JEOS (just enough OS) image inside Tuuli Cloud.
Requirements
- Tuuli Cloud Virtual machine with SLES JeOS 15 or 15 SP1
- minimum of 100GB disk space, depending on the products you select to mirror
- 2 Cores and 2 GB Ram
- SSH Key in Tuuli Cloud
- Public IP
- Ports 22, 80 and 443 TCP opened via Security Groups
- SUSE credentials for scc.suse.com and a valid product key for SLES (trial works to get you started)
Boot the instance and when its booted log in with user SLES and the IP (or dns name) of the instance. You should see something like this:
Last login: Wed Apr 29 11:35:09 2020 from 193.185.173.98 sles@cloudrmt:~>
Next , we register the instance with SUSE and your key:
sudo SUSEConnect --reg YOURREGISTRATIONKEY sudo zypper —non-interactive up
This will register the update repos from SUSE on your cloudrmt server and also update the server to the newest packages.
Next we will install yast2 packages and the RMT packages with the following:
sudo zypper —non-interactive in autoyast2 rmt-server yast2-rmt yast2-system screen
After this is completed, you need to start the rmt configuration by running:
sudo yast2 rmt
You can follow the steps now to configure the RMT server for this you will need to enter your SCC credentials since it needs to check what products you are entitled to, set the database password and set the certificate name.
NOTICE: Make sure you add the certificate additional name of the dns name you want to use for the instance in the future. Otherwise they will fail to connect since the certificate won’t match the name.
Once you have completed the installation, you are ready to sync the repository information and then enable some repositories.
This step has 3 parts.
Step 1
Check the repositories you want to mirror and enable them. Running CODE rmt-cli sync CODE will synchronise all repositories and ID that you have access to.
Step 2
When it is completed, run CODE rmt-cli product list –al CODE to see all repos in your list. If you have a big subscription, you will get quite a list. You can use grep to search for specific products, such as
rmt-cli product list --all | grep "15 SP1"
for all 15.1 SLES based repos or
rmt-cli product list --all | grep "Storage”
for all Enterprise Storage versions and repos.
Running the first example, will produce the following output:
cloudrmt:~ # rmt-cli product list --all | grep "15 SP1" | 1772 | Basesystem Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:35:38 UTC | | 1790 | Containers Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:20 UTC | | 1776 | Desktop Applications Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:35:47 UTC | | 1794 | Development Tools Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:35:52 UTC | | 1800 | HPC Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:37:09 UTC | | 1804 | Legacy Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:37 UTC | | 1808 | Public Cloud Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:45 UTC | | 1867 | Python 2 Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:53 UTC | | 1780 | Server Applications Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:29 UTC | | 1809 | SUSE Cloud Application Platform Tools Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:57 UTC | | 1785 | SUSE Linux Enterprise High Availability Extension | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:49 UTC | | 1768 | SUSE Linux Enterprise High Performance Computing | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:37:05 UTC | | 1763 | SUSE Linux Enterprise Server | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:35:17 UTC | | 1871 | SUSE Package Hub | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:16 UTC | | 1825 | Transactional Server Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:37:01 UTC | | 1798 | Web and Scripting Module | 15 SP1 | x86_64 | Mirror | 2020-05-04 04:36:33 UTC |
To enable a repo for mirroring, you need to run
rmt-cli product enable ID
where ID is the id of the repo, in case of the Basesystem module, it would be
rmt-cli product enable 1772
This will enable the repo for mirroring. Once you have enabled all the repos you want you need to mirror them.
Step 3
Mirroring is very simple. Running:
screen rmt-cli mirror
Will open a new screen to run mirroring in. This allows you to log out and the mirror will continue to run. Bear in mind that mirroring will take a long time. Just the Basic SLES 15.1, its modules and the updates are over 10 GB and the SUSE downstream is not always the greatest. Last time we did this it took a couple of hours.
Aftermath
Once you have the repos mirrored, you can actually register new deployments (and existing ones) to your RMT server with
SUSEConnect —url URLOFYOURRMTSERVER
if your certificate matches it will register all the modules needed and inside yast2 you can then add more modules if you have them mirrored.
This allows you to update and install over LAN speeds instead of internet speeds.
