@DreamOn I would have tried exactly what you described. After playing around with it, I think I understand the problem generally, although I may be incorrect on some details.
Only the user root
has adequate permissions to create the file, but I think your task was trying as admin
.
The deploy.yml
playbook makes its SSH connections as the web_user
.
I believe your become_user
: admin
parameter is similar to running sudo -u admin touch <file>
, i.e., the web_user
becomes admin
and tries to touch the file, but fails because only root
has permission.
So, you need to become root
then touch
the file. The admin
user is already a sudoer so it would be easiest to use the remote_user
task parameter to make this task’s SSH connection as admin
instead of web_user
. The become: yes
will default to becoming the root
user.
The following change is like SSHing as admin
then running sudo touch <file>
:
- name: Create file
command: touch /var/lib/mysql/test_file
become: yes
- become_user: admin
+ remote_user: admin
If I were writing the task, I’d use Ansible’s file module like this:
- name: Create file
file:
dest: /var/lib/mysql/test_file
state: touch
become: yes
remote_user: "{{ admin_user }}"
The deploy playbook intentionally only connects as the web_user
, who has limited permissions compared to the admin_user
. Adding remote_user: "{{ admin_user }}"
as above breaks this pattern. This could be a problem if you want to allow limited privilege colleagues to deploy (colleagues with ability to run only as web_user
, not admin_user
).
If adding the remote_user: "{{ admin_user }}"
parameter causes this problem for you, see the example of how Trellis enables the web_user
to run sudo service php7.0-fpm reload
by adding a permission to sudoers.d.j2 that lets web_user
run sudo service
commands without a password.