2. 已知问题

2.1. `CSRF_TRUSTED_ORIGIN` 设置 

如果您在负载均衡器后面使用 AWX，则可能需要 CSRF_TRUSTED_ORIGIN 设置。随着 Django 4.2 的更新，CSRF（跨站点请求伪造）检查变得更加严格。因此，在负载均衡器后面使用 AWX 在以前工作的情况下可能会导致问题。如果您遇到以下错误，则需要将源添加到 CSRF_TRUSTED_ORIGIN 设置中。

WARNING [b336a554] django.security.csrf Forbidden (Origin checking failed - https://127.0.0.1:3001 does not match any trusted origins.): /api/login/

有关如何解决此错误的更多详细信息，请参阅 Django csrf-trusted-origins 文档。

2.2. 启动 ansible-runner 组件无法按预期工作 

对 ansible-runner 组件的启动方式（AWX 启动以运行剧本的执行环境中的可执行文件）进行了一项更改，引入了向后不兼容性。强烈建议始终在与您使用的 AWX 版本相对应的基本执行环境之上重新构建。这通常应该是升级的理想方法。

2.3. 删除默认组织会产生重复的 Ansible-Galaxy 凭据 

尽管能够在删除默认组织时运行后续安装，但它不会自动删除或修复重复的 Ansible-Galaxy 凭据。

2.5. 浏览器忽略 `autocomplete=off` 设置 

AWX 利用表单上的 autocomplete=off 属性来向浏览器传达它不应自动填充该表单中的字段。但是，在某些情况下，浏览器可能会忽略此设置并尝试保存和/或自动填充字段。这往往发生在似乎包含登录字段（如用户名和密码）的表单上，例如“用户”表单和某些“设置”表单。正在进一步调查以提供防止此行为的选项。

2.7. 作业切分和限制交互 

将限制传递给切分作业时，如果限制导致切片没有分配主机，则这些切片将失败，导致整个作业失败。

2.8. 滥用作业切分会导致作业调度错误 

作业切分的目的是水平扩展作业执行。在作业模板上启用作业切分会将要操作的清单划分为在启动时配置的切片数量，然后为每个切片启动一个作业。

预计切片数量将等于或小于控制器节点的数量。设置极高的作业切片数量（例如，数千个），虽然允许，但会导致性能下降，因为作业调度程序并非设计为同时调度数千个工作流节点，而切分作业将变为工作流节点。

2.9. 必须配置默认 LDAP 目录才能使用 LDAP 身份验证 

能够配置最多六个用于身份验证的 LDAP 目录需要一个值。在 LDAP 的设置页面上，有一个“默认”LDAP 配置，后面跟着五个编号的配置插槽。如果未填充“默认”，则 AWX 将不会尝试使用其他目录配置进行身份验证。

2.10. 在 `REMOTE_HOST_HEADERS` 中使用 `X_FORWARDED_FOR` 存在潜在的安全问题 

如果将 AWX 节点放置在某种代理后面，这可能会造成安全问题。此方法假设流量始终仅通过您的负载均衡器流动，并且绕过负载均衡器的流量容易受到 X-Forwarded-For 标头欺骗。

2.11. 通过主机名访问 SAML 元数据时出现服务器错误 

当仅通过主机名访问 AWX（例如 https://my-little-awx）时，尝试从 /sso/metadata/saml/ 读取 SAML 元数据会生成 sp_acs_url_invalid 服务器错误。

仅通过主机名而不是 FQDN 访问 AWX 时使用 SAML 的配置不受支持。这样做会生成一个错误，该错误将在浏览器中捕获，并包含完整的回溯信息。

较旧版本的 AWX，SAML 适配器不会评估登录用户的系统审计员或系统管理员角色。因此，登录过程不会更改通过用户界面授予用户的系统角色。适配器现在有一个名为 **SAML 用户标志属性映射** 的设置，可以根据 SAML 属性或角色授予登录用户的这些角色，并且适配器默认为在未指定的情况下删除这些角色，类似于 LDAP 适配器。请参阅显示角色、属性和属性值设置的配置方式以及用户是否将被授予系统管理员/审计员角色之间关系的逻辑表。

2.13. 实时事件状态指示器 

当出现问题时，在 AWX 仪表板顶部会看到实时事件状态点为红色或橙色。当系统处于健康状态时，根本看不到它们。如果您遇到红色或橙色实时事件状态指示器，即使您的系统似乎正常，以下建议可能会提供解决方案

尝试手动刷新/重新加载浏览器页面。
尝试更改网络浏览器，因为据报道 Firefox 和 Safari 在信任自签名证书方面存在问题。
尝试创建与您的 DNS 匹配的自签名证书，并将其手动导入到您的信任库中。
尝试使用隐身或私人浏览会话。
尝试禁用浏览器插件以确保没有任何插件阻止服务。

实时事件状态点用于排查 AWX 实例的问题。您可以通过运行 sosreport 收集故障排除帮助。以 root 身份在您的系统上运行命令 sosreport 以自动生成诊断 tar 文件，然后联系 Ansible 的支持团队，提供收集的信息以获得进一步的帮助。有关 sosreport 的更多信息，请参阅《AWX 管理指南》中的 sosreport。

2.14. VMware 自签名证书 

如果您有一个使用自签名证书的 VMware 实例，则需要将以下内容添加到云组的源变量配置中

"source_vars": ---validate_certs: False

您可以在 VMware vCenter 的清单源中进行如下设置

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

2.15. awx-manage inventory_import 用户 

通常，当由 root 或 awx 用户执行时，支持使用 awx-manage 命令。但是，即使以 root 用户身份运行，命令 awx-manage inventory_import 仍可能无法与托管执行环境的私有注册表进行身份验证。解决方法是以 awx 用户身份运行该命令，因为图像应该由安装程序预先提取，并且安装程序可以正确地进行身份验证。

2.16. 升级 OCP 部署上的现有实例组 

所有作业执行都在 OpenShift 上部署的容器组中发生。在用户界面中禁用了创建新的“普通”实例组，但是升级后，普通实例组不会发生任何变化。这是一个已知问题，因为任何尝试使用包含控制平面 pod 作为实例的普通实例组的资源都将具有 0 容量，并且作业将无限期地保持在挂起状态。解决方法是删除所有这些“普通”实例组。默认情况下，存在一个容器组，作业执行将在其中发生，与 AWX pod 部署在相同的命名空间中。可以通过在相同或任何其他 OpenShift 集群上配置其他容器组来提供额外的容量。

2.17. 磁盘上的数据库损坏 

如果 AWX 未干净地关闭，它会在磁盘上留下 /var/lib/awx/beat.db 文件。如果发生这种情况，调度程序将无法启动，您必须手动删除 /var/lib/awx/beat.db 文件并重新启动 AWX，调度程序才能正常启动。

2.18. 本地管理功能异常 

所有 playbook 都是由 AWX 在称为自动化执行环境的 Linux 容器中执行的。

使用 delegate_to: localhost 或 local_action 管理执行主机在此环境中将不起作用，因为它仍然在容器内执行。

要管理执行所在的本地主机，您需要使用 ssh 连接插件从容器连接到本地主机。