Voglio proporre ancora un'altra soluzione:
- 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
Perché è meglio? Come è già stato notato qui, i giochi Ansible dovrebbero essere idempotenti. Dovresti pensarli non come una sequenza di azioni in stile imperativo, ma come uno stato desiderato, uno stile dichiarativo. Di conseguenza dovresti essere in grado di eseguirlo più volte e ottenere lo stesso risultato, lo stesso stato del server.
Sembra tutto fantastico, ma ci sono alcune sfumature. Uno di questi è la gestione degli utenti. "Stato desiderato" significa che ogni volta che esegui un gioco che crea un utente, verrà aggiornato in modo che corrisponda esattamente a quello stato. Con "aggiornato" intendo che anche la sua password verrà cambiata. Ma molto probabilmente non è quello che ti serve. Di solito, è necessario creare l'utente, impostare e far scadere la sua password solo una volta, ulteriori corse di gioco non dovrebbero aggiornare la sua password.
Fortunatamente, Ansible ha un update_passwordattributo nel usermodulo che risolve questo problema. Mescolando questo con le variabili registrate puoi anche far scadere la sua password solo quando l'utente viene effettivamente aggiornato.
Nota che se cambi la shell dell'utente manualmente (supponiamo, non ti piace la shell che il malvagio amministratore ha forzato nel suo gioco) l'utente verrà aggiornato, quindi la sua password sarà scaduta.
Nota anche come puoi usare facilmente le password iniziali in testo normale nei giochi. Non c'è bisogno di codificarli da qualche altra parte e incollare gli hash, puoi usare il filtro Jinja2 per quello. Tuttavia, questo può essere un difetto di sicurezza se qualcuno accede prima di te inizialmente.
passwordnon dovrebbe essere in testo normale ma piuttosto prehashed.