Eu tenho o Ansible Tower mais recente configurado em um RHEL 8.9
Quando executo tarefas ansible específicas, sempre recebo esta mensagem de erro:
{
"module_stdout": "",
"module_stderr": "sudo: /etc/sudo.conf is owned by uid 65534, should be 0\nsudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set\n",
"msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
"rc": 1,
"_ansible_no_log": false,
"changed": false
}
Exemplo de tarefas seria:
- name: Install cx_Oracle Python module
pip:
name: cx_Oracle
state: present
- name: Execute SQL to get Schemas from DB
ibre5041.ansible_oracle_modules.oracle_sql:
username: "{{ db_username }}"
password: "{{ db_password }}"
mode: "{{ 'sysdba' if ar_orcl_db_sql_user|upper == 'SYS' else 'normal' }}"
hostname: "{{ db_host }}"
service_name: "{{ db_service_name }}"
port: "{{ db_port }}"
#sql: "SELECT username FROM dba_users"
sql: "SELECT NAME FROM v$database"
delegate_to: 127.0.0.1
register: schema_result
Observe que, quando comento qualquer uma das tarefas, sempre aciona o erro.
Confirmei que o proprietário de ambos os arquivos é root e acredito que o setuid foi definido.
Aqui está a prova:
$ ls -la /usr/bin/sudo
---s--x--x. 1 root root 165528 Dec 7 2021 /usr/bin/sudo
$ stat /usr/bin/sudo
File: /usr/bin/sudo
Size: 165528 Blocks: 328 IO Block: 4096 regular file
Device: ca02h/51714d Inode: 9184962 Links: 1
Access: (4111/---s--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:sudo_exec_t:s0
Access: 2024-02-23 12:17:03.876558806 +0000
Modify: 2021-12-07 12:02:43.000000000 +0000
Change: 2022-11-21 19:52:23.879128352 +0000
Birth: 2022-11-21 19:47:26.179931860 +0000
$ stat /etc/sudo.conf
File: /etc/sudo.conf
Size: 1786 Blocks: 8 IO Block: 4096 regular file
Device: ca02h/51714d Inode: 8619263 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:etc_t:s0
Access: 2024-02-23 12:17:03.883558691 +0000
Modify: 2021-12-07 11:57:12.000000000 +0000
Change: 2022-11-21 19:52:23.873128307 +0000
Birth: 2022-11-21 19:47:26.165931757 +0000
O que eu perdi aqui?
Tive o mesmo problema. Tente “tornar-se: false”, não sei por que funciona.
Eu tenho uma resposta completa em um fórum ansible. Estou postando aqui a resposta para que quem enfrenta esse problema entenda por que isso acontece e como resolver.
Basicamente, o antigo Tower 3.8 também possui um mecanismo para isolar o processo de execução do job em outra forma (Bubblewrap) que não seja o Podman. Você pode encontrar mais informações aqui .
Resolvi o problema adicionando
extra_args: "--user"
à primeira tarefa ebecome: false
à segunda tarefa.Para mais detalhes, você pode conferir minha postagem em outro fórum aqui .