1. Preparing for the Ansible Automation Platform Installation¶

1.2.1.1. Notable PostgreSQL Changes¶

Automation Platform uses PostgreSQL 10, which is an SCL package on RHEL 7 and an app stream on RHEL8. Some changes worth noting when upgrading to PostgreSQL 10 are:

• PostgreSQL user passwords will now be hashed with SCRAM-SHA-256 secure hashing algorithm before storing in the database.

• You will no longer need to provide a pg_hashed_password in your inventory file at the time of installation because PostgreSQL 10 can now store the user’s password more securely. If users supply a password in the inventory file for the installer (pg_password), that password will be SCRAM-SHA-256 hashed by PostgreSQL as part of the installation process. DO NOT use special characters in pg_password as it may cause the setup to fail.

• Since Ansible Tower and Automation Hub are using a Software Collections version of PostgreSQL in 3.8, the rh-postgresql10 scl must be enabled in order to access the database. Administrators can use the awx-manage dbshell command, which will automatically enable the PostgreSQL SCL.

• If you just need to determine if your Tower instance has access to the database, you can do so with the command, awx-manage check_db.

1.2.1.2. PostgreSQL Configurations¶

Optionally, you can configure the PostgreSQL database as separate nodes that are not managed by the Automation Platform installer. When the Automation Platform installer manages the database server, it configures the server with defaults that are generally recommended for most workloads. However, you can adjust these PostgreSQL settings for standalone database server node where ansible_memtotal_mb is the total memory size of the database server:

max_connections == 1024
shared_buffers == ansible_memtotal_mb*0.3
work_mem == ansible_memtotal_mb*0.03
maintenance_work_mem == ansible_memtotal_mb*0.04

Refer to PostgreSQL documentation for more detail on tuning your PostgreSQL server.

1.2.3.1. Installing Automation Platform on Systems with FIPS Mode Enabled¶

Ansible Automation Platform can run on systems where FIPS mode is enabled, though there are a few limitations to keep in mind:

• Only Enterprise Linux 7+ is supported. The standard python that ships with RHEL must be used for Ansible Tower to work in FIPS mode. Using any non-standard, non-system python for Tower is therefore, unsupported.

• By default, Tower configures PostgreSQL using password-based authentication, and this process relies on the usage of md5 when CREATE USER is run at install time. To run the Tower installer from a FIPS-enabled system, specify pg_password in your inventory file. DO NOT use special characters in pg_password as it may cause the setup to fail:

  pg_password='choose-a-password'
  

  For further detail, see Setting up the Inventory File.

  If you supply a password in the inventory file for the installer (pg_password), that password will be SCRAM-SHA-256 hashed by PostgreSQL as part of the installation process.

• The ssh-keygen command generates keys in a format (RFC4716) which uses the md5 digest algorithm at some point in the process (as part of a transformation performed on the input passphrase). On a FIPS-enforcing system, md5 is completely disabled, so these types of encrypted SSH keys (RFC4716 private keys protected by a passphrase) will not be usable. When FIPS mode is enabled, any encrypted SSH key you import into Ansible Tower must be a PKCS8-formatted key. Existing AES128 keys can be converted to PKCS8 by running the following openssl command:

  $ openssl pkcs8 -topk8 -v2 aes128 -in <INPUT_KEY> -out <NEW_OUTPUT_KEY>
  

For more details, see: https://access.redhat.com/solutions/1519083

• Use of Ansible features that use the paramiko library will not be FIPS compliant. This includes setting ansible_connection=paramiko as a transport and using network modules that utilize the ncclient NETCONF library.

• The TACACS+ protocol uses md5 to obfuscate the content of authorization packets; TACACS+ Authentication is not supported for systems where FIPS mode is enabled.

• The RADIUS protocol uses md5 to encrypt passwords in Access-Request queries; RADIUS Authentication is not supported for systems where FIPS mode is enabled.

1.2.3.2. Notes for Red Hat Enterprise Linux and CentOS setups¶

• PackageKit can frequently interfere with the installation/update mechanism. Consider disabling or removing PackageKit if installed prior to running the setup process.

• Only the “targeted” SELinux policy is supported. The targeted policy can be set to disabled, permissive, or enforcing.

• When performing a bundled install, refer to Using the Bundled Ansible Automation Platform Installer for more information.

• When installing Ansible Tower, you only need to run setup.sh, any repositories needed by Tower are installed automatically.

• The latest version of Ansible is installed automatically during the setup process. No additional installation or configuration is required.

1.2.3.3. Notes for Ubuntu setups¶

Ansible Tower no longer supports Ubuntu. Refer to previous versions of the Ansible Automation Platform Installation and Reference Guide for details on Ubuntu.

1.2.3.4. Configuration and Installation on OpenShift¶

For OpenShift-based deployments, refer to OpenShift Deployment and Configuration.

1.2.3.5. Installing Satellite instances on Tower¶

Satellite users will need to install the Katello RPM for your Satellite instance on the Tower node prior to installing Tower. This RPM automatically configures Subscription Manager to use Satellite as its content source, and the hostname value gets updated in /etc/rhsm/rhsm.conf.