Registering CentOS Clients

This section contains information about registering clients running CentOS operating systems.

You are responsible for arranging access to CentOS base media repositories and CentOS installation media, as well as connecting Uyuni Server to the CentOS content delivery network.

Registering CentOS clients to Uyuni is tested with the default SELinux configuration of enforcing with a targeted policy. You do not need to disable SELinux to register CentOS clients to Uyuni.

1. Add Software Channels

Before you can register CentOS 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 x86_64 architecture. Replace it with other architectures if appropriate.

The channels you need for this procedure are:

Table 1. CentOS Channels - CLI
OS Version	Base Channel	Client Channel	Updates/Appstream Channel
CentOS 7	centos7	centos7-uyuni-client	centos7-updates

Procedure: Adding Software Channels at the Command Prompt

At the command prompt on the Uyuni Server, as root, use the spacewalk-common-channels command to add the appropriate channels. Ensure you specify the correct architecture:
```
spacewalk-common-channels \
-a <architecture> \
<base_channel_name> \
<child_channel_name_1> \
<child_channel_name_2> \
... <child_channel_name_n>
```
If automatic synchronization is turned off, synchronize the channels:
```
spacewalk-repo-sync -p <base_channel_label>-<architecture>
```
Ensure the synchronization is complete before continuing.

The client tools channel provided by spacewalk-common-channels is sourced from Uyuni and not from SUSE.

If you are using modular channels, you must enable the Python 3.6 module stream on the client. If you do not provide Python 3.6, the installation of the spacecmd package will fail.

You might notice some disparity in the number of packages available in the AppStream channel between upstream and the Uyuni 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 CentOS manages their repositories. CentOS removes older version of packages when a new version is released, while Uyuni keeps all of them, regardless of age.

2. Check Synchronization Status

Procedure: Checking Synchronization Progress From the Web UI

In the Uyuni Web UI, navigate to Software Manage Channels, then click the channel associated to the repository.
Navigate to the Repositories tab, then click Sync and check Sync Status.

Procedure: Checking Synchronization Progress From the Command Prompt

At the command prompt on the Uyuni container host, as root, check the synchronization log file:
```
mgrctl exec -ti -- 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 CentOS channels.

For more information on activation keys, see Activation Keys.

4. 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. Because a software channel cannot be used when the GPG key is not trusted, the decision of assigning a channel to a client depends on the decision of trusting the key.

For more information about GPG keys, see GPG Keys.

5. 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 on the container host:

mgrctl exec -ti mgr-create-bootstrap-repo

For more information on registering your clients, see Client Registration.

6. Manage Errata

This section is only applicable to non-containerized Uyuni and it will be removed after CentOS 7 will go end-of-life.

When you update CentOS clients, the packages do not include metadata about the updates. You can use a third-party errata service to obtain this information.

The authors of CEFS provide patches or errata on a best-effort basis, in the hope they are useful but with no guarantees of correctness or currency. This could mean that the patch dates could be incorrect, and in at least one case, the published data was shown to be more than a month old. For more information on these cases, see https://github.com/stevemeier/cefs/issues/28#issuecomment-656579382 and https://github.com/stevemeier/cefs/issues/28#issuecomment-656573607.

Any problems or delays with the patch data might result in unreliable patch information being imported to your Uyuni Server. This would cause reports, audits, CVE updates, or other patch-related information to also be incorrect. Please consider alternatives to using this service, such as independently verifying patch data, or choosing a different operating system, depending on your security-related requirements and certifications criteria.

Procedure: Installing an Errata Service

On the Uyuni Server, from the command prompt, as root, add the sle-module-development-tools module:
```
SUSEConnect --product sle-module-development-tools/15.2/x86_64
```
Install errata service dependencies:
```
zypper in  perl-Text-Unidecode
```

Add or edit this line in /etc/rhn/rhn.conf:

java.allow_adding_patches_via_api = centos7-x86_64-updates,centos7-x86_64,centos7-x86_64-extras

Restart Tomcat:
```
systemctl restart tomcat
```
Create a file for your errata script:
```
touch /usr/local/bin/cent-errata.sh
```

Edit the new file to include this script, editing the repository details as required. This script fetches the errata details from an external errata service, unpacks it, and publishes the details:

#!/bin/bash
mkdir -p /usr/local/centos
cd /usr/local/centos
rm *.xml
wget -c http://cefs.steve-meier.de/errata.latest.xml
wget -c https://www.redhat.com/security/data/oval/v2/RHEL7/rhel-7.oval.xml.bz2
bzip2 -d rhel-7.oval.xml.bz2
wget -c http://cefs.steve-meier.de/errata-import.tar
tar xvf errata-import.tar
chmod +x /usr/local/centos/errata-import.pl
export SPACEWALK_USER='<adminname>';export SPACEWALK_PASS='<password>'
/usr/local/centos/errata-import.pl --server '<servername>' \
--errata /usr/local/centos/errata.latest.xml  \
--include-channels=centos7-x86_64-updates,centos7-x86_64,centos7-x86_64-extras \
--publish --rhsa-oval /usr/local/centos/rhel-7.oval.xml

Set up a cron job to run the script daily:

ln -s /usr/local/bin/cent-errata.sh /etc/cron.daily

For more information on this tool, see https://cefs.steve-meier.de/.