在具有共享NFS挂载的服务器上运行playbook

Question

我有以下Ansible playbook，可用于跨集群进行软件包更新：

- hosts: cluster
  become: true
  become_user: root
  tasks:
   - name: updates a server
     apt: update_cache=yes
   - name: upgrade a server
     apt: upgrade=full

当我运行它时，作为NFS控制器的节点执行得非常好，但是那两个在home目录上挂载NFS的节点失败，并显示以下错误：

$ansible-playbook upgrade-servers.yml  -K
SUDO password:

PLAY ***************************************************************************

TASK [setup] *******************************************************************
fatal: [nej-worker2]: FAILED! => {"changed": false, "failed": true, "module_stderr": "", "module_stdout": "\r\n/usr/bin/python: can't open file '/home/gms/.ansible/tmp/ansible-tmp-1461269057.4-144211747884693/setup': [Errno 13] Permission denied\r\n", "msg": "MODULE FAILURE", "parsed": false}
ok: [iznej]
fatal: [nej-worker1]: FAILED! => {"changed": false, "failed": true, "module_stderr": "", "module_stdout": "\r\n/usr/bin/python: can't open file '/home/gms/.ansible/tmp/ansible-tmp-1461269057.4-16590584976890/setup': [Errno 13] Permission denied\r\n", "msg": "MODULE FAILURE", "parsed": false}

TASK [updates a server] ********************************************************
ok: [iznej]

TASK [upgrade a server] ********************************************************
changed: [iznej]

NO MORE HOSTS LEFT *************************************************************

PLAY RECAP *********************************************************************
iznej                      : ok=3    changed=1    unreachable=0    failed=0
nej-worker1                : ok=0    changed=0    unreachable=0    failed=1
nej-worker2                : ok=0    changed=0    unreachable=0    failed=1

我在共享文件夹上运行pip时遇到了类似的问题，解决方法是使用--set-build重定向构建目录... 我认为这就是Ansible的问题，因为它在NFS控制器上工作正常，而不是那些具有共享/挂载驱动器的服务器。

- horcle_buzz

Answer 1

明白了。需要在我的ansible.cfg文件中添加remote_tmp = /tmp/.ansible。请参见此处Ansible配置参数。完成！

问题在于当Ansible执行sudo时，root帐户不是NFS挂载共享上的用户帐户。

- horcle_buzz

Answer 2

引用 RHEL 6 安全指南:

“默认情况下，NFS 共享将根用户更改为 nfsnobody 用户，一个非特权用户帐户。这会将所有由 root 创建的文件的所有者更改为 nfsnobody，从而防止上传设置了 setuid 位的程序。如果使用 no_root_squash [选项]，远程 root 用户可以更改共享文件系统上的任何文件，并留下被特洛伊木马感染的应用程序供其他用户无意中执行。”

换句话说，这是一种默认且安全的 NFS 行为。

- ILIV