3. Known Issues¶

3.1. Installation failure related to MongoDB¶

During the releases of Tower 2.x, the upstream URL for the MongoDB repository changed. This change in the upstream URL caused installations to fail.

The Ansible Tower 2.4.5 release has been corrected to include the new upstream URL for MongoDB. For those that require MongoDB, use the latest version of the Tower 2.4.5 release. If MongoDB is not a requirement, consider upgrading to the latest version of Ansible Tower.

3.2. Upgrading to Ansible Tower 2.4.4¶

If you are considering an upgrade to Ansible Tower version 2.4.4, but you are not yet using Ansible version 2.0, please note that yum calls will not work from Tower. If you rely heavily on yum calls, but are not ready to upgrade Ansible to version 2.0, you should not upgrade Ansible Tower to the 2.4.4 version.

3.3. Running in FIPS mode¶

At this time, Tower does not support running when the operating system is configured to operate in FIPS mode.

3.4. Errors when editing objects¶

Ansible Tower implements a role based access control system. It may appear that you can edit objects that do not belong to you–like being able to pull up an edit dialog of your teammates, which you have been granted permission to view–but when you try to edit something, you will receive a 403 error and you cannot view any information you should not already have access to as defined in the system.

3.5. Host comparisons against a single host¶

When performing a host comparison against a single host, if there is only one (1) run for the selected date, Tower may display a message saying it could not find any scan job runs in one of the columns.

3.6. Host comparisons against two hosts¶

When performing a host comparison against two hosts, you can only select from a single page of hosts.

3.7. Live events status indicators¶

Live events status dots are either seen as a red or orange dot at the top of the Tower Dashboard when something goes wrong, or they are not seen at all to indicate a healthy system state. If you encounter a red or orange live events status indicator, even when your system seems fine, the following suggestions may offer a solution:

• Try manually refreshing/reloading your browser page.
• Try changing web browsers, as Firefox and Safari have been reported to have issues trusting self-signed certificates.
• Try creating a self-signed certificate that matches your DNS and import it into your trust manually.
• Try using an incognito or private browsing session.
• Try disabling your browser plugins to ensure none are blocking the service.
• Try accessing Tower at https://tower-ip:8080/ which should allow you to accept the certificate for the machine.

Live event status dots are used for troubleshooting problems with your Tower instance and the socketio logs can point out anything problematic. You can collect troubleshooting help by running a sosreport. As root, run the command sosreport from your system to automatically generate a diagnostic tar file, then contact Ansible’s Support team with the collected information for further assistance.

3.8. Use of Custom Certificates with Live Events¶

When using a custom SSL certificate with Live Events, you must:

• use the default /etc/tower/tower.cert and /etc/tower/tower.key paths
• use an unencryped /etc/tower/tower.key keyfile.

If a custom location or encrypted keyfile is used, the Live Events service will not function properly.

3.9. sudo/su not working as expected for local playbooks or playbooks with local_actions¶

Instances have been reported that sudo/su commands do not work when using an entirely local playbook or a playbook with some local_actions cases. This is likely due to PRoot being enabled. To use sudo/su commands with local playbooks or those with local_actions, PRoot must be disabled. You can disable PRoot by navigating to the /etc/tower/settings.py file, setting AWX_PROOT_ENABLED=False, then restarting services with the ansible-tower-service restart command.

3.10. Installation program does not enable su command support¶

During the testing of Ansible Tower 2.3.0, it was discovered that the installation program does not handle the option to enable su command support.

When using the Tower installation program to install Tower to a remote system where su access is required, the installation program will not work. To workaround this issue, you should manually run the ansible-playbook command with the --su parameter.

3.11. Problems when using SSH customization¶

The PRoot functionality in Ansible Tower limits which directories on the Tower file system are available for playbooks to see and use during playbook runs. If you are attempting to customize SSH behavior by using a custom SSH configuration in the Tower user’s home directory, this directory must be added to the list of directories exposed by PRoot.

For example, to add a custom SSH config in /var/lib/awx/.ssh/config and make it available for Tower jobs, edit the /etc/tower/settings.py file and add that path to the AWX_PROOT_SHOW_PATHS variable:

AWX_PROOT_SHOW_PATHS = [ '/var/lib/awx/.ssh/' ]

Once the paths you need have been added to settings.py, restart Tower using the admin utility script, ansible-tower-service:

ansible-tower-service restart

3.12. Ubuntu unsupported for bundled installations¶

If you are using the bundled installer for Ansible Tower 2.3.0, note that only Red Hat Enterprise Linux and CentOS are supported at this time. Ubuntu support has not yet been added to the bundled installer. Ubuntu users can continue to use the unbundled installer.

3.13. YAML parser errors when installing Tower without python-yaml installed¶

Instances of YAML parser traceback errors have been reported when users attempt to install Tower without python-yaml being installed. In this scenario, the installation program uses the built-in YAML parser, but the built-in YAML parser is unable to parse a YAML variable initialized to an empty dictionary (e.g. {}).

The traceback may look like the following:

Traceback (most recent call last):
  File "./configure", line 787, in <module>
    if conf['configure_private_vars'].get(field, None):
AttributeError: 'str' object has no attribute ‘get’

To workaround this issue, remove the offending variable (such as configure_private_vars: {}) from the Tower settings file, tower_setup_conf.yml.

3.14. Session Limits of 1 minute or less will break your instance of Tower¶

Proactive session limits will kick the user out when the session is idle. It is strongly recommended that you do not set the session limit to anything less than 1 minute, as doing so will break your Ansible Tower instance.

3.15. Ansible 2.0 strategies¶

Ansible 2.0 introduces strategies, such as strategy: free, but Ansible Tower support for these new strategies is not yet available in Tower version 2.4.0. This Ansible feature will not be added to Tower until a later release.

If you attempt to use strategy: free in Ansible Tower, jobs will run, but they will not display properly in the Job Detail page.

Refer to the following link for more information: https://docs.ansible.com/ansible/playbooks_strategies.html

3.16. Reactivating OAuth authentication accounts which have been deleted¶

Once a user who logs in using social authentication has been deleted, the user will not be able to login again or be recreated until the system administrator runs a cleanup_deleted action with days=0 to allow users to login again. Once cleanup_deleted has been run, Tower must be restarted using the ansible-tower-service restart command. Accounts which have been deleted prior to having the cleanup_deleted action run will receive a “Your account is inactive” message upon trying to login.