☰

sudo: /etc/sudo.conf 由 uid 65534 拥有，应为 0\nsudo: /usr/bin/sudo 必须由 uid 0 拥有，并且设置了 setuid 位

tag-icon • tag-icon ansible ansible-playbook ansible-tower
sudo: /etc/sudo.conf 由 uid 65534 拥有，应为 0\nsudo: /usr/bin/sudo 必须由 uid 0 拥有，并且设置了 setuid 位

我在 RHEL 8.9 上配置了最新的 Ansible Tower

当我运行特定的 ansible 任务时，我总是收到此错误消息：

{
    "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
}

任务示例如下：

    - 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

请注意，当我评论其中一项任务时，它总是触发错误。

我已确认这两个文件的所有者都是 root，并且我相信 setuid 已设置。

证明如下：

$ 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

我在这里错过了什么？

答案1

有同样的问题。尝试“become: false”，不知道为什么它有效。

答案2

我在 ansible 论坛上找到了完整的答案。我在这里发布答案，以便任何遇到此问题的人都能理解为什么会发生这种情况以及如何解决它。

基本上，旧的 Tower 3.8 也具有另一种形式（Bubblewrap）隔离作业执行过程的机制，而不是 Podman。您可以找到更多信息这里。

extra_args: "--user"我通过添加第一个任务和become: false第二个任务解决了这个问题。

有关更多详细信息，您可以查看我在另一个论坛上的帖子这里。

相关内容