Ten en cuenta que en las ciencias informáticas un problema casi siempere suele tener diversas resoluciones, no obstante nosotros te compartimos lo más óptimo y eficiente.
Solución:
Puede que sea demasiado tarde para responder esto, pero recientemente descubrí que los filtros jinja2 tienen la capacidad de manejar la generación de contraseñas cifradas. En mi main.yml Estoy generando la contraseña cifrada como:
- name: Creating user " uusername " with admin access
user:
name: uusername
password: upassword
groups: admin append=yes
when: assigned_role == "yes"
- name: Creating users " uusername " without admin access
user:
name: uusername
password: upassword
when: assigned_role == "no"
- name: Expiring password for user " uusername "
shell: chage -d 0 " uusername "
“uusername” y “uppassword” se pasan como --extra-vars al libro de jugadas y observe que he usado el filtro jinja2 aquí para cifrar la contraseña pasada.
He agregado a continuación un tutorial relacionado con esto en mi blog.
- https://thinkingmonster.wordpress.com/it-automation/386-2/ansible-roles/
Si lee el manual de Ansible para user módulo, lo dirigirá al repositorio de github de Ansible-examples para obtener detalles sobre cómo usar password parámetro.
Allí verás que tu contraseña debe ser cifrada.
- hosts: all
user: root
vars:
# created with:
# python -c 'import crypt; print crypt.crypt("This is my Password", "$1$SomeSalt$")'
password: $1$SomeSalt$UqddPX3r4kH3UL5jq5/ZI.
tasks:
- user: name=tset password=password
Si su libro de jugadas o línea de comando ansible tiene su contraseña tal como está en texto sin formato, esto significa que su hash de contraseña está registrado en su sombra el archivo esta mal Eso significa que cuando intenta autenticarse con su contraseña, su hash nunca coincidirá.
Además, consulte las preguntas frecuentes de Ansible sobre algunos matices del parámetro de contraseña y cómo usarlo correctamente.
Quiero proponer otra solución:
- name: Create madhead user
user:
name: madhead
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
¿Por qué es mejor? Como ya se ha señalado aquí, las obras de Ansible deben ser idempotentes. Debe pensar en ellos no como una secuencia de acciones en estilo imperativo, sino como un estado deseado, estilo declarativo. Como resultado, debería poder ejecutarlo varias veces y obtener el mismo resultado, el mismo estado del servidor.
Todo esto suena genial, pero hay algunos matices. Uno de ellos es la gestión de usuarios. “Estado deseado” significa que cada vez que ejecuta una jugada que crea un usuario, se actualizará para que coincida exactamente con ese estado. Por “actualizado” quiero decir que su contraseña también se cambiará. Pero lo más probable es que no sea lo que necesitas. Por lo general, debe crear un usuario, configurar y hacer caducar su contraseña solo una vez, las ejecuciones posteriores del juego no deberían actualizar su contraseña.
Afortunadamente, Ansible tiene update_password attribute en user módulo que resuelve este problema. Combinando esto con variables registradas, también puede caducar su contraseña solo cuando el usuario esté realmente actualizado.
Tenga en cuenta que si cambia el shell del usuario manualmente (supongamos que no le gusta el shell que el malvado administrador forzó en su juego), el usuario se actualizará, por lo que su contraseña caducará.
También tenga en cuenta cómo puede usar fácilmente contraseñas iniciales de texto sin formato en las obras de teatro. No es necesario codificarlos en otro lugar y pegar hashes, puede usar el filtro Jinja2 para eso. Sin embargo, esto puede ser una falla de seguridad si alguien inicia sesión antes que usted.
Recuerda difundir esta noticia si te valió la pena.