Known Issues¶

Potential security issue using X_FORWARDED_FOR in REMOTE_HOST_HEADERS¶

If placing Tower nodes behind some sort of proxy, this may pose a security issue. This approach assumes traffic is always flowing exclusively through your load balancer, and that traffic that circumvents the load balancer is suspect to X-Forwarded-For header spoofing. See Proxy Support.

Server error when accessing SAML metadata via hostname¶

When Tower is accessed via hostname only (e.g. https://my-little-tower), trying to read the SAML metadata from /sso/metadata/saml/ generates a sp_acs_url_invalid server error.

A configuration in which uses SAML when accessing Tower via hostname only instead of an FQDN, is not supported. Doing so will generate an error that is captured in the tower.log file and in the browser with full traceback information.

Running in FIPS mode¶

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

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.

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. They are not seen at all when the system is in a healthy 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.

VMWare Self-Signed Certs¶

If you have a vmware instance that uses a self-signed certificate, then you will need to add the followig to the Source Vars configuration of the Cloud Group:

"source_vars": "---\nvalidate_certs: False",

Celery Beat Database on Disk Becomes Corrupted¶

If celery is not cleanly shutdown, it leaves a /var/lib/awx/beat.db file on disk.

If you observe the traceback in the initial comment, you must manually delete the /var/lib/awx/beat.db file and restart Tower.

Safari unable to establish connection to web socket¶

The following connection error displays in Tower:

This error is the result of Safari silently refusing to establish a connection to a web socket that is using a self-signed certificate. To resolve this issue, you must set Safari to always trust the website upon first visiting it:

1. Close the current browser and revisit the site. An error message appears stating Safari can’t verify the identity of the website.
2. Click Show Certificate.
3. Check the Always trust ... when connecting to ... checkbox to allow Safari to accept the connection.

If you click Continue without checking the checkbox, this error will persist.

Ansible Module for set_stats unavailable until Ansible v2.2.2¶

The set_stats Ansible module is unavailable until Ansible 2.2.2 is released. This module is used by Tower to pass artifacts from one job to another in a workflow. As a workaround, please note that you are able to use artifacts with the devel branch of Ansible.

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 through the Jobs tab of the Configure Tower screen by setting the Enable Job Isolation toggle to OFF:

Click Save to save your changes and restart services.

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, you can specify the path in the Job Execution Isolation Path field accessed from the Jobs tab of the Configure Tower screen:

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.

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.

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

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.