Chcę zaproponować jeszcze jedno rozwiązanie:
- 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
Dlaczego to jest lepsze? Jak już tu wspomniano, gry Ansible powinny być idempotentne. Powinieneś myśleć o nich nie jako o sekwencji działań w stylu rozkazującym, ale jak o pożądanym stanie, stylu deklaratywnym. W rezultacie powinieneś być w stanie uruchomić go wiele razy i uzyskać ten sam wynik, ten sam stan serwera.
To wszystko brzmi świetnie, ale są pewne niuanse. Jednym z nich jest zarządzanie użytkownikami. „Stan pożądany” oznacza, że za każdym razem, gdy uruchamiasz grę, która tworzy użytkownika, zostanie on zaktualizowany, aby dokładnie odpowiadał temu stanowi. Przez „zaktualizowane” rozumiem, że jego hasło również zostanie zmienione. Ale najprawdopodobniej to nie jest to, czego potrzebujesz. Zwykle wystarczy tylko raz stworzyć użytkownika, ustawić i wygaśnąć jego hasło, dalsze rozgrywki nie powinny aktualizować jego hasła.
Na szczęście Ansible ma update_password
atrybut w user
module, który rozwiązuje ten problem. Mieszając to z zarejestrowanymi zmiennymi , możesz również wygasnąć jego hasło tylko wtedy, gdy użytkownik jest faktycznie zaktualizowany.
Zauważ, że jeśli zmienisz powłokę użytkownika ręcznie (przypuśćmy, że nie podoba ci się powłoka, którą zmusił zły administrator do swojej gry), użytkownik zostanie zaktualizowany, a tym samym jego hasło straci ważność.
Zwróć także uwagę, jak łatwo możesz używać początkowych haseł w postaci zwykłego tekstu w grach. Nie ma potrzeby kodowania ich gdzie indziej i wklejania skrótów, możesz do tego użyć filtra Jinja2 . Może to jednak stanowić lukę w zabezpieczeniach, jeśli zdarzy się, że ktoś zaloguje się, zanim to zrobisz.
password
nie powinien być zwykłym tekstem, ale raczej zhasowany.