Register Clients To Satellite Server 6 Or Katello

Red Hat Network Satellite Server 6, as well as its upstream project Katello, has been developed to provide software to client hosts, as well as manage their configuration sending SSH remote commands or leveraging on Puppet or Ansible.

The published packages are provided by the means of content views with frozen packages versions.

The obvious requirement to benefit from the provided services is registering client hosts. This post shows how to register clients on Red Hat Network Satellite Server 6 or Katello, providing all the necessary information to be skilled enough on subscription-manager to be able not only to operate it, but to successfully troubleshoot when it is not working as expected.

In addition to that, we also see how to enable and configure SSH based remote actions and how to run an existing Job Template..

Overview Of Registering The Client

Registering the client host means basically two things:

• securely identify it
• grant it the right to download the software it needs

since the adoption of subscription-manager, all of the above is performed in a secure and easy way leveraging three kind of X.509 certificates

the consumer certificate is generated at registration time: registering the client host means providing a security token (can either be a username/password pair or an activation key) that creates a Content Host object related to the client into the Satellite.

Key Topics

My goal in this post is much more ambitious than simply providing the commands to blindly register the client host: I want to give you a quick overview of the key topics with the minimum notions about their internals that are necessary to know how to survive when things go wrong.

Consumer

The consumer is the one that consumes the software provided by the Satellite, ... so it is the client host. The Satellite validates its identity at each check-in, asking the client host to provide the consumer certificate.

Generating The Consumer Certificate

This certificate is generated at client host registration time: the client host generates a private key and sends a Certificate Signing Request to the Satellite that signs it, generating a client certificate with the client UUID listed into the Common Name. The UUID is also included in the  Subject Alternative Names too, along with the FQDN of the client host.

The certificate is then sent back to the client host, which stores both certificate ("cert.pem") and the private key ("key.pem") files beneath the "/etc/pki/consumer" directory.

Displaying The Contents Of The Consumer Certificate

We can see the contents of a consumer certificate using the rct command line tool as follows:

rct cat-cert /etc/pki/consumer/cert.pem

the outcome is as follows:

+-------------------------------------------+
	Identity Certificate
+-------------------------------------------+

Certificate:
	Path: /etc/pki/consumer/cert.pem
	Version: 1.0
	Serial: 3915644524775027711
	Start Date: 2022-02-03 20:42:16+00:00
	End Date: 2038-02-03 21:42:16+00:00
	Alt Name: DirName:/CN=8cc00be6-7128-401b-968a-5564714ce53d, DirName:/CN=srv-ci-up3a002.prod.carcano.local

Subject:
	CN: 8cc00be6-7128-401b-968a-5564714ce53d

Issuer:
	C: US
	CN: sat-ci-up3a002.mgmt.carcano.local
	L: Raleigh
	O: Katello
	OU: SomeOrgUnit
	ST: North Carolina

Of course the necessary requisite to have these files on the host is having already registered it to the Satellite - we'll see how to do this shortly.

Subscription

A subscription is the agreement that grants the right to install a given number of instances of a product from the start date until the expiration date of the subscription: once expired, the subscription is no longer valid and you must obtain a new subscription.

When you are dealing with Red Hat products, the subscription also contains commercial metadata such as the Contract Number or the Account Number, or the Service Level Agreement (SLA) with Red Hat. At the time of writing this post, the available SLA are "Premium", "Standard" and "Self Support".

You can entitle an host to use a given subscription, or have it automatically entitled to use the relevant subscriptions by specifying one or more activation keys at registration time.

Entitlement

An entitlement is the claim of the right of being attached to a subscription that grants to the client the right to download a certain product. If the subscription provides a limited number of product instances, attaching to a subscription decreases the number of available instances of that product and increases the number of assigned instances in that subscription.

The manifest of an entitlement is an X509 certificate: it contains several metadata: besides information such as the ID and name of the product, the entitlement certificate provides a lot of additional information, such as the list of repositories (that are called Contents URL) from where the various versions of the product can be downloaded.

Generating The Entitlement Certificate

This certificate is signed by the Satellite and is recreated each time something is modified in the subscription to which the entitlement relates: each time the client needs to download packages, it provides this certificate as an authentication token.

