Registering Rocky Linux Clients
This section contains information about registering Salt clients running Rocky Linux operating systems.
Traditional clients are not available on Rocky Linux. Rocky Linux clients are only supported as Salt clients.
|
|
Registering Rocky Linux clients to SUSE Manager is tested with the default SELinux configuration of |
1. Add Software Channels
Before you can register Rocky Linux clients to your SUSE Manager Server, you need to add the required software channels, and synchronize them.
The architectures currently supported are: x86_64 and aarch64, on version 9 additionally ppc64le and s390x.
For full list of supported products and architectures, see Supported Clients and Features.
|
In the following section, descriptions often default to the |
For example, when working with x86_64 architecture, you need this product:
| OS Version | Product Name |
|---|---|
Rocky Linux 9 |
Rocky Linux 9 x86_64 |
Rocky Linux 8 |
Rocky Linux 8 x86_64 |
-
In the SUSE Manager Web UI, navigate to .
-
Locate the appropriate products for your client operating system and architecture using the search bar, and check the appropriate product. This will automatically check all mandatory channels. Also all recommended channels are checked as long as the
include recommendedtoggle is turned on. Click the arrow to see the complete list of related products, and ensure that any extra products you require are checked. -
Click Add Products and wait until the products have finished synchronizing.
Alternatively, you can add channels at the command prompt. The channels you need for this procedure are:
| OS Version | Base Channel |
|---|---|
Rocky Linux 9 |
rockylinux9-x86_64 |
Rocky Linux 8 |
rockylinux8-x86_64 |
-
At the command prompt on the SUSE Manager Server, as root, use the
mgr-synccommand to add the appropriate channels:mgr-sync add channel <channel_label_1> mgr-sync add channel <channel_label_2> mgr-sync add channel <channel_label_n>
-
Synchronization starts automatically. If you want to synchronize the channels manually, use:
mgr-sync sync --with-children <channel_name>
-
Ensure the synchronization is complete before continuing.
|
You might notice some disparity in the number of packages available in the AppStream channel between upstream and the SUSE Manager channel. You might also see different numbers if you compare the same channel added at a different point in time. This is due to the way that Rocky Linux manages their repositories. Rocky Linux removes older version of packages when a new version is released, while SUSE Manager keeps all of them, regardless of age. |
|
The AppStream repository provides modular packages. This results in the SUSE Manager Web UI showing incorrect package information. You cannot perform package operations such as installing or upgrading directly from modular repositories using the Web UI or API. Alternatively, you can use Salt states to manage modular packages on Salt clients, or use the |
2. Check Synchronization Status
-
In the SUSE Manager Web UI, navigate to and select the
Productstab. This dialog displays a completion bar for each product when they are being synchronized. -
Alternatively, you can navigate to , then click the channel associated to the repository. Navigate to the
Repositoriestab, then clickSyncand checkSync Status.
-
At the command prompt on the SUSE Manager Server, as root, use the
tailcommand to check the synchronization log file:tail -f /var/log/rhn/reposync/<channel-label>.log
-
Each child channel generates its own log during the synchronization progress. You need to check all the base and child channel log files to be sure that the synchronization is complete.
3. Create an Activation Key
You need to create an activation key that is associated with your Rocky Linux channels.
For more information on activation keys, see Activation Keys.
4. Trust GPG Keys on Clients
Operating systems either trust their own GPG keys directly or at least ship them installed with the minimal system. But third party packages signed by a different GPG key need manual handling. The clients can be successfully bootstrapped without the GPG key being trusted. However, you cannot install new client tool packages or update them until the keys are trusted.
Salt clients now use GPG key information entered for a software channel to manage the trusted keys. When a software channel with GPG key information is assigned to a client, the key is trusted as soon as the channel is refreshed or the first package gets installed from this channel.
The GPG key URL parameter in the software channel page can contain multiple key URLs separated by "whitespace". In case it is a file URL, the GPG key file must be deployed on the client before the software channel is used.
The GPG keys for the Client Tools Channels of Red Hat based clients are deployed on the client into /etc/pki/rpm-gpg/ and can be referenced with file URLs.
Same is the case with the GPG keys of Expanded Support clients.
Only in case a software channel is assigned to the client they will be imported and trusted by the system.
|
Because Debian based systems sign only metadata, there is no need to specify extra keys for single channels. If a user configures an own GPG key to sign the metadata as described in "Use Your Own GPG Key" in Signing Repository Metadata the deployment and trust of that key is executed automatically. |
4.1. User defined GPG keys
Users can define their own GPG keys to be deployed to the client.
By providing some pillar data and providing the GPG key files in the Salt filesystem, they are automatically deployed to the client.
These keys are deployed into /etc/pki/rpm-gpg/ on RPM based operating systems and to /usr/share/keyrings/ on Debian systems:
Define the pillar key [literalcustom_gpgkeys for the client you want to deploy the key to and list the names of the key file.
cat /srv/pillar/mypillar.sls custom_gpgkeys: - my_first_gpg.key - my_second_gpgkey.gpg
Additionally in the Salt filesystem create a directory named gpg and store there the GPG key files with the name specified in the custom_gpgkeys pillar data.
ls -la /srv/salt/gpg/ /srv/salt/gpg/my_first_gpg.key /srv/salt/gpg/my_second_gpgkey.gpg
The keys are now deployed to the client at /etc/pki/rpm-gpg/my_first_gpg.key and /etc/pki/rpm-gpg/my_second_gpgkey.gpg.
The last step is to add the URL to the GPG key URL field of the software channel.
Navigate to and select the channel you want to modify.
Add to GPG key URL the value file:///etc/pki/rpm-gpg/my_first_gpg.key.
4.2. GPG Keys in Bootstrap Scripts
-
On the SUSE Manager Server, at the command prompt, check the contents of the
/srv/www/htdocs/pub/directory. This directory contains all available public keys. Take a note of the key that applies to the channel assigned to the client you are registering. -
Open the relevant bootstrap script, locate the
ORG_GPG_KEY=parameter and add the required key. For example:uyuni-gpg-pubkey-0d20833e.key
You do not need to delete any previously stored keys.
|
Trusting a GPG key is important for security on clients. It is the task of the administrator to decide which keys are needed and can be trusted. A software channel cannot be assigned to a client when the GPG key is not trusted. |
5. Manage GPG Keys
Clients use GPG keys to check the authenticity of software packages before they are installed. Only trusted software can be installed on clients.
|
Trusting a GPG key is important for security on clients. It is the task of the administrator to decide which keys are needed and can be trusted. A software channel cannot be assigned to a client when the GPG key is not trusted. |
For more information about GPG keys, see GPG Keys.
6. Register Clients
To register your clients, you need a bootstrap repository. By default, bootstrap repositories are automatically created, and regenerated daily for all synchronized products. You can manually create the bootstrap repository from the command prompt, using this command:
mgr-create-bootstrap-repo
For more information on registering your clients, see Client Registration.
7. Manage Errata
When you update Rocky Linux clients, the packages include metadata about the updates.