Question 1

如何修复在使用 Python 3.15 运行 ansible-galaxy 或 ansible 时出现的 "AttributeError: module dataclasses has no attribute _is_type" 错误？

Accepted Answer

此错误是因为 ansible-core 2.21 依赖于内部的 `dataclasses._is_type` API,而该 API 已在 Python 3.15 中被移除,且 ansible-core 2.21 并不支持 Python 3.15。修复方法:(1) 升级到 ansible-core 2.22+,这是首个官方支持 Python 3.15 的版本(通过 PR #86976 修复):`pip install --upgrade ansible-core>=2.22`。(2) 或者将解释器降级到受支持的 Python 版本(例如 3.14 或更低版本),以配合 ansible-core 2.21 使用。目前没有针对 2.21 的向后移植(backport)计划,因此升级 ansible-core 或降级 Python 是仅有的两种选择。

Question 2

如何修复在 Ubuntu 26.04 上使用 --become 时出现的 Ansible "Timeout waiting for privilege escalation prompt" 错误？

Accepted Answer

此问题影响 Ubuntu 26.04 上的 ansible-core 2.21.x，因为 Ansible 在进行权限提升时选择了错误的 sudo 可执行文件。解决方法是将 become 可执行文件显式设置为 `/usr/bin/sudo.ws`：

```bash
ansible -i hosts.ini ubuntu26 -a "ls" -k -K -b -e ansible_become_exe=/usr/bin/sudo.ws
```

或者，在你的 inventory 中设置它：

```ini
[ubuntu26]
your-host ansible_become_exe=/usr/bin/sudo.ws
```

如果该路径不存在，请使用 `command -v sudo.ws` 验证路径。该问题已在 Ansible 的 `devel` 分支中修复；相关的回溯/修复 PR 包括 #86905 和 #86964，因此在包含该修复的 ansible-core 版本发布后，请升级到该版本。

Question 3

如何修复 Ansible no_log 选项使用非字符串默认值时出现的 "'bool' object has no attribute 'strip'" 错误？

Accepted Answer

这是 ansible-core 2.22.0b2 及受影响的 devel 构建版本中的一个回归问题（#87457）；ansible-core 2.21 不受影响。请升级到包含 issue #87623 修复的发布版或 devel 构建版本，或者暂时降级到 ansible-core 2.21。

作为模块的临时解决方法，请从具有非字符串默认值的非敏感布尔、整数或端口选项中移除 `no_log=True`，例如：

```python
# Before
force=dict(type='bool', no_log=True, default=True)

# After
force=dict(type='bool', default=True)
```

同样的更改也适用于 `no_log` 子选项和角色的 `argument_specs`。修复后的 Ansible 版本能够正确处理非字符串默认值，并跳过对布尔值 `True`/`False` 的屏蔽。

Question 4

如何防止 ansible_facts 从一台主机泄漏到同一个 play 中的另一台主机？

Accepted Answer

这是由 ansible-core 2.21.x 中 `VariableManager.set_host_facts()` 的跨主机字典别名(dictionary aliasing)问题导致的,在涉及多台主机或 `run_once` 任务时尤为明显。修复方法是在缓存 facts 字典之前先对其进行复制,而不是存储调用方的字典引用。请升级到包含 PR #87415 的 ansible-core 版本,或手动应用该补丁。

一种可靠的变通方法是:显式调用 `ansible.builtin.setup`,使用 `register`,并从注册的变量中读取 facts,而不是使用隐式的 `ansible_facts`:

```yaml
- name: 收集主机 facts
  ansible.builtin.setup:
  register: host_setup

- name: 使用注册的 facts
  ansible.builtin.debug:
    var: host_setup.ansible_facts.ansible_default_ipv4.address
```

更改 `forks`、strategy、callbacks 或运行 `--flush-cache` 都无法解决此问题,因为 facts 是在内存中被别名引用的。

Question 5

为什么在 FreeBSD 上使用 `ansible.builtin.service` 时，`state: restarted` 对已禁用的服务没有效果？

Accepted Answer

在 FreeBSD 上，service 模块会将已禁用服务的 `start`、`stop` 和 `reload` 映射到对应的 `one*` 形式，但 `restart` 不会映射为 `onerestart`。因此，已禁用的服务不会被重启。

解决方法：直接调用 FreeBSD 的 `onerestart`：

```yaml
- name: 强制重启已禁用的 FreeBSD 服务
  become: true
  ansible.builtin.command:
    cmd: /usr/sbin/service apache24 onerestart
  changed_when: true
```

或者，在重启之前先启用该服务：

```yaml
- name: 启用并重启 apache24
  become: true
  ansible.builtin.service:
    name: apache24
    enabled: true
    state: restarted
```

上游代码的修复方式是以相同的方式映射 restart 操作：

```python
if self.action == "restart":
    self.action = "onerestart"
```

ansible

项目简介

README 预览

常见问题 (5)

同类型项目

hermes-agent

firecrawl

go

markitdown