Displaying The Contents Of The Entitlement Certificate

Same way as with consumer certificates, we can use the rct command line tool to have a look to an entitlement certificate:

rct cat-cert /etc/pki/entitlement/6557567279976834240.pem 

Of course the necessary requisite to have this file on the host is having already registered it to the Satellite - we'll see how to do this shortly.

Product

As the name does suggest the product is just a product, such as "Red Hat Enterprise Linux", or "CentOS Linux", "PostgreSQL"; a product can even be anything developed by your Corporate.

Product Certificate

The manifest file that describes the product is the product certificate: it is a certificate with custom metadata that can be exploited by the auto-attach feature of subscription-manager to guess what products are compatible with the operating system version and so can be installed, or when providing a criteria to automatically attach the matching products.

The product certificate is provided by an RPM package that installs it beneath the "/etc/pki/product" directory, into a PEM file with the numeric ID of the product as name. For example "69.pem" is the name of the file with the product certificate of "Red Hat Enterprise Linux".

A product certificate contains metadata stored as children the "1.3.6.1.4.1.2312.9.1" OID namespace: the first children number of the namespace is the numeric ID of the product (that marks the beginning of the product namespace). For example, since "Red Hat Enterprise Linux" has been assigned the ID 69, its OID namespace is "1.3.6.1.4.1.2312.9.1.69".

Beneath the product namespace there are the following attributes:

• Name: the name of the product, for example "Red Hat Enterprise Linux"
• Version: the version of the product, for example "7.9"
• Arch: the architecture family of the product, for example "x86_64"
• Tags: a comma-separated list of tags assigned to the product. These are often used to express affinities. For example "rhel-7,rhel-7-server"
• Brand Type: an optional attribute with the brand type
• Brand Name: an optional attribute with the brand name

Creating A Product Certificate

Let's see now how to generate a product certificate for a product published on Satellite.

In our example, the Product ID of the CentOS Server product guessed from Satellite is "656104112056".

Since every custom attribute we are about to add has its own OID, it is straightforward that to generate such a kind of certificate we need a dedicated openssl config file that lists them all and instructs openssl on how to add them to the Certificate Signing Request (CSR), so that the signing Certification Authority can then copy them to the actual certificate.

As an example, let's create the "products.conf" file with the following contents:

id_section = contents_oid

[ contents_oid ]
Name=1.3.6.1.4.1.2312.9.1.656104112056.1
Version=1.3.6.1.4.1.2312.9.1.656104112056.2
Arch=1.3.6.1.4.1.2312.9.1.656104112056.3
Tags=1.3.6.1.4.1.2312.9.1.656104112056.4

[ req ]
distinguished_name  = req_distinguished_name
req_extensions      = centos85-x86_64

[ req_distinguished_name ]
commonName                      = Common Name

[ centos85-x86_64 ]
basicConstraints = CA:FALSE
1.3.6.1.4.1.2312.9.1.656104112056.1 = ASN1:UTF8String:CentOS Server
1.3.6.1.4.1.2312.9.1.656104112056.2 = ASN1:UTF8String:8.5
1.3.6.1.4.1.2312.9.1.656104112056.3 = ASN1:UTF8String:x86_64
1.3.6.1.4.1.2312.9.1.656104112056.4 = ASN1:UTF8String:centos-8,centos-8-server

then we can work as we would do as usual: generate the RSA key we use for any product certificate:

openssl genrsa -aes256 -out corporate.key 4096

then create the Certificate Signing Request (CSR) for the "CentOS Server" Product, version "8.5" for  "x86_64" architecture:

openssl req -config products.conf -key corporate.key -new -sha256 -out centos85-x86_64.csr

in this example, I specify "CN=Carcano SA [1dse-34221-frrg-1111]" as the Common Name.

We can now submit the CSR to the Corporate CA to get the certificate.

Just as an example, if the corporate CA would be made using openssl, the certificate generation command would be:

openssl ca -config openssl.conf -days 7000 -in centos85-x86_64.csr -out 656104112056.pem

the certificate must then be packaged within an RPM and installed on the  client.

Installing The Product Certificate

Once you get the product certificate, install it beneath the "/etc/pki/product" directory manually, or have it done by the package management software.

