If you changed the sudoer password hash in
group_vars/<environment>/vault.yml, then what you’ve said sounds right, because the task right before the failed task is the
Setup users task, which would be the one to update the sudoer password hash on the server. I’ll explain.
With root login disabled, you would have had to pass the
admin_user sudoer password to the
ansible-playbook command using the option
--ask-become-pass. You probably passed in the old sudoer password, which would still have been in effect on the server and would have worked for all tasks up till the point the password hash was changed in the
Setup users task. Then the next task would fail because Ansible was still trying to use the sudoer password passed to
--ask-become-pass, which was suddenly out-of-date.
My guess is that the playbook will run completely and successfully if you run it again, but this time pass in the new sudoer password with
Changing the sudoer password hash is appropriate given that you were enabling vault and wanted the newly encrypted
vault.yml file to have a new hash that wasn’t in plain text in your git history.
However, changing an existing password for a sudoer while connecting as that same sudoer does present the complication you experienced here. It’s not a scenario I’ve considered before. I suppose a person who wants to change the sudoer password after root login is disabled has four options after changing the sudoer password hash in
First, you could take your approach of just running
server.yml, having to enter the old sudoer password with the
--ask-become-pass, then just let the playbook fail right after the password is changed, as you experienced. Then just use the new password with Ansible commands going forward (with
Second, an alternative would be to change back to
sshd_permit_root_login: true and run the
sshd role of
server.yml to apply that change (e.g.,
ansible-playbook server.yml -e env=<environment> --tags sshd). Then run the
users role, which will change the sudoer password. It will connect as
root now, so no need for
--ask-become-pass (e.g., just run
ansible-playbook server.yml -e env=<environment> --tags users). Then finally, change back to
sshd_permit_root_login: false and apply the change by running the
sshd role again. That’s a bit of a hassle in effort to avoid seeing the failed task that you saw.
Third, an alternative would be to change the hash manually by ssh-ing into the server (and still change it in your
group_vars/<environment>/vault.yml of course).
I guess a fourth alternative would be to back up and database, uploads, etc. (if you even need them), then rebuild the server completely, this time with the new sudoer password hash, of course.
You’re right that it is only
deploy.yml that uses
web_user, but that user must be set up first before it can be used. The user setup takes place in
server.yml, in the
users role where you saw the failed task.