The architectural deployment of automation frameworks within an enterprise Linux environment requires a precise understanding of package management, repository orchestration, and system-level dependencies. In the context of Red Hat Enterprise Linux (RHEL) 8, the transition and maintenance of Ansible 2.9 represent a critical phase in infrastructure automation. This specific version of the Ansible engine serves as a bridge between legacy automation patterns and the modern, modular approach introduced in later iterations of Ansible Core. Implementing Ansible 2.9 on x86_64 architecture involves navigating the complexities of Red Hat's subscription model, the nuances of the AppStream repository, and the necessity of manual intervention when air-gapped or restricted network environments preclude the use of standard package managers.
The deployment of Ansible 2.9 is not merely a matter of executing an installation command but involves a holistic configuration of the control node and managed nodes. This includes the establishment of secure communication channels via SSH, the configuration of sudoers for privileged execution, and the management of specific Python dependencies that ensure the stability of the Ansible runtime. As the ecosystem evolved toward RHEL 9, the availability of Ansible 2.9 became limited, necessitating a strategic approach to its installation on RHEL 8 to ensure long-term operational stability.
Red Hat Satellite 6 Repository Orchestration via Hammer
For organizations utilizing Red Hat Satellite 6 for centralized content management, the enablement of the Ansible 2.9 repository is performed through the hammer command-line interface. This process ensures that the correct software channels are synchronized from the Red Hat Customer Portal to the local Satellite server and subsequently delivered to the client systems.
The process begins with the identification of the correct repository set. The administrator must first determine the organization ID to ensure the repository is enabled for the correct tenant.
- Identify the organization:
hammer organization list
Once the organization ID (represented as X in the following commands) is identified, the administrator must search for the specific Ansible Engine 2.9 repository set to verify its availability and exact naming convention.
- Search for the repository:
hammer repository-set list --search 'Ansible Engine 2.9' --organization-id X
After confirming the repository's existence, the specific enablement command must be executed. The naming convention differs based on the target OS version. For RHEL 8 x8664 systems, the specific repository to be enabled is "Red Hat Ansible Engine 2.9 for RHEL 8 x8664 (RPMs)".
- Enable the RHEL 8 repository:
hammer repository-set enable --name 'Red Hat Ansible Engine 2.9 for RHEL 8 x86_64 (RPMs)' --basearch x86_64 --organization-id X
In scenarios where legacy RHEL 7 servers are also present in the environment, a separate command is required to enable the corresponding repository:
hammer repository-set enable --name 'Red Hat Ansible Engine 2.9 RPMs for Red Hat Enterprise Linux 7 Server' --basearch x86_64 --organization-id X
The technical requirement for this process is the correct mapping of the basearch to x86_64 and the accurate association of the organization-id. The real-world impact is the ability to centrally manage software updates across thousands of nodes without requiring each node to have direct internet access. This creates a dense web of dependency management where the Satellite server acts as the single source of truth for the Ansible 2.9 binaries.
Standard Installation Procedures via YUM and Subscription Manager
For standalone RHEL 8 systems with direct access to Red Hat's infrastructure, the installation follows a streamlined path using the Yellowdog Updater, Modified (yum) or the newer dnf package manager.
The prerequisite for any installation is the verification of the current system release and the status of the available repositories. The following sequence is utilized to prepare the system:
Verify the release:
cat /etc/redhat-releaseAudit available repositories for Ansible:
yum repolist all | grep ansible
To enable the specific repository required for the 2.9 engine, the yum-config-manager tool is employed. This tool is part of the yum-utils package, which must be installed first to provide the necessary functionality for managing repository configurations.
Install utility tools:
yum install yum-utilsEnable the Ansible 2.9 repository:
yum-config-manager --enable ansible-2.9-for-rhel-8-x86_64-rpmsConfirm repository enablement:
yum repolist enabled
Once the repository is active and recognized by the system, the installation of the Ansible package is executed.
Install Ansible:
yum install -y ansibleVerify the installation:
ansible --version
The technical layer of this process involves the yum-config-manager modifying the .repo files located in /etc/yum.repos.d/, switching the enabled flag from 0 to 1. The consequence for the user is a seamless transition from a clean RHEL 8 install to a fully functional automation control node.
Manual Upgrade Paths and Air-Gapped Strategies
In enterprise environments, there are frequently scenarios where systems are disconnected from the Red Hat Subscription Manager or lack internet access, rendering yum or dnf commands ineffective for remote repository fetching. This is a common challenge for users attempting to upgrade from version 2.9.10 to 2.9.11 or 2.9.12.
Local RPM Installation
When the subscription-manager is unavailable and the system cannot reach external repositories, the only viable path is the manual installation of the .rpm package. If a user has downloaded a package such as ansible-2.9.11-1.el8.noarch.rpm, the upgrade must be performed locally.
The standard upgrade command for a local file is as follows:
sudo rpm -Uvh ansible-2.9.11-1.el8.noarch.rpm
Proxy Configuration for PIP
If a system is not connected to a subscription manager but does have access to the internet via a proxy, the Python Package Index (PIP) serves as an alternative installation vector. This requires the configuration of the proxy settings on the RHEL 8 node to allow the pip command to reach the PyPI repositories.
Dependency Resolution: libmodulemd
A critical technical hurdle during the manual installation of Ansible on RHEL 8 is the requirement for libmodulemd. If the installation fails due to missing dependencies, the user must search for the specific library and its Python bindings.
Search for the library:
yum search libmodulemdSearch for Python bindings:
yum search python3-libmodulemdInstall the required RPM:
yum install rpm file(Referring to the specific package identified in the search)
The impact of missing libmodulemd is a complete failure of the Ansible installation process, as the engine relies on these modules to interact with the RHEL 8 application stream and module system.
Control Node and Managed Node Configuration
Installing the software is only the first step; the environment must be configured to allow the Ansible engine to communicate with the target hosts. This involves a strict set of administrative steps on both the control node and all managed nodes.
User Account Setup
A dedicated ansible user should be created to avoid using the root account for automation, adhering to the principle of least privilege.
Create the user:
useradd -m ansibleSet the password:
passwd ansibleConfigure passwordless sudo:
echo "ansible ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
The addition of the user to the sudoers file with NOPASSWD is a technical requirement for Ansible to execute tasks that require root privileges (such as installing packages or modifying system files) without prompting for a password during the playbook run.
SSH Key Orchestration
Ansible relies on SSH for transport. To achieve non-interactive authentication, SSH keys must be generated on the control node and distributed to the managed nodes.
Generate the key pair (on the control node as the
ansibleuser):ssh-keygenCopy the key to the managed nodes:
ssh-copy-id [email protected]ssh-copy-id [email protected]Test the connection:
ssh [email protected]
SSH Daemon Configuration
For security and accessibility, the SSH configuration on the managed nodes may need to be modified to explicitly allow the ansible user.
Edit the SSH configuration:
sudo nano /etc/ssh/sshd_configAdd the following line:
AllowUsers ansible
Ansible Environment Structure and First Playbook
Once the connectivity is established, the directory structure for the automation project must be created.
Inventory and Directory Setup
The administrator should create a dedicated space for playbooks and define the host groups in an inventory file.
Create the playbook directory:
mkdir /home/ansible/playscd /home/ansible/playsCreate the inventory file (
myhosts):sudo nano myhosts
The inventory file should be structured as follows: ```text [fileservers] 192.168.1.151
[webservers] 192.168.1.130 ```
Developing the Initial Playbook
To verify the installation and the connectivity, a basic playbook is created. This playbook demonstrates the file module to create a configuration file on the remote targets.
- Create the playbook:
sudo nano first-play-book.yml
The playbook content:
```yaml
- name: first play
hosts: all
tasks:
- name: create a new file file: path: /tmp/wow.conf mode: 0664 owner: ansible state: touch ```
Transition to Ansible Core and RHEL 9 Implications
As the environment evolves, it is important to note the shift from the full "Ansible" package to "Ansible Core". In RHEL 9, the support for Ansible Engine 2.9 has been deprecated.
Ansible Core Integration
For those experiencing issues where python3 and the standard ansible package are not working in tandem, the installation of ansible-core is recommended.
Install Ansible Core:
sudo yum -y install ansible-core --allowerasingVerify the version:
ansible --version(Example output:ansible [core 2.16.3])
The technical transition to ansible-core involves a reduced footprint, focusing only on the essential engine without the massive collection of community modules bundled in the 2.9 release. The real-world consequence is that playbooks previously running on Ansible Engine 2.9 may generate error messages regarding missing plugins or modules. This necessitates a move toward "Collections," where specific modules are installed independently.
Technical Specification Summary
The following table provides a comprehensive comparison of the installation and management methods discussed.
| Method | Connectivity Required | Tool Used | Primary Use Case | Requirement |
|---|---|---|---|---|
| Satellite 6 | Internal Network | hammer |
Enterprise Centralized Mgmt | Organization ID |
| Standard YUM | Internet/Repo Access | yum-config-manager |
Standalone RHEL 8 Nodes | Subscription |
| Manual RPM | None (Local File) | rpm |
Air-gapped / No Subscription | Local .rpm file |
| PIP | Proxy Access | pip |
Python-based install | Proxy Config |
| Ansible Core | Internet/Repo Access | yum |
RHEL 9 or Modern RHEL 8 | AppStream Repo |
Conclusion
The deployment of Ansible 2.9 on RHEL 8 x86_64 is a multifaceted process that requires a deep understanding of both the Red Hat ecosystem and the Ansible architecture. Whether utilizing the hammer CLI for Satellite orchestration, the yum-config-manager for standard installations, or manual RPM updates for air-gapped systems, the priority remains the stability of the Python environment and the correct resolution of dependencies like libmodulemd.
The transition from Ansible 2.9 to Ansible Core represents a fundamental shift in how automation is delivered. While 2.9 provided a "batteries-included" experience, the move toward Core emphasizes modularity and a limited scope of support within RHEL. For administrators, this means that the strategy for managing RHEL 8 must account for the eventual migration to RHEL 9, where the 2.9 engine is no longer available. Ensuring that the ansible user is correctly configured with passwordless sudo and that SSH keys are securely distributed is the foundation upon which all subsequent automation is built. The ability to pivot between installation methods—from Satellite-driven to manual RPMs—ensures that the automation framework can be deployed regardless of the network constraints of the environment.