Displaying The Contents Of A Product Certificate

Same way as with consumer and entitlement certificates, we can have a look to any product certificate using the rct command line tool as follows:

rct cat-cert 656104112056.pem

the output is as follows:

+-------------------------------------------+
	Product Certificate
+-------------------------------------------+

Certificate:
	Path: /etc/pki/product/656104112056.pem
	Version: 1.0
	Serial: 4096
	Start Date: 2022-02-07 20:34:12+00:00
	End Date: 2038-07-13 20:34:12+00:00

Subject:
	CN: CN=Carcano SA [1dse-34221-frrg-1111]

Issuer:
	C: CH
	CN: Intermediate CA
	O: Carcano SA
	ST: Tessin

Product:
	ID: 656104112056
	Name: CentOS Server
	Version: 8.5
	Arch: x86_64
	Tags: centos-8,centos-8-server
	Brand Type: 
	Brand Name:  

Listing Installed Products

Subscription-manager relates the product certificates to the entitlement of having them installed.

In this example we installed the product certificate "656104112056.pem" into the "/etc/pki/product" directory: this means that the subscription-manager can see it and relate it to the attached subscriptions.

To see the list of installed products, along with the status of their related subscriptions, type:

sudo subscription-manager list --installed

the outcome is as follows:

+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: CentOS Server
Product ID: 656104112056
Version: 8.5
Arch: x86_64
Status: Unknown
Status Details: 
Starts: 
Ends: 

as you see the status of the attached subscription is Unknown: this is right - we have only created and installed the product certificate, but we have not attached the client host to a subscription that provides the product yet.

The Registration Process

Now that we have clarified enough all the concepts that are necessary to know, we can go on and see how to deal with the registration process itself.

Everything can be made using subscription-manager, after configuring it to connect to your Satellite.

The katello-ca-consumer RPM Package

Manually configuring subscription-manager and in general the system is a repetitive and time-consuming task - so it is the perfect candidate for an automated procedure.

Indeed the Satellite provides the katello-ca-consumer RPM package that automatically configures the consumer (the client host) and installs subscription-manager along with its dependencies if they are missing.

We can easily download the katello-ca-consumer RPM package right from the Satellite simply using curl as follows (in this post the Satellite FQDN is "sat-ci-up3a002.mgmt.carcano.local"):

curl -k -O https://sat-ci-up3a002.mgmt.carcano.local/pub/katello-ca-consumer-sat-ci-up3a002.mgmt.carcano.local-1.0-1.noarch.rpm

then we can install it as follows:

sudo dnf localinstall -y \
katello-ca-consumer-sat-ci-up3a002.mgmt.carcano.local-1.0-1.noarch.rpm

now the consumer has been properly set up with everything needed to register the client host on the Satellite.

We can have a look to the configuration settings with the following command:

sudo subscription-manager config

the outcome is as follows:

[server]
   hostname = sat-ci-up3a002.mgmt.carcano.local
   insecure = [0]
   no_proxy = []
   port = [443]
   prefix = /rhsm
   proxy_hostname = []
   proxy_password = []
   proxy_port = []
   proxy_scheme = [http]
   proxy_user = []
   server_timeout = [180]
   ssl_verify_depth = [3]

[rhsm]
   auto_enable_yum_plugins = [1]
   baseurl = https://sat-ci-up3a002.mgmt.carcano.local/pulp/repos
   ca_cert_dir = [/etc/rhsm/ca/]
   consumercertdir = [/etc/pki/consumer]
   entitlementcertdir = [/etc/pki/entitlement]
   full_refresh_on_yum = 1
   inotify = [1]
   manage_repos = [1]
   package_profile_on_trans = 1
   pluginconfdir = [/etc/rhsm/pluginconf.d]
   plugindir = [/usr/share/rhsm-plugins]
   productcertdir = [/etc/pki/product]
   repo_ca_cert = /etc/rhsm/ca/katello-server-ca.pem
   repomd_gpg_url = []
   report_package_profile = [1]

[rhsmcertd]
   auto_registration = [0]
   auto_registration_interval = [60]
   autoattachinterval = [1440]
   certcheckinterval = [240]
   disable = [0]
   splay = [1]

