Before patching a RHEL fleet with Satellite, check three things: that each host is registered to a content view environment, that the repositories are synchronised and that the host supports remote execution. With those in place, Satellite works out which errata are applicable and installable, and you apply them through the web UI or with hammer. AAP comes in afterwards: it takes the Satellite hosts as its inventory and orchestrates what surrounds the patch. This list summarises what to check at each point according to the Red Hat Satellite 6.18 and Ansible Automation Platform 2.6 documentation.
The pieces involved
| Piece | What it does for patching |
|---|---|
| Synchronised repositories | Bring the latest Red Hat errata into Satellite. |
| Content view and lifecycle environment | Set which errata each host can install. |
| Remote execution | Launches the installation job on the hosts. |
| AAP inventory with a Satellite credential | Gives AAP the list of hosts Satellite manages. |
First, look at the Satellite lifecycle: the policy is N-2, where N is the latest minor version, and N-2 is supported only while that version remains supported. An orderly patch run starts by knowing which Satellite version you are on.
1. Requirements for each host
According to the Satellite 6.18 documentation, the following must hold before installing errata:
- The Satellite Server repositories are synchronised with the latest Red Hat errata.
- The host is registered to a content view environment.
- The host is configured for remote execution.
- The errata are installable: only those in the host's content view environment can be installed.
Hosts also need the Red Hat Satellite Client 6 package set, which includes katello-host-tools and its dependencies, according to the patching best practices.
2. Applicable versus installable errata
In the web UI, each host's errata card (Hosts > All Hosts, Overview tab) shows two lists. Applicable shows the errata that affect installed packages; Installable shows the applicable ones that are available in the host's content view environment. You can filter them by security advisories, bug fixes and enhancements.
On the command line, the documentation uses:
hammer erratum list --organization "My_Organization"
The command accepts --errata-restrict-applicable and --errata-restrict-installable to filter the output.
If an erratum is applicable but not installable, the documentation says to update the content view incrementally and promote it to the host's lifecycle environment. After that, the erratum becomes installable. Check how many errata are in that situation before planning the window: it is the difference between what affects your hosts and what you can actually install.
3. How they are installed
The Satellite 6.18 documentation describes two routes. Through the web UI: Content > Content Types > Errata, choose the erratum, select the hosts on the Content Hosts tab and click Apply to Hosts and then Confirm. You check the result in Monitor > Jobs, where the latest Install errata job should have finished successfully on all hosts.
With hammer, through remote execution, the documentation shows this example:
hammer job-invocation create \
--feature katello_errata_install \
--inputs errata=ERRATUM_ID_1,ERRATUM_ID_2 \
--search-query "name = host.example.com"
To act on a host collection, the query is "host_collection = Collection_Name". For all hosts where an erratum is applicable, "applicable_errata = ERRATUM_ID". To follow the result, use hammer task list and hammer task progress --id TASK_ID.
4. Patching in batches
For bulk actions, Red Hat's guide recommends grouping hosts by operating system major version and choosing the "via remote execution – customize first" option, which lets you decide when patches are applied. It also notes that errata cannot be applied to packages that are not in the Satellite repositories or in the host's content view environments.
Before the first window, decide the order of the batches, who validates each one and what condition stops the next.
5. Connecting AAP to Satellite
AAP 2.6 has the Red Hat Satellite 6 credential type, which lets you synchronise the inventory with Satellite. It asks for the Satellite URL, a username and a password. With that credential you create an inventory source and synchronise it, so AAP knows the same hosts as Satellite.
Check which Satellite user that credential uses and what permissions it has: it only needs to read the inventory AAP is going to manage.
6. What AAP adds to patching
Satellite already installs errata through remote execution. AAP can take care of what surrounds the patch, such as pre- and post-checks, if you define them in a job template or a workflow. Before automating them, write down what you would check by hand on each host before and after the patch: that list is the starting point for the template.
Where a review can help
If you want a priority order for your fleet, the RHEL and AAP lifecycle review covers versions, support dates, patching status and playbooks.