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:
CODE
Last login: Wed Apr 29 11:35:09 2020 from 193.185.173.98
sles@cloudrmt:~>
CODE
Next , we register the instance with SUSE and your key:
CODE
sudo SUSEConnect –reg YOURREGISTRATIONKEY
sudo zypper —non-interactive up
CODE
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:
CODE
sudo zypper —non-interactive in autoyast2 rmt-server yast2-rmt yast2-system
screen
CODE
After this is completed, you need to start the rmt configuration by running:
CODE
sudo yast2 rmt
CODE
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 synchronize 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 CODE rmt-cli product list –all | grep “15 SP1”
CODE for all 15.1 SLES based repos or CODE rmt-cli product list –all | grep
“Storage” CODE for all Enterprise Storage versions and repos.
Running the first example, will produce the following output:
CODE
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 |
CODE
To enable a repo for mirroring, you need to run CODE rmt-cli product enable ID
CODE where ID is the id of the repo, in case of the Basesystem module, it would be
CODE rmt-cli product enable 1772 CODE. This will enable the repo for mirroring.
Once you have enabled all the repos you want you need to mirror them.
HEADER 3: Step 3
Mirroring is very simple. Running:
CODE
screen rmt-cli mirror
CODE
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.
HEADER 2: Aftermath
Once you have the repos mirrored, you can actually register new deployments (and
existing ones) to your RMT server with CODE 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.