[logging]
   default_log_level = [INFO]

[] - Default value in use 

you can alter this configuration using the relevant options of the subscription-manager config command: you can easily get the syntax by typing:

sudo subscription-manager config --help

Registering The Client Host

We are finally ready to proceed registering the client host to the Satellite.

Besides authenticating to the Satellite, this operation requires at least to specify the Organization to whom the client host belongs to..

Listing the Organizations

It may happen not to exactly remember how it is written the name that have been assigned to the Organization: if this happens you can get the list with all the Organizations configured on the Satellite by typing:

sudo subscription-manager orgs --username mcarcano

the outcome is a list like the following one:

+-------------------------------------------+
          mcarcano Organizations
+-------------------------------------------+

Name: Carcano CH
Key:  Carcano_CH

Name: Default Organization
Key:  Default_Organization

Of course it displays only the Organization the username you supply has access to.

Listing the Environments

Since the Satellite provides the software by publishing the repositories into distinguished environments, we may need to get the list of the environments configured for the Organization we want to assign the host to. This can be easily accomplished using subscription-manager as follows:

sudo subscription-manager environments --org="Carcano CH" \
--username mcarcano

the outcome is a list like the following one:

+-------------------------------------------+
          Environments
+-------------------------------------------+
Name:        Lab/CentOS_8
Description: 

Name:        Library/CentOS_8
Description: 

Name:        Lab/CentOS_7
Description: 

Name:        Library/CentOS_7
Description: 

Name:        Library
Description: 

Mine is short, since this is only a Lab, but in the real world the list is usually much more long.

Registering With Username And Password

This is the most intuitive (but also the most cumbersome) method for registering the client host: Satellite authenticates the user by checking the supplied username and password. The user must of course have at least the rights to register a client host to the Satellite.

Once registered the client host can attach to any of the available subscriptions and enable any of the repositories that are available in the environment it has been assigned to.

This means that when registering the client host, besides the Organization it is also necessary to specify the environment you want to put it into.

For example, to register the client host using username and password:

sudo subscription-manager register --org="Carcano CH" --environment=Lab/CentOS_8 \
--username mcarcano

the password is interactively asked (but you can also provide it on the command line using the --password parameter). If you omit the --environment parameter, also the environment is interactively asked.

Once the command returns successfully, the consumer certificate has just been created and stored into the "/etc/pki/consumer" directory.

In addition to that, the client host pushes to the Satellite a set of facts that describes it, such as the number of CPUs, the amount of RAM, the networking configuration and so on.

You can see these facts guessed by subscription-manager by typing:

sudo subscription-manager facts

this is a snippet of the output on my system:

cpu.core(s)_per_socket: 2
cpu.cpu(s): 2
...
distribution.id: 8
distribution.name: CentOS Linux
distribution.version: 8
distribution.version.modifier: Unknown
dmi.baseboard.manufacturer: Oracle Corporation
dmi.baseboard.product_name: VirtualBox
...
last_boot: 2022-02-10 07:02:13
lscpu.architecture: x86_64
lscpu.bogomips: 7199.99
...
lscpu.vendor_id: GenuineIntel
lscpu.virtualization_type: full
memory.memtotal: 992252
memory.swaptotal: 2097148
net.interface.eth0.ipv4_address: 10.1.0.4
...
network.fqdn: srv-ci-up3a002.prod.carcano.local
network.hostname: srv-ci-up3a002.prod.carcano.local
network.ipv4_address: 10.1.0.4
network.ipv6_address: fe80::20b6:8b15:326e:fb8, fe80::bd6a:47db:6368:75d6
...
proc_cpuinfo.common.cpu_family: 6
...
proc_cpuinfo.common.vendor_id: GenuineIntel
...
system.certificate_version: 3.2
system.default_locale: en_US.UTF-8
uname.machine: x86_64
uname.nodename: srv-ci-up3a002.prod.carcano.local
uname.release: 4.18.0-240.1.1.el8_3.x86_64
uname.sysname: Linux
uname.version: #1 SMP Thu Nov 19 17:20:08 UTC 2020
virt.host_type: virtualbox, kvm
virt.is_guest: True
virt.uuid: 96e15246-3da1-ca4d-ba6f-e290052b35cc

