Почему не работает become на хосте Ubuntu 26.04 LTS?

Question

[Антон Татаринов]

Машина с Ansible - Ubuntu 22.04 LTS
ansible [core 2.17.13]

Управляемый хост:

Distributor ID: Ubuntu
Description:    Ubuntu 26.04 LTS
Release:        26.04
Codename:       resolute

- name: Create a user
  delegate_to: '{{ srv_ip }}'
  ansible.builtin.user:
    name: admin
    shell: /bin/bash
    create_home: yes
    state: present
  become: true
  become_method: sudo

Ошибка:

fatal: [localhost -> 192.168.1.54]: FAILED! => {
    "msg": "Timeout (12s) waiting for privilege escalation prompt: "
}

Answer 1

[Пума Тайланд]

В Ubuntu 26.04 заменили sudo на sudo-rs, у него другой формат промпта. Ansible 2.17.x его не распознаёт и таймаутится. Самый быстрый фикс — указать классический sudo в инвентаре: ansible_become_exe=/usr/bin/sudo.ws (он остался доступен в 26.04 рядом с sudo-rs). Или добавь NOPASSWD для ansible-юзера, тогда промпт не нужен вообще.

Comments

[Dmitry]

или можно указать прям в плейбуке или таске

vars:
  ansible_become_exe: "sudo.ws"

[Пума Тайланд]

да, в vars гибче — можно переопределить только для конкретного плейбука без правки инвентаря

Answer 2

[Andrei Katin]

Причина — переход Ubuntu 26.04 на sudo-rs

У sudo-rs отличается текст запроса пароля:

• классический sudo: [sudo] password for user:
  
• sudo-rs: [sudo: authenticate] Password:
  

Ansible 2.17 ожидает знакомый ему шаблон prompt и получает timeout, хотя SSH, пароль и сам sudo могут работать нормально. Это известная проблема Expect-подобной автоматизации с новым приглашением sudo-rs.

Документация Ubuntu:
https://documentation.ubuntu.com/server/reference/...

Быстрый и локальный обходной путь

В Ubuntu 26.04 рядом с sudo-rs оставлен классический бинарник /usr/bin/sudo.ws. Можно заставить использовать его только Ansible, не переключая sudo во всей системе:

ansible_become: true
ansible_become_method: sudo
ansible_become_exe: /usr/bin/sudo.ws

Для приведённого задания:

- name: Create a user
  delegate_to: "{{ srv_ip }}"
  ansible.builtin.user:
    name: admin
    shell: /bin/bash
    create_home: true
    state: present
  become: true
  vars:
    ansible_become_exe: /usr/bin/sudo.ws

Либо задайте ansible_become_exe в inventory/host_vars именно для управляемого хоста.

Как проверить гипотезу

На Ubuntu 26.04:

readlink -f "$(command -v sudo)"
ls -l /usr/bin/sudo.ws
sudo --version
sudo.ws --version

Если sudo требует пароль, playbook запускается с -K:

ansible-playbook -i inventory.yml playbook.yml -K

Пароль для автоматического запуска лучше передавать через Ansible Vault или защищённое хранилище секретов, а не записывать открытым текстом в inventory.

Что ещё стоит сделать

• обновить управляющую машину с ansible-core 2.17 до поддерживаемой актуальной ветки;
  
• проверить задачу с -vvv или -vvvv, чтобы увидеть фактическую команду privilege escalation;
  
• убедиться, что переменные become относятся к делегированному хосту, а не только к localhost.
  

NOPASSWD также устранит запрос пароля, но это отдельное решение по безопасности. Давать автоматизационной учётной записи неограниченный NOPASSWD только ради обхода несовместимого prompt я бы не советовал.

Наиболее безопасный временный фикс — ansible_become_exe=/usr/bin/sudo.ws только для Ansible, плюс обновление ansible-core.