Ansible è un tool di gestione dei sistemi operativi, nei precedenti articoli abbiamo visto come abilitare la gestione di alcuni server Linux e come impartire un comando. Vediamo in questo articolo come ottenere informazioni dai server gestiti. A volte è necessario recuperare alcuni parametri di configurazione di un sistema.

La configurazione di base per il setup di Ansible la potete trovare negli articoli precedenti, in questo invece vediamo alcuni tipi di playbook.

L’intento dell primo playbook è di restituire l’output del comando /usr/bin/date, che dovrebbe mostrarci il giorno e l’ora corrente.

- hosts: all
  user: ansible_service
  tasks:
   - name: Get clock
     shell: /usr/bin/date
     changed_when: False
     register: date
   - debug:
      msg: "{{ date.stdout }}"

Il playbook viene lanciato su alcuni server. La maggior parte dei sistemi restituisce un messaggio in cui è riportato il giorno e l’orario.

Tuttavia nel caso del server con IP 192.168.217.11 (Linux Mint) si può notare come l’esecuzione del comando restituisce un errore: “/bin/sh: 1: /usr/bin/date: not found“, l’estratto è interpretabile in maniera semplice: il comando /usr/bin/date non esiste sul sistema in questione. Infatti su server Linux Mint, /usr/bin/date non è disponibile.

Da ciò si può capire che l’uso dei comandi shell non è consigliato perchè questi comandi non sono disponibili su tutte le distribuzioni Linux. Alternativamente possiamo usare dei “costrutti” incorporati in Ansible chiamati “built-in” fact (traducibile con dati integrati).

Si può ottenere una lista dei fact (e relativi valori) usando il comando

ansible localhost -m ansible.builtin.setup

Questo mostrerà a video tutti i dati disponibili, nel caso specifico quelli del localhost. Nel mio caso più di 1000 righe di output. Fra questi, ce ne è uno che può essere usato per recuperare la data e l’ora; si tratta di ansible_date_time.iso8601.

Per evitare un errore simile a quello riscontrato con Linux Mint, abbiamo aggiunto una condizione chiamata when che ci permette di recuperare il dato dal sistema solo se esso è definito.

Riscriveremo il nostro playbook in questo modo:

- hosts: all
  user: ansible_service
  tasks:
   - name: Print day and time
     ansible.builtin.debug:
       msg: Host {{ inventory_hostname }} {{ ansible_date_time.iso8601 }}
     when: ansible_date_time.iso8601 is defined

Una nota: l’orario restituito essendo di tipo ISO 8601 è riportato col fuso orario UTC, per cui bisogna aggingere un’ora quando il fuso è CET oppure 2 ore quando è CEST.

Nell’esempio successivo invece desideriamo riavviare il servizio ntpd, quello che tipicamente mantiente l’ora sincronizzata.

Il playbook è abbastanza semplice:

- hosts: all
  user: ansible_service
  become: yes
  become_user: root
  tasks:
    - name: restart service ntp
      service:
       name: ntpd
       state: restarted

Tuttavia l’esecuzione è alquanto “disastrosa”

Purtroppo il servizio ntpd non è disponibile su nessuna delle macchine. Questo ci obbliga a modificare lo script. Sulle più recenti distribuzioni come le derivate da RHEL 8 e SUSE 15, il deamon responsabile della sincronizzazione dell’orologio via rete si chiama chrony. Spesso non è attivo di default.

Il deamon di sincronizzazione non è avviato.

Abbiamo dunque lanciato il nuovo playbook:

- hosts: all
  user: ansible_service
  become: yes
  become_user: root
  tasks:
    - name: restart service time synch
      service:
       name: chronyd
       state: restarted

Il riepilogo ci mostra che solo l’host Linux Mint riporta la mancata esecuzione del task. Questo perchè su quell’host il servizio chrony non è disponibile. Ma su gli altri host cosa è successo? Il servizio chronyd è stato riavviato e questo ha provocato un cambio di stato del sistema per cui abbiamo un changed=1.

Abbiamo creato un playbook per recuperare lo stato del servizio:

- hosts: all
  user: ansible_service
  tasks:
   - name: checking service status
     command: systemctl status chronyd
     changed_when: False
     register: result
     ignore_errors: yes

   - name: display results
     debug: var=result.stdout

Questo playbook ci consente di capire se sul sistema è attivo chrony oppure un altro servizio per sincronizzare l’orologio come il vecchio ntpd.

In questo caso abbiamo questo risultato:

Toshiba 4TB Canvio Basics Portable External Hard Drive,USB 3.2. Gen 1, Black (HDTB440EK3AA)

Dall’esecuzione del playbook, è possibile scoprire che il servizio chrony non sia attivo sull’host 192.168.217.14.

Concludiamo col precedente playbook questa guida su come ottenere informazioni usando Ansible, nei successivi articoli incontreremo nuove sfide.

Di valent

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *