Ansible Tower on RHEL 8 requires Ansible 2.8 or greater. Older versions of Ansible will not work on RHEL 8.
If you need to access a HTTP proxy to install software from your OS vendor, ensure that the environment variable “HTTP_PROXY” is set accordingly before running setup.sh.
The Tower installer creates a self-signed SSL certificate and keyfile at /etc/tower/tower.cert and /etc/tower/tower.key for HTTPS communication. These can be replaced after install with your own custom SSL certificates if you desire, but the filenames are required to be the same.
If using Ansible version 1.8 or later, ensure that fact caching using Redis is not enabled in ansible.cfg on the Tower machine.
Note that the Tower installation must be run from an internet connected machine that can install software from trusted 3rd-party places such as Ansible’s software repository, and your OS vendor’s software repositories. In some cases, access to the Python Package Index (PyPI) is necessary as well. If you need to be able to install in a disconnected environment and the bundled installation program is not a solution for you (refer to Using the Bundled Tower Installation Program), please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
If installing Tower on OpenShift, refer to OpenShift Deployment and Configuration.
Flags and/or extra variables that you can use with the Ansible Tower installer include (but are not limited to) the following:
Usage: setup.sh [Options] [-- Ansible Options]
Options:
-i INVENTORY_FILE Path to ansible inventory file (default: ${INVENTORY_FILE})
-e EXTRA_VARS Set additional ansible variables as key=value or YAML/JSON
i.e. -e bundle_install=false will force an online install
-b Perform a database backup in lieu of installing.
-r Perform a database restore in lieu of installing.
-h Show this help message and exit
Ansible Options:
Additional options to be passed to ansible-playbook can be added following the -- separator.
Use the -- separator to add any Ansible arguments you wish to apply. For example: ./setup.sh -i my_awesome_inventory.yml -e matburt_is_awesome=True -- -K
The following are examples of common scenarios - be sure to supply your own values appropriate to your specific case.
To upgrade core:
./setup.sh -e upgrade_ansible_with_tower=1
To disable https handling at nginx:
./setup.sh -e nginx_disable_https=true
To specify a non-default path when restoring from a backup file:
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
To override an inventory file used by passing it as an argument to the setup script:
setup.sh -i <inventory file>
Tower 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. If you intend to run the Tower installer from a FIPS-enabled system, you’ll need to pre-compute an md5 hash yourself at install time and add its value to the inventory file described in Setting up the Inventory File.
Specifically, you must pre-compute the hashed value on a system without FIPS enabled:
$ python -c 'from hashlib import md5; print("md5" + md5("choose-a-password" + "awx").hexdigest())'
md57d08dde7e95e862eaadfff09565e92e6
…and specify both pg_password and pg_hashed_password in your inventory file:
pg_password='choose-a-password'
pg_hashed_password='md57d08dde7e95e862eaadfff09565e92e6'
The “awx” implies the Postgres username. If you have an alternative username, provide that rather than “awx”.
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.
In order for Ansible Tower to run on RHEL 8, Ansible 2.8 or greater must be installed. Ansible 2.8 and greater are supported versions for RHEL 8.
Starting with Ansible Tower 3.5, Tower runs with Python 3, which is automatically installed on RHEL 8 when installing Tower.
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 Tower Installation Program 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.
Ubuntu support is deprecated in Ansible Tower 3.5, and will be removed in a future release. Refer to previous versions of the Ansible Tower Installation and Reference Guide for details on Ubuntu.
For OpenShift-based deployments, refer to OpenShift Deployment and Configuration.