This set of facts is periodically pushed to the satellite each time the rhsmcertd daemon checks-in.

Be wary that the registration command registers the client, but unless you provide the --auto parameter it does not attached it to any available subscription - try typing:

sudo subscription-manager list --consumed

the outcome is:

No consumed subscription pools were found.

If you want to have your own products recognized by subscription-manager so that the auto attach feature works with them, you must generate a product certificate for each of them as described before and install them into the "/etc/pki/product" directory.

We'll see an example of this shortly, for the "CentOS Server" product we created the certificate before, when demonstrating how to register using an activation key.

At the moment I'm writing this post, the signature of the product certificate is not checked, so you can generate it with whatever certificate authority you wish.

Registering Using An Activation Key

This is certainly the most popular method for registering client hosts: Satellite verifies the right of adding a client host  by checking the supplied activation key.

The activation key is a multi-purpose authentication token that:

• lets Satellite check that  the user issuing the registration command actually have right to register a client host
• relates the host to the desired Content View of a given environment
• only when dealing with Red Hat products, binds the host to the proper Service Level Agreement (SLA) and Release Version
• attaches the host to one or more subscriptions, and enable or disable some or all the repositories the attached subscriptions grants access to
• assign the host to the desired host collection. An host collection is a named group of hosts you can use as a target to perform actions as a whole.

Be wary that when registering the client, it is possible to specify more than one activation key by separating them using commas.

A broadly used strategy is to have:

• an activation key that registers the client host and connects it to the right Content View of the desired environment, assigns it to the right host collection and attach the subscription of the version of the Linux distribution in use, enabling only the desired repositories
• additional activation keys dedicated to subscriptions of specific products that enabled only desired repositories

Just to show you an example, let's unregister the client host we just registered:

sudo subscription-manager unregister

this causes the removal of the consumer certificate from the "/etc/pki/consumer" directory.

Now register it again, this time using the activation keys "CentOS8-Lab" and "PostgreSQL10-for-CentOS8" as member of the "Carcano CH" organization.

sudo subscription-manager register --org="Carcano CH" \
--activationkey="CentOS8-Lab,PostgreSQL10-for-CentOS8"

Again, once the command returns successfully, the consumer certificate has just been created and stored into the "/etc/pki/consumer" directory.

Let's verify the entitlements:

sudo subscription-manager list --consumed

the outcome is:

+-------------------------------------------+
Consumed Subscriptions
+-------------------------------------------+
Subscription Name: CentOS Server
Provides: CentOS Server
SKU: 656104112056
Contract: 
Account: 
Serial: 8897560660188851257
Pool ID: 8a8180827e777cec017e7787dfaf0012
Provides Management: No
Active: True
Quantity Used: 1
Service Type: 
Service Level: 
Status Details: Subscription is current
Subscription Type: Standard
Starts: 01/20/22
Ends: 01/18/32
System Type: Physical

This means that as expected, we can install and update both CentOS and PostgreSQL Server at wish.

Now that we have the entitlement to install the "CentOS Server" product , let's see if anything changed about how subscription-manager relates the status of the attached subscription with the product certificate of the "CentOS Server" product we created and installed before:

sudo subscription-manager list --installed

this time the outcome is:

+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: CentOS Server
Product ID: 656104112056
Version: 7.9
Arch: x86_64
Status: Subscribed
Status Details: 
Starts: 01/20/2022
Ends: 01/18/2032

it seems that our trick to create a product certificate does work: we have the right to install the product that is marked as subscribed and the attached subscription is valid until 01/18/2032.

Ensure Rhsmcertd Service Is Running

Entitlements (the subscriptions a client host is attached to) can either be managed issuing attach commands on the client host, or operating on the Satellite server: if the attached subscriptions are changed on the Satellite, the client host must be notified, so that it downloads the new entitlement certificates.

This synchronization is made by the rhsmcertd service, that periodically checks-in to the Satellite. We must start it if it is not already started.

sudo systemctl start rhsmcertd

Working With Subscriptions

Registering the client host is only the prerequisite to access the software repositories: as we saw it is necessary that the client host also is attached to the  subscriptions that provide access to the desired software repositories.

