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 causes installations to fail.

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

3.2. 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.3. 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.4. Host comparisons against a two hosts¶

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

3.5. 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.

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.6. Playbooks missing access to necessary data due to PRoot issues¶

When running a playbook that reads and writes information in certain prohibited directories, users may encounter issues with PRoot. PRoot runs the ansible-playbook command within a chroot jail. In cases like these, the running playbook cannot see other playbooks or sensitive data on disk and should the playbook expect to have access to that information, problems will occur. To fine tune your usage of PRoot, there are certain variables that can be set:

# Enable proot support for running jobs (playbook runs only).
AWX_PROOT_ENABLED = False

# Command/path to proot.
AWX_PROOT_CMD = 'proot'

# Additional paths to hide from jobs using proot.
AWX_PROOT_HIDE_PATHS = []

# Additional paths to show for jobs using proot.
AWX_PROOT_SHOW_PATHS = []

3.7. Slower than expected performance¶

Slow performance issues have been reported against Ansible Tower 2.2.0. You may experience slower than expected system performance if:

• You have a large number of job templates, users, credentials, permissions, projects, and/or inventories. If you find that loading the job template page for normal users is unacceptably slow, run the “Cleanup Deleted Data” management job with days = 0. Refer to Management Jobs in the Ansible Tower Administration Guide for more information.
• You have a job that produces a lot of playbook output (several megabytes or more). Performance can often be improved by switching to “Normal” verbosity, assuming that your Job Template is set to a higher verbosity level.