Ansible – My Shitty Code

Ansible: Handling Sudo Password with Homebrew

Shitty Author — Wed, 04 Sep 2024 15:45:24 +0000

Problem

When using the Ansible playbook to run Homebrew-related modules, it will prompt for a sudo password where necessary on specific tasks. For example, using the community.general.homebrew_cask module to (un)install the apps under /Applications directory will prompt for a sudo password on each app.

It is not possible to preemptively prompt for a sudo password before running the Ansible playbook:

# Does not work!
sudo -v

ansible-playbook main.yml

It is also not possible to perform clever tricks like this to extend the sudo timeout:

# Does not work, too!
while true; do sudo -n true; sleep 60; kill -0 "$$" || exit; done 2>/dev/null &

ansible-playbook main.yml

Root Cause

This is not an Ansible problem. This behavior exists because Homebrew always clears the sudo password cache to prevent privilege escalation attacks [link 1] [link 2].

The upside is the community.general.homebrew_cask module provides a variable for passing in a sudo password, for example:

- name: Install/Upgrade cask packages
  community.general.homebrew_cask:
    name: '{{ item }}'
    state: upgraded
    greedy: true
    install_options: force,no-quarantine
    sudo_password: "{{ ansible_become_pass }}"
  loop: '{{ homebrew_cask_packages_present }}'

Solution

While storing passwords in a file is not ideal, it prevents these Ansible tasks from prompting for a sudo password each time. The ansible-vault command can be used to store the password (and other secrets) securely.

First, create an encrypted file.

ansible-vault create vault.yml

You will be prompted for a new vault password. Once provided, enter the following into the file.

ansible_become_pass: [YOUR_SUDO_PASSWORD]

Now, your encrypted file should be created in the location you specified with the proper permission set:

$ ls -la
total 88
drwxr-xr-x@ 18 shitty.author  staff   576 Sep  4 09:06 .
drwxr-xr-x  12 shitty.author  staff   384 Jun 27 12:47 ..
-rw-r--r--   1 shitty.author  staff    99 Mar  1  2024 .ansible-lint
-rw-r--r--   1 shitty.author  staff   193 Mar 19 08:57 .editorconfig
drwxr-xr-x  16 shitty.author  staff   512 Sep  4 09:06 .git
-rw-r--r--   1 shitty.author  staff   243 Mar  1  2024 .gitignore
drwxr-xr-x   8 shitty.author  staff   256 Sep  4 09:35 .idea
drwxr-xr-x   6 shitty.author  staff   192 Mar  4  2024 .venv
-rw-r--r--   1 shitty.author  staff    72 Mar  1  2024 .yamllint
-rw-r--r--   1 shitty.author  staff  1079 Mar  1  2024 LICENSE.md
-rw-r--r--@  1 shitty.author  staff  1796 Sep  4 08:39 README.md
-rw-r--r--   1 shitty.author  staff   381 Mar  1  2024 ansible.cfg
-rw-r--r--   1 shitty.author  staff    65 Mar  1  2024 inventory.yml
-rw-r--r--@  1 shitty.author  staff  1450 Sep  4 09:06 main.yml
drwxr-xr-x  16 shitty.author  staff   512 Aug 12 09:32 roles
-rw-------@  1 shitty.author  staff   484 Sep  4 09:01 vault.yml

If you open vault.yml, the content should look gibberish.

$ cat vault.yml                                                                                  ✔
$ANSIBLE_VAULT;1.1;AES256
62343635616463643935613965336336323366653565646137616238663266633936363463611364
6139353639666163323066653733663763323236663361380a646264623465616461646637315661
34396438316137383130366330313431653336396435656562356430333762373866663234383230
6265656164346531660a626431383230326664393839316131626330353562363164313439661863
31343363323236333531303139396662386531626165663732386233626538646338333133375936
6535626465393233386634393934623438393535626365313132

In the Ansible playbook, specify vault.yml under vars_files.

---
- name: My Playbook
  hosts: all
  vars_files:
    - vault.yml
  roles:
    - ...

Finally, run the Ansible playbook with the –ask-vault-pass option, where you will be prompted for the vault password once before Ansible executes the playbook.

ansible-playbook main.yml --ask-vault-pass

Now, you will not be prompted for a sudo password every time Homebrew-related tasks run.

The post Ansible: Handling Sudo Password with Homebrew appeared first on My Shitty Code.

Ansible: Handling Multiple Hosts via SSH

Shitty Author — Wed, 19 May 2021 13:28:47 +0000

PROBLEM

To run Ansible playbook in multiple hosts via SSH.

SOLUTION

Configuring SSH environment

Ensure SSH keypair exists on the current machine (ex: ~/.ssh/id_rsa for private key and ~/.ssh/id_rsa.pub for public key). If you do not have one, create one:

ssh-keygen

Copy the public key (ex: ~/.ssh/id_rsa.pub) to each remote host’s ~/.ssh/authorized_keys. If this file doesn’t exist, create it.

Ensure the current machine’s .ssh/ directory and file have correct permission.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

In the current machine’s /etc/hosts, add all remote hosts.

127.0.0.1      localhost  # current machine
192.168.1.100  donkeykong # remote host 1
192.168.1.200  supermario # remote host 2

In each remote host, enable the remote login and grant yourself the access to this service.

Enabling Remote Login on Mac

Test SSH connection to remote host to ensure they work first before working on Ansible playbook.

ssh user@donkeykong
ssh user@supermario

Creating Ansible Playbook

Create ansible.cfg and define the location of inventory file.

[defaults]
inventory = inventory.yml

Create inventory.yml and define both localhost and remote hosts.

all:
  hosts:
    localhost:
      ansible_connection: local
    donkeykong:
      ansible_user: user
      ansible_ssh_private_key_file: ~/.ssh/id_rsa
    supermario:
      ansible_user: user
      ansible_ssh_private_key_file: ~/.ssh/id_rsa

Run a test to ensure the connection to remote hosts are successful.

ansible all -i inventory.yml -m ping

If successful, the output looks something like this:

localhost | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
donkeykong | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
supermario | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Create main.yml with a very simple task.

- name: all-hosts
  hosts: all
  tasks:
    - name: Capture current dir
      shell: pwd
      register: output

    - name: Display output
      debug: msg='{{ output.stdout }}'

Run the playbook.

ansible-playbook main.yml

If successful, the output looks something like this:

PLAY [all-hosts] *******************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************
ok: [localhost]
ok: [donkeykong]
ok: [supermario]

TASK [Capture current dir] *********************************************************************************************
changed: [localhost]
changed: [donkeykong]
changed: [supermario]

TASK [Display output] **************************************************************************************************
ok: [localhost] => {
    "msg": "/Users/user/myshittycode"
}
ok: [donkeykong] => {
    "msg": "/Users/user"
}
ok: [supermario] => {
    "msg": "/Users/user"
}

PLAY RECAP *************************************************************************************************************
donkeykong                 : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
supermario                 : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Controlling the Hosts

Sometimes, you want finer controls on what tasks to be ran in certain hosts.

To run in just one host (ex: donkeykong):

- name: one-host
  hosts: donkeykong
  tasks:
    - ...

To run in all remote hosts except localhost:

- name: all-hosts-except-localhost
  hosts: all:!localhost
  tasks:
    - ...

The post Ansible: Handling Multiple Hosts via SSH appeared first on My Shitty Code.