List Attached Subscriptions (The Entitlements)

Of course the very first thing to know is how to list the subscriptions the client has been already attached - the so called entitlements:

sudo subscription-manager list --consumed

for example, if the output is like the following:

+-------------------------------------------+
Consumed Subscriptions
+-------------------------------------------+
Subscription Name: CentOS Server
Provides: CentOS Server
SKU: 656104112056
Contract: 
Account: 
Serial: 8897560660188851257
Pool ID: 8a8180827e777cec017e7787dfaf0012
Provides Management: No
Active: True
Quantity Used: 1
Service Type: 
Service Level: 
Status Details: Subscription is current
Subscription Type: Standard
Starts: 01/20/22
Ends: 01/18/32
System Type: Physical

it means that the client is currently attached to the "CentOS Server" subscription that provides the "CentOS Server" product, and so the client host has the entitlement to install and update the product.

This means also that there is the related entitlement certificate into the "/etc/pki/entitlements" directory.

List Available Subscriptions

We can have a look to the available subscriptions: since these are bound to products, we can know the products we can install by attaching to them:

sudo subscription-manager list --available

the output looks like as follows:

+-------------------------------------------+
Available Subscriptions
+-------------------------------------------+
Subscription Name: PostgreSQL
Provides: 
SKU: 369190582741
Contract: 
Pool ID: 8a8180827e828d29017e829ba4070027
Provides Management: No
Available: Unlimited
Suggested: 1
Service Type: 
Roles: 
Service Level: 
Usage: 
Add-ons: 
Subscription Type: Standard
Starts: 01/22/22
Ends: 12/01/49
Entitlement Type: Physical

as you see, if we need to install the "PostgreSQL" product we just have to attach to the "PostgreSQL" subscription so to get the entitlement to install and update it.

Attaching To A Subscription

Attaching the client host to a subscription requires just to provide its "Pool ID".

For example, to attach the client host to the "PostgreSQL" subscription of the previous example:

sudo subscription-manager attach --pool=8a8180827e828d29017e829ba4070027

the output must be as follows:

Successfully attached a subscription for: PostgreSQL

this means that as by now the client host has an entitlement certificate for the attached subscription stored into the "/etc/pki/entitlement" directory.

Detaching From A Subscription

Same way as we can attach the client host to a subscription, we can remove it right after uninstalling a product or even simply if for any reason we need to attach the client host to another subscription that provides the same product. We can simply do this providing its "Pool ID" as follows:

sudo subscription-manager remove --pool=8a8180827e828d29017e829ba4070027

the output must be as follows:

The entitlement server successfully removed these pools:
8a8180827e828d29017e829ba4070027
The entitlement server successfully removed these serial numbers:
2298128950294303483

This obviously causes the removal of the related entitlement certificate from the "/etc/pki/entitlement" directory.

Working With Repositories

Once attached to a subscription, the client host gets access to every repository of the subscription that have been published to the Content View of the environment the client host belongs to.

List Enabled Repositories

You can list the repositories that are already enabled as follows:

sudo subscription-manager repos --list-enabled

you can install or update the software provided by the enabled repositories using yum or dnf.

List Disabled Repositories

The software you need sometimes is provided by disabled repositories: this means that unless you enable them you cannot install it using yum or dnf.

As an example, let's pretend that we need to install the "katello-agent" RPM package but yum or dnf complains that the package does not exists: let's get the list of the disabled repositories:

sudo subscription-manager repos --list-disabled

the output is as follows:

+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: Carcano_CH_CentOS_Server_Katello_Tools_6_6_for_CentOS8_Server_RPMs_x86_64
Repo Name: Katello Tools 6.6 for CentOS8 Server RPMs x86_64
Repo URL: https://sat-ci-up3a002.mgmt.carcano.local/pulp/repos/Carcano_CH/Lab/CentOS_8/custom/CentOS_Server/Katello_Tools_6_6_for_CentOS8_Server_RPMs_x86_64
Enabled: 0

From the name of the repository we can guess that it is very likely that it is the one that provides the "katello-agent" RPM package. We just need to enable it.

Enable A Repository

Let's enable the repository as follows:

sudo subscription-manager repos \
--enable Carcano_CH_CentOS_Server_Katello_Tools_6_6_for_CentOS8_Server_RPMs_x86_64

we can now install the "katello-agent" RPM package using yum or dnf.

Disable A Repository

Same way, we can easily disable a repository:

sudo subscription-manager repos \
--disable Carcano_CH_CentOS_Server_Katello_Tools_6_6_for_CentOS8_Server_RPMs_x86_64

this causes the software provided by that repository not to be installable either updatable using yum or dnf until we enable the repository again.

Disable The Old Online YUM Repositories

Once attached to subscriptions provided by the Satellite, when dealing with non Red-Hat distributions, such as CentOS, you wind up with duplicated repositories: the online ones and the ones from the Satellite.

Since the online ones are not needed anymore, you can easily disable them using yum-config-manager.

if you are using CentOS7 or older, type the following command::

sudo yum-config-manager --disable base updates extras

otherwise, type this command:

sudo yum-config-manager --disable appstream baseos extras

Remote Execution

As we have already seen, subscription-manager can only send information about installed packages to the Satellite or pull the client profile to see if there are any modification to the subscriptions, but besides this it cannot do anything else: subscription-manager cannot execute even simple commands such as the ones necessary to install, update or remove packages.

Executing commands can be done basically on two different models:

• push-based: the Satellite connects to the client host and executes commands
• pull-based: the client host connects to the Satellite looking for pending commands to execute

On Foreman, remote execution is provided by the remote execution plugin that is generally enabled by default, so usually it is necessary to enable it only on capsule servers.

If you want to enable it, either on a capsule server or on the Satellite itself if for any reason it is still disabled, simply login to the capsule or to the Satellite server that needs to be reconfigured and reconfigure foreman with the following command:

sudo foreman-installer --enable-foreman-plugin-remote-execution

the Satellite or capsule configuration (or reconfiguration) starts as follows:

Installing             Package[ca-certificates]                           [13%] [.........         ]

in the end you should get something as in the following snippet:

Installing             Done                                               [100%] [...........................................................................]
  Success!
  * Katello is running at https://sat-ci-up3a002.mgmt.carcano.local
  * To install an additional Foreman proxy on separate machine continue by running:

      foreman-proxy-certs-generate --foreman-proxy-fqdn "$FOREMAN_PROXY" --certs-tar "/root/$FOREMAN_PROXY-certs.tar"
  The full log is at /var/log/foreman-installer/katello.log

Katello Agent (Deprecated)

Katello initially (a euphemism - it has been like this for many years) provided only the pull-based model through the katello-agent RPM package: this package installs and sets-up goferd (the pulp2 agent) on the client host.

The agent is then exploited to enable package actions such as install, update or remove in a pull-based model.

Although this is not necessary neither fostered, for the sake of completeness this is the command to use if you want to install it:

sudo yum install -y katello-agent

Remote Execution With SSH

As you can easily infer, conversely from katello-agent, remote execution using SSH does not require having any agent installed on the client host, since the Satellite simply connects via SSH and executes the remote commands.

Remote execution with SSH provided by the remote execution ssh plugin.

Installing the plugin

 The foreman-installer options necessary to enable it are:

• --enable-foreman-proxy-plugin-remote-execution-ssh
• --foreman-proxy-plugin-remote-execution-ssh-install-key=true

If the remote execution plugin have already been configured,  the command to enable the remote execution ssh plugin too is as follows:

sudo foreman-installer --enable-foreman-proxy-plugin-remote-execution-ssh \
--foreman-proxy-plugin-remote-execution-ssh-install-key=true

the Satellite or capsule configuration (or reconfiguration) starts as follows:

Installing             Package[ca-certificates]                           [13%] [.........         ]

in the end you should get something as in the following snippet:

Installing             Done                                               [100%] [...........................................................................]
  Success!
  * Katello is running at https://sat-ci-up3a002.mgmt.carcano.local
  * To install an additional Foreman proxy on separate machine continue by running:

      foreman-proxy-certs-generate --foreman-proxy-fqdn "$FOREMAN_PROXY" --certs-tar "/root/$FOREMAN_PROXY-certs.tar"
  The full log is at /var/log/foreman-installer/katello.log

