Ansible

[defaults]
hostfile = hosts
remote_user = vagrant
host_key_checking = False

callback_whitelist = profile_tasks

connection = smart
timeout = 60
deprecation_warnings = False
inventory = /home/student12/lightbulb/lessons/lab_inventory/student12-instances.txt
host_key_checking = False
private_key_file = /home/student12/.ssh/aws-private.pem

Esta línea callback_whitelist = profile_tasks muestra el tiempo que toma una tarea.

hostfile
remote_user
private_key_file
host_key_checking

Ansible busca un archivo ansible.cfg en las siguientes rutas, en este orden:

  1. Un archivo especifico declarado en la variable de ambiente ANSIBLE_CONFIG
  2. ./ansible.cfg (ansible.cfg en el directorio actual)
  3. ~/.ansible.cfg (.ansible.cfg en tu directorio $HOME)
  4. /etc/ansible/ansible.cfg

Típicamente dejo el archivo ansible.cfg dentro del directorio donde están de mis playbooks. De esa manera, puedo tener todo en el mismo repositorio de control de versiones, los playbooks y el ansible.cfg.

Ansible uses /etc/ansible/hosts as the default location for the inventory file. However, I never use this because I like to keep my inventory files version controlled alongside my playbooks.

Although we don’t cover the topic of version control in this book, I strongly recommend you use a version control system like Git for maintaining all of your playbooks. If you’re a developer, you’re already familiar with version control systems. If you’re asystems administrator and aren’t using version control yet, this is a perfect opportunity to get started.

Para las situaciones en las que los comandos requieren procesamiento de la shell, los administradores pueden usar el módulo shell. Al igual que el módulo command, pase los comandos que se deben ejecutar como argumentos al módulo en el comando ad hoc. A continuación, Ansible ejecuta el comando de forma remota en los hosts administrados. A diferencia del módulo command, los comandos se procesan a través de una shell en los hosts administrados. Por lo tanto, se podrá acceder a las variables del entorno de la shell, y también está disponible el uso de las operaciones de la shell, como redirección y tubería.

El siguiente ejemplo ilustra la diferencia entre los módulos command y shell. Si se intenta ejecutar el comando Bash integrado, set, con estos dos módulos, solo será satisfactorio con el módulo shell.

[student@demo ~]$ ansible localhost -m command -a set
localhost | FAILED | rc=2 >>
[Errno 2] No such file or directory

[student@demo ~]$ ansible localhost -m shell -a set
localhost | SUCCESS | rc=0 >>
BASH=/bin/sh
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interact
ive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
...output omitted...

Ambos command y shell requieren una instalación Python de trabajo en el host administrado. Un tercer módulo, raw, puede ejecutar un comando directamente en la shell remota, y eludir el subsistema del módulo. Esto es útil cuando administra sistemas que no pueden tener Python instalado (por ejemplo, un enrutador de red). También puede usarse para instalar Python en un host que no lo tenga aún.

Hay veces en las que los módulos de “ejecución de comandos” son herramientas valiosas y una buena solución a un problema. Si no necesita usarlos, probablemente sea mejor intentar usar command primero, y recurrir a shell o raw solo si necesita sus funciones especiales.
Para una mejor legibilidad y análisis de la salida del comando ad hoc, los administradores pueden encontrar útil tener una sola línea de salida para cada operación realizada en un host administrado. Puede usar la opción -o para mostrar la salida de los comandos ad hoc de Ansible en un formato de una sola línea.
[student@controlnode ~]$ ansible mymanagedhosts -m command -a /usr/bin/hostname -o
host1.lab.example.com | SUCCESS | rc=0 >> (stdout) host1.lab.example.com
host2.lab.example.com | SUCCESS | rc=0 >> (stdout) host2.lab.example.com
Opciones de la línea de comandos de Ansible
Parámetro Opción de la línea de comandos
inventory -i
remote_user -u
become –become, -b
become_method –become-method
become_user –become-user
become_ask_pass –ask-become-pass, -K
ansible -f1 --ssh-extra-args="-T" -u afi02552 -k -b -K aix* -m file -a "path=/usr/local/bin/sendEmail mode=u=rwx,g=rx,o=rx"
-f1 Número de Forks que lanzará Ansible
–ssh-extra-args=“-T” Disable pseudo-terminal allocation

Enlace Relacionado: https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#list-of-behavioral-inventory-parameters

En el archivo de inventario agregar la siguiente variable a los servidores AIX

[aixservers:vars]
ansible_ssh_extra_args="-T"

Instalar con brew

SSHPASS

$ brew install sshpass
Error: No available formula with the name "sshpass"
We won't add sshpass because it makes it too easy for novice SSH users to
ruin SSH's security.
$ brew install https://raw.githubusercontent.com/kadwanev/bigboybrew/master/Library/Formula/sshpass.rb

Exportar la variable PYTHONPATH

PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH

Agregar la siguientes líneas al archivo .vimrc o /etc/vimrc

set autoindent
set tabstop=2
set shiftwidth=2
autocmd FileType yaml setlocal ai ts=2 sw=2 et
autocmd FileType yml setlocal ai ts=2 sw=2 et

let &t_SI .= "\<Esc>[?2004h"
let &t_EI .= "\<Esc>[?2004l"

inoremap <special> <expr> <Esc>[200~ XTermPasteBegin()

function! XTermPasteBegin()
  set pastetoggle=<Esc>[201~
  set paste
  return ""
endfunction
ansible all -i my_inventory -u miusuario -k -m user -a "name=miusuario update_password=always password={{ 'contrasñea_new' | password_hash ('sha512') }}" -K -b