Preparing for RHEL Extended Life Cycle Support with Red Hat Satellite and the Ansible Automation Platform

Red Hat Enterprise Linux (RHEL) 6 was introduced more than 10 years ago, on November 9, 2010. Originally branched from Fedora 12, RHEL 6 has spent the last 10 years faithfully running Linux workloads. After more than a decade of faithful service, RHEL 6’s lifespan is nearly up: on November 30th, RHEL 6 will move out of Maintenance Support 2 and into Extended Life Phase. 

Red Hat offers the Extended Life Cycle Support (ELS) add-on (available through June 30, 2024) for those customers who need extra migration time. Red Hat Enterprise Linux 6 ELS delivers certain Red Hat defined Critical and Important security fixes and selected (at Red Hat discretion) urgent priority bug fixes and troubleshooting for the last minor release.

Today, we’ll walk through how to prepare our Red Hat Satellite server for the switch of RHEL 6 to RHEL 6 ELS, as well as adjusting our currently registered systems. We’ll be doing both of these things via Ansible and the newly introduced redhat.satellite Ansible Collection.

Setting Up Ansible Tower

Before we start writing some Ansible, there are two pieces we’ll want to configure: a virtual environment for our Satellite jobs with the necessary Python libraries, and a custom credential type to feed environment variables to the modules contained in the redhat.satellite Collection.

The redhat.satellite Collection requires the apypie Python library which can be installed using pip. Here we're going to set up a custom Python virtual environment and installing apypie into it, as that's how we did this for writing this post. (Another way to do this would be to stand up a new RHEL 7 VM and install the python2-apypie RPM and work from there.)

Let’s set up a virtual environment:

[root@tower01 ~]# sudo pip3 install virtualenv
...
Installing collected packages: zipp, importlib-metadata, filelock, distlib, appdirs, importlib-resources, virtualenv
Successfully installed appdirs-1.4.4 distlib-0.3.1 filelock-3.0.12 importlib-metadata-2.0.0 importlib-resources-3.3.0 virtualenv-20.1.0 zipp-3.4.0
[root@tower01 ~]# mkdir /opt/custom-virtualenvs
[root@tower01 ~]# chmod 0755 /opt/custom-virtualenvs
[root@tower01 ~]# virtualenv /opt/custom-virtualenvs/satellite
created virtual environment CPython3.6.8.final.0-64 in 836ms
  creator CPython3Posix(dest=/opt/custom-virtualenvs/satellite, clear=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv)
    added seed packages: pip==20.2.4, setuptools==50.3.2, wheel==0.35.1
  activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator           
[root@tower01 ~]# python3 -m venv /opt/custom-virtualenvs/satellite
[root@tower01 ~]# /opt/custom-virtualenvs/satellite/bin/pip install -U apypie ansible==2.9.15
...
Successfully installed apypie-0.3.1 certifi-2020.11.8 chardet-3.0.4 idna-2.10 requests-2.24.0 urllib3-1.25.11

Note: python3-devel and gcc may be needed on your system to correctly install psutil and Ansible in the virtualenv. The psutil package is a base dependency for Ansible.

Let’s configure Ansible Tower to pick up virtualenvs automatically in the directory we created:

Now, let’s set up a custom credential type that we can use to securely store some connection information for our satellite. First, we’ll define our input configuration:

fields:
  - id: satellite_username
    type: string
    label: Satellite Username
  - id: satellite_password
    type: string
    label: Satellite Password
    secret: true
  - id: validate_satellite_certificate
    type: string
    label: Validate Satellite Certificate
    choices:
      - 'yes'
      - 'no'
  - id: satellite_url
    type: string
    label: Satellite URL
required:
  - satellite_username
  - satellite_password
  - validate_satellite_certificate
  - satellite_url

Now we need to take these inputs and have tower inject them as environment variables with the following injector configuration:

env:
  FOREMAN_USERNAME: '{{ satellite_username }}'
  FOREMAN_PASSWORD: '{{ satellite_password }}'
  FOREMAN_SERVER_URL: '{{ satellite_url }}'
  FOREMAN_VALIDATE_CERTS: '{{ validate_satellite_certificate }}'

Once saved, we can now set up a credential for our Satellite, and Tower will keep our credentials secure.

Finally, don’t forget to set Ansible Automation Hub as your primary Ansible content  server for Tower. We’ll be setting up a requirements.yml later on, so Tower will download the collection automatically.

Adding ELS Subscriptions to a Red Hat Satellite manifest

Note: If you already have ELS subscriptions in your manifest, skip this section. If you need to purchase ELS subscriptions, reach out to your Red Hat account team.

First, we’ll add the appropriate Extended Life Cycle Subscriptions to our Red Hat Satellite Manifest. In the subscription allocation section of the customer portal, let’s select our Satellite manifest:

Once we’re editing the Satellite manifest, let’s select add in the right corner and search for ‘Extended’ to view only our Extended Life Cycle Support subscriptions:

After adding a few entitlements of the appropriate subscription to our manifest, we can refresh our manifest within satellite under Content -> Subscriptions -> Manage Manifest:

Once the manifest refresh completes, we’re ready to enable the ELS repositories.

Enabling and Syncing RHEL6 ELS Repositories

Here’s where we’ll start using Ansible instead of the Satellite WebUI. Instead of manually enabling the repositories via Satellite’s WebUI, let’s leverage Ansible and the redhat.satellite Ansible Collection. Let’s start with a quick inventory file:

[satellite]
demo-satellite01.josh.lab.msp.redhat.com

Now let’s set up a requirements.yml file with the redhat.satellite Ansible Collection specified so Tower will automatically grab the Collection for us:

---
collections:
  - redhat.satellite

Time for our playbook. To start, let’s just enable the RHEL 6 ELS repository via the redhat.satellite Collection:

---

- name: configure satellite 6 with rhel6 els content
  hosts:
    - satellite
  gather_facts: false
  tasks:
    - name: configure satellite 6 via the redhat.satellite collection
      block:
        - name: enable the rhel6 els repo
          redhat.satellite.repository_set:
            organization: josh-demo
            name: Red Hat Enterprise Linux 6 Server - Extended Life Cycle Support (RPMs)
            product: Red Hat Enterprise Linux Server - Extended Life Cycle Support
            repositories:
              - basearch: x86_64
      delegate_to: localhost

Let’s take a second to call out a few things in this playbook. First, since the modules in the redhat.satellite Ansible Collection leverage the satellite API, I’ve set up a block with delegate_to: localhost to ensure our Ansible control node does the actual API calls. In addition, we won’t need to log directly into the system.

Another thing to notice: the modules do have options for username, password, etc., however we don’t have to define them in our playbook. According to the module documentation:

If the value is not specified in the task, the value of environment variable FOREMAN_SERVER_URL will be used instead.

Since our custom credential injects environment variables, we’re all set as soon as we create a new credential with our custom credential type:

Now let’s tie this all together with a job template:

After the job runs, we can see one change against our Satellite server:

Within the satellite UI, we can confirm the RHEL6 ELS repo is now enabled:

Now we need to sync that repo. Let’s add a task to our playbook:

        - name: sync the rhel6 els repo
          redhat.satellite.repository_sync:
            organization: josh-demo
            repository: Red Hat Enterprise Linux 6 Server - Extended Life Cycle Support (RPMs)
            product: Red Hat Enterprise Linux Server - Extended Life Cycle Support

After we sync the new code into tower and kick off the job, Satellite will start syncing the RHEL 6 ELS repo:

And our Ansible Tower job will finish denoting the repo sync as a change:

To speed up the process, let’s add a conditional on the repository sync:

        - name: enable the rhel6 els repo
         ...
          register: repo_enabled
        - name: sync the rhel6 els repo
          when:
            - repo_enabled.changed

Modifying Content Views with the New Content

First, let’s create a new content view for our RHEL 6 ELS content and publish it. Again, no need for the web interface, let’s add two tasks to our playbook:

       - name: create rhel6 els content view
          redhat.satellite.content_view:
            organization: josh-demo
            name: cv-els-rhel6
            repositories:
              - name: Red Hat Enterprise Linux 6 Server - Extended Life Cycle Support RPMs x86_64
                product: Red Hat Enterprise Linux Server - Extended Life Cycle Support
          register: content_view_created
        - name: publish rhel6 els content view
          redhat.satellite.content_view_version:
            organization: josh-demo
            content_view: cv-els-rhel6
            version: 1.0
          when: content_view_created.changed

Once the tower job completes, we’ll have our new content view in Satellite:

One of the benefits of composite content views is the ability to update certain content without impacting other content. This Satellite server has a composite content view called composite-rhel6 we’ll add our new content view to, and since we’re not updating the other component content views, we’re safe to add this new content. Let’s add two more tasks to update the composite content view and publish a new version to a lower life cycle environment:

       - name: update composite content view
          redhat.satellite.content_view:
            organization: josh-demo
            content_view: composite-rhel6
            composite: true
            components:
              - content_view: cv-server-rhel6
                latest: true
              - content_view: cv-satellitetools6.8-rhel6
                latest: true
              - content_view: cv-els-rhel6
                latest: true
          register: composite_updated
        - name: publish new version of the composite content view
          redhat.satellite.content_view_version:
            organization: josh-demo
            name: composite-rhel6
            lifecycle_environments:
              - Library
              - sandbox
          when:
            - composite_updated.changed

Once complete, we have a new version of the composite content view that’s been promoted to a life cycle environment:

Creating ELS Activation Keys

Now that we have our content and content views, let’s create an activation key that can be used to register new RHEL6 systems to Satellite and automatically enable the ELS repos. Back to our playbook:

       - name: create rhel6 els activation key
          redhat.satellite.activation_key:
            organization: josh-demo
            lifecycle_environment: development
            name: rhel6-els-development
            content_view: composite-rhel6
            content_overrides:
              - label: rhel-6-server-els-rpms
                override: enabled
            release_version: 6Server

Within Satellite we can see our new activation key and the ELS repository set to enabled (overridden).

Switching Registered Hosts over to the ELS Repositories

Finally, we can leverage Ansible to migrate our existing RHEL 6 systems over to the ELS repository. Let’s create a new playbook:

---

- name: switch to els repos
  hosts:
    - rhel6
  gather_facts: false
  tasks:
    - name: disable normal rhel6 server repo
      rhsm_repository:
        name: rhel-6-server-rpms
        state: disabled
    - name: enable rhel6 els repo
      rhsm_repository:
        name: rhel-6-server-els-rpms
        state: enabled

After running our new playbook through tower, our RHEL 6 systems will now be consuming the rhel6 ELS repo:

[root@rhel6els01 ~]# yum repolist

Loaded plugins: enabled_repos_upload, package_upload, product-id, search-disabled-repos, security, subscription-manager

rhel-6-server-els-rpms     rhel-6-server-satellite-tools-6.8-rpms

Conclusion

The combination of products from Red Hat working together greatly enhances the overall capabilities and user experience available to our customers. By leveraging the strengths of the products, we’ve created an automated and repeatable process to manage our RHEL 6 ELS systems, as well as set ourselves up for future enhancements and steps along the management journey.

Extended Life Cycle Support maintenance ends on June 30, 2024. Your Red Hat subscription gives you continuous access to active versions of the Red Hat software in both binary and source form, including security updates and bug fixes. We strongly recommend that you take full advantage of your subscription services and upgrade to Red Hat Enterprise Linux 7 or 8, which contain compelling new features, enablement for modern hardware platforms and ISV applications.

Editor's note: Blog updated for clarity about ELS on 8 December 2020.