Granting SSH Login To The Clients

By default Satellite executes remote commands connecting to the client hosts as the root user. This means that it is necessary to install the public key of the foreman-proxy user of the Satellite server among the authorized keys of the root user on the client host.
To do so, login to the client and switch to the root user:

sudo su -

create the ".ssh" directory (if it does not already exist):

[ -d .ssh ] || mkdir -m 700 .ssh

add the public key to the list of the authorized keys - we can directly fetch it from the Satellite using curl as follows:

curl https://sat-ci-up3a002.mgmt.carcano.local:9090/ssh/pubkey >> ~/.ssh/authorized_keys

if the authorized_key file has just been created, fix its permissions as follows:

chmod 0600 ~/.ssh/authorized_keys

Testing the Remote SSH Execution

We should of course test that everything is properly set up as follows.

Login to the Satellite server and open a shell as foreman-proxy user:

sudo -u foreman-proxy -s /bin/bash

try to SSH connect to the client host:

ssh -i ~/.ssh/id_rsa_foreman_proxy -o StrictHostKeyChecking=no root@srv-ci-up3a002.prod.carcano.local

if everything is properly working, we must be able to connect.

Job Templates

Satellite lets define Job Templates: these are Embedded Ruby (ERB) template files that are processed to generate a "Job" containing the actual logic to run. This enables you to derive from a Job Template almost any kind of statement files, such as shell scripts or even Ansible playbooks indeed: it is the Satellite that takes care of generating and running the resulting statement file on the client hosts.

They are a very handy and powerful tool, since we can even define input parameters such as textboxes, drop-downs, checkboxes and such: they are rendered by the Satellite Web UI while their values are stored within ERB variables.

When connected to the Satellite Web UI as a user with administrative rights, we can can easily list the existing Job Templates of the currently selected Organization by clicking onto:

• "Hosts"
• "Job Templates"

A table with the list of the available Job Templates is shown:

As you can see from the above list, the Satellite provides a small set of pre-configured Job Templates for common tasks such as installing RPM packages or errata, puppet modules, enabling or disabling services and so on.

Running A Job Template On A Client Host

Let's see how easy is running Job Templates on client hosts using the Satellite Web UI: in this example we run the "Package Action - SSH Default" Job template to install the "rng-tools" RPM package: just switch to the "All Hosts" listing page as follows:

• "Hosts"
• "All Hosts"

This page lists every client host you have registered on the Satellite providing an overview of the installed operating system, the host group they belong to, the Puppet Environment and the last time the client host has submitted a report with its facts.

If you have many hosts, it is useful to learn how to filter them so to get a shorter list: you can even select just one client host, as by shown in the following screenshot:

click on the FQDN of the host - in this example I click on "srv-ci-up3a002.mgmt.carcano.local": a page like the following thumbnails is shown:

as you see it  provides a summary of some of the most interesting collected metrics along with several buttons to perform actions on this client host.

Note how the Status is "Warning" because of "Non-security errata applicable".

Click on the "Schedule Remote Job" button and fill-in the form as follows:

select "Packages" as the Job category and the "Package Action - SSH Default" Job Template". Type "rng-tools" in the package, and choose "install" as action, then click on "Submit" to schedule the job for immediate execution.

The job is queued, started and the execution summary is shown: the following screenshot show the outcome of the successfully terminated job:  

you may want to see the console output: just click on the FQDN - in this case "srv-ci-up3a002.mgmt.carcano.local".

This is the output of a successful execution of the yum install command triggered by the "Package Action - SSH Default" Job Template on the client host.

Footnotes

Here it ends this tutorial on registering a client host to Red Hat Network Satellite Server 6 or Katello. We learned together how to operate a subscription-manager and all the things that are necessary to know to troubleshoot if anything would go wrong. We also learned how to create product certificates for our own products and how the Satellite implements remote execution on the client hosts. In addition to that, we learned how to enable and configure SSH remote actions that can be exploited to  manage the client hosts.

Satellite Server 6 and Katello are a huge step onward from Satellite Server 5 and Spacewalk, ... I think that using them is really worth the effort.