Known Issues¶

Isolated node public key not restored ¶

Tower clusters optionally generate an ssh key pair and distribute them to isolated nodes for use when Tower control nodes contact the isolated nodes. This is enabled with the install option in the inventory file by setting isolated_key_generation=true. This key pair is stored as a set of Tower settings called AWX_ISOLATED_PUBLIC_KEY and AWX_ISOLATED_PRIVATE_KEY.

If you restore a backup of a cluster on new hosts, the public key Tower uses to connect to the isolated node is not placed on the isolated node, causing Tower to be unable to access the isolated node using AWX_ISOLATED_PRIVATE_KEY, so it is not possible for Tower to run jobs on the isolated nodes.

Isolated nodes unsupported in an OpenShift deployment ¶

Isolated nodes are not currently supported when deploying Ansible Tower in OpenShift.

Browsers ignoring the `autocomplete=off` setting ¶

Ansible Tower leverages the autocomplete=off attribute on forms to relay to the browser that it should not autocomplete the fields within that form. In some scenarios, however, the browser may ignore this setting and attempt to save and/or autocomplete fields. This tends to happen on forms that appear to contain login fields like username and password, such as the User form and some Settings forms. Further investigation is underway to deliver options that prevent this behavior.

Job slicing and limit interactions ¶

When passing a limit to a Sliced Job, if the limit causes slices to have no hosts assigned, those slices will fail, causing the overall job to fail.

Default LDAP directory must be configured to use LDAP Authentication ¶

Tower 3.3 introduced the ability to configure multiple LDAP directories for authentication–up to six. On the settings page for LDAP, there is a “Default” LDAP configuration followed by five-numbered configuration slots. If the “Default” is not populated, Tower will not try to authenticate using the other directory configurations.

Lost Isolated Jobs ¶

After starting an isolated job, if an event impacts the availability of the controller which manages the job, Tower will be unable to determine the status of the job, and manual intervention will be necessary. Contact Ansible via the Red Hat Customer portal at https://access.redhat.com/ for instructions specific to your scenario.

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 in the Ansible Automation Platform Installation and Reference Guide.

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.

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. 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. For more information on sosreport, refer to sosreport in the Ansible Tower Administration Guide.

VMWare Self-Signed Certs ¶

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

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

You can set this in inventory source for VMware vCenter as follows:

_images/ki-vmware-source-variables-example.png

Tower Database on Disk Becomes Corrupted ¶

If Tower is not cleanly shutdown, it leaves a /var/lib/awx/beat.db file on disk. If that happens, the dispatcher won’t start, and you must manually delete the /var/lib/awx/beat.db file and restart Tower before the dispatcher will start properly.

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:

Close the current browser and revisit the site. An error message appears stating Safari can’t verify the identity of the website.
Click Show Certificate.
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 Azure Dependencies ¶

Ansible Tower 3.4 contains bindings for Microsoft Azure compatible with Ansible 2.7. However, these bindings will not work with earlier versions of Ansible. If you are using earlier versions of Ansible in a custom virtual environment, you may need to install different versions of Azure dependencies to use Microsoft Azure modules.

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 job isolation being enabled. To use sudo/su commands with local playbooks or those with local_actions, job isolation must be disabled. You can disable job isolation 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 Job Isolation 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 bubblewrap.

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 discontinued ¶

If you are using the bundled installer for Ansible Tower, note that only Red Hat Enterprise Linux and CentOS are supported. Ubuntu support has been discontinued as of Ansible Tower 3.6.

Database server installed on nodes ¶

All nodes in the cluster get a database server even if the nodes do not have a database. This is unexpected and may take up space.

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.

Using vaulted variables in inventory sourced from a project ¶

When using inventory from a source control project, individual vaulted variable values are supported. Vaulted files are not currently supported.

Using Tower credential with Tower 3.3+ Tokens ¶

The Ansible Tower credential type in Ansible Tower 3.4 does not support use with an OAuth2 Token. Only username + password is currently supported.

Saved scheduled and workflow configurations and surveys ¶

If a configuration of a job template is scheduled or added to a workflow with answers from a prompted survey, changing the Job Template survey to supply different variable names may cause the saved configuration to not function. The workaround is to delete the saved schedule configuration/workflow node, and recreate it with answers from the updated survey.