Question 1

Python 3.15에서 ansible-galaxy 또는 ansible을 실행할 때 발생하는 'AttributeError: module dataclasses has no attribute _is_type' 오류를 해결하는 방법

Accepted Answer

이 오류는 ansible-core 2.21이 Python 3.15에서 제거된 내부 dataclasses._is_type API에 의존하기 때문에 발생하며, ansible-core 2.21은 Python 3.15를 지원하지 않습니다. 해결 방법: (1) Python 3.15를 공식적으로 지원하는 첫 번째 버전인 ansible-core 2.22+로 업그레이드하세요 (PR #86976에서 수정됨): pip install --upgrade ansible-core>=2.22. (2) 또는 ansible-core 2.21에서 지원되는 Python 버전(예: 3.14 이하)으로 인터프리터를 다운그레이드하세요. 2.21에 대한 백포트 계획은 없으므로 ansible-core 업그레이드 또는 Python 다운그레이드가 유일한 방법입니다.

Question 2

Ubuntu 26.04에서 --become 사용 시 발생하는 Ansible "Timeout waiting for privilege escalation prompt" 오류 해결 방법

Accepted Answer

이 문제는 Ansible이 권한 상승을 위해 잘못된 sudo 실행 파일을 선택하기 때문에 Ubuntu 26.04의 ansible-core 2.21.x에 영향을 미칩니다. become 실행 파일을 `/usr/bin/sudo.ws`로 명시적으로 설정하여 이 문제를 우회하세요:

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

또는 인벤토리에서 설정할 수 있습니다:

```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로 다운그레이드하십시오.

모듈 차원의 해결 방법으로, 문자열이 아닌 기본값을 갖는 비밀 값이 아닌 boolean, integer 또는 port 옵션에서 `no_log=True`를 제거하십시오. 예를 들면 다음과 같습니다:

```python
# 변경 전
force=dict(type='bool', no_log=True, default=True)

# 변경 후
force=dict(type='bool', default=True)
```

동일한 변경 사항이 `no_log` 하위 옵션과 role `argument_specs`에도 적용됩니다. 패치된 Ansible 버전은 문자열이 아닌 기본값을 올바르게 처리하고 boolean `True`/`False` 값의 마스킹을 건너뜁니다.

Question 4

같은 플레이에서 한 호스트의 ansible_facts가 다른 호스트로 유출되는 것을 어떻게 막을 수 있나요?

Accepted Answer

이 문제는 ansible-core 2.21.x의 `VariableManager.set_host_facts()`에서 발생하는 호스트 간 딕셔너리 앨리어싱 때문에 발생하며, 특히 여러 호스트가 있거나 `run_once` 태스크가 있는 경우에 나타납니다. 이 수정 사항은 호출자의 dict 참조를 저장하는 대신 캐시하기 전에 facts 딕셔너리를 복사합니다. PR #87415가 포함된 ansible-core 릴리스로 업그레이드하거나 해당 패치를 수동으로 적용하십시오.

신뢰할 수 있는 우회 방법으로는 `ansible.builtin.setup`을 명시적으로 호출하고 `register`를 사용한 뒤, 암시적 `ansible_facts` 대신 등록된 변수에서 facts를 읽으십시오:

```yaml
- name: Gather host facts
  ansible.builtin.setup:
  register: host_setup

- name: Use registered facts
  ansible.builtin.debug:
    var: host_setup.ansible_facts.ansible_default_ipv4.address
```

facts가 메모리에서 앨리어싱되고 있기 때문에 `forks`, strategy, callbacks를 변경하거나 `--flush-cache`를 실행해도 문제가 해결되지 않습니다.

Question 5

FreeBSD에서 `ansible.builtin.service`를 사용할 때 비활성화된 서비스에 대해 `state: restarted`가 아무런 효과도 없는 이유는 무엇인가요?

Accepted Answer

FreeBSD에서 service 모듈은 비활성화된 서비스에 대해 `start`, `stop`, `reload`를 해당하는 `one*` 명령으로 매핑하지만, `restart`는 `onerestart`로 매핑되지 않습니다. 따라서 비활성화된 서비스는 재시작되지 않습니다.

해결 방법: FreeBSD의 `onerestart`를 직접 호출합니다:

```yaml
- name: Force-restart disabled FreeBSD service
  become: true
  ansible.builtin.command:
    cmd: /usr/sbin/service apache24 onerestart
  changed_when: true
```

또는, 재시작하기 전에 서비스를 활성화할 수 있습니다:

```yaml
- name: Enable and restart apache24
  become: true
  ansible.builtin.service:
    name: apache24
    enabled: true
    state: restarted
```

업스트림 코드 수정은 restart 동작을 동일한 방식으로 매핑하는 것입니다:

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

ansible

개요

README 미리보기

FAQ (5)

同类型项目

hermes-agent

firecrawl

go

markitdown