I want to offer another solution:
- name: Create madhead user user: name: madhead password: "{{ 'password' | password_hash('sha512') }}" shell: /bin/zsh update_password: on_create register: madhead - name: Force madhead to change password shell: chage -d 0 madhead when: madhead.changed
Why is it better? As already noted here, Ansible plays must be idempotent. You should not think of them as a sequence of actions in an imperative style, but as a desired state, a declarative style. As a result, you can run it several times and get the same result, the same server state.
All this sounds great, but there are some nuances. One of them is user management. “Desired state” means that every time you launch a game that creates a user, it will be updated to exactly match that state. By "update" I mean that his password will also be changed. But, most likely, this is not what you need. Usually you need to create a user, set and end his password only once, further playback runs should not update his password.
Fortunately, Ansible has the update_password attribute in the user module, which solves this problem. By mixing this with registered variables , you can also finish your password only when the user is actually updated.
Please note that if you change the user’s shell manually (suppose you don’t like the shell that the villainous administrator made to play), the user will be updated, so his password will expire.
Also pay attention to how you can easily use the initial plaintext passwords in games. There is no need to encode them somewhere else and insert hashes; you can use the Jinja2 filter . However, this can be a security flaw if someone accidentally logs in before you do this.
madhead Apr 24 '16 at 15:05 2016-04-24 15:05
source share