Registering openEuler Clients
This section contains information about registering clients running openEuler operating systems.
When created at AWS, openEuler instances always have the same |
1. Add Software Channels
Before you register openEuler clients to your Uyuni Server, you need to add the required software channels, and synchronize them.
The architectures currently supported are: x86_64
and aarch64
.
For full list of supported products and architectures, see Supported Clients and Features.
In the following section, descriptions often default to the |
The channels you need for this procedure are:
OS Version | Core Channel | Client Channel | Update Channel | EPOL Channel | Everything Channel |
---|---|---|---|---|---|
openEuler 22.03 |
openeuler2203 |
openeuler2203-uyuni-client |
openeuler2203-update |
openeuler2203-epol |
openeuler2203-everything |
-
At the command prompt on the Uyuni Server, as root, use the
spacewalk-common-channels
command to add the appropriate channels:spacewalk-common-channels \ <base_channel_label> \ <child_channel_label_1> \ <child_channel_label_2> \ ... <child_channel_label_n>
-
If automatic synchronization is turned off, synchronize the channels:
spacewalk-repo-sync -p <base_channel_label>
-
Ensure the synchronization is complete before continuing.
The client tools channel provided by |
2. Check Synchronization Status
-
In the Uyuni Web UI, navigate to
, then click the channel associated to the repository. -
Navigate to the
Repositories
tab, then clickSync
and checkSync Status
.
-
At the command prompt on the Uyuni Server, as root, use the
tail
command 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 openEuler channels.
For more information on activation keys, see Activation Keys.
5. 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.
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 when the channel is refreshed or the first package is 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.
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 Repository Metadata the deployment and trust of that key is executed automatically. |
5.1. User Defined GPG Keys
Users can define custom GPG keys to be deployed to a 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 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 GPG key URL
the value file:///etc/pki/rpm-gpg/my_first_gpg.key
.
5.2. GPG Keys in Bootstrap Scripts
-
On the Uyuni 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. |
6. Register Clients
openEuler clients are registered in the same way as all other clients. For more information, see Client Registration.