hlab/ansible/playbooks
Fabio Sinibaldi e876f32de1 Parametric SMTP secure flag 2026-09-15 17:16:50 +02:00
..
roles Parametric SMTP secure flag 2026-09-15 17:16:50 +02:00
templates fix item.key reference 2026-07-24 15:00:01 +02:00
README.md Update playbook docs 2026-09-14 17:04:48 +02:00
authentik.yaml Parametric become_exe 2026-07-30 18:03:16 +02:00
bootstrap.yaml Parametric become_exe 2026-07-30 18:03:16 +02:00
borg_backups.yaml Rename borg playbook file as borg_backups 2026-09-09 17:32:49 +02:00
forgejo.yaml Parametric become_exe 2026-07-30 18:03:16 +02:00
nextcloud.yaml Initial nextcloud playbook 2026-07-30 18:04:24 +02:00
pangolin.yaml fix role and task invocations 2026-09-15 14:41:21 +02:00
static_nginx_page.yaml Parametric become_exe 2026-07-30 18:03:16 +02:00
tests.yaml testing purposes 2026-07-27 17:21:41 +02:00
vpn_server.yaml Parametric become_exe 2026-07-30 18:03:16 +02:00

README.md

Playbooks

Qui vengono riportati i playbook disponibili, descrizione e utilizzo. NB Ci si aspetta che i playbook siano idempotenti. In caso contrario e importante riportarlo nella documentazione corrente.

Summary

Bootstrap

Implementa la configurazione di base di un nodo per poter essere gestito dagli altri playbook, in particolare : - crea lutente ansible - registra le chiavi ssh degli utenti configurati

Target Hosts : all

Parametri

Il playbook si aspetta le seguenti variabili

ansible_authorized_keys:
    - label : <MY LABEL>
      key: <MY>

Chiamata

Per lanciare il playbook e necessario specificare lutente da utilizzare per connettersi ed esguire il playbook con lopzione -e. Lopzione -K invece permette di chiedere la password dellutente remoto

 ansible-playbook -i inventories/<INVENTORY>.yaml  playbooks/bootstrap.yaml -e 'ansible_user=<SUDO USER>' -K

VPN Server

Istanzia un server Wireguard abilitando il tunneling del traffico.

Target Hosts : wireguard_server

Generazione chiavi e configurazioni dei Peer

Genera in /wg_clients/< ANSIBLE_HOSTNAME >/ i file di configurazione per i peer configurati.

NB Il playbook e a conoscenza della chiave privata del peer solo se e stato necessario generarla durante lesecuzione. In caso contrario viene riportata solo la chiave pubblica ed e compito dellutente inserire la chiave privata.

Il playbook genera le chiavi nei seguenti casi : - nessuna chiave pubblica e stata fornita e il peer non e gia configurato sul server - Force Regeneration = True

Parametri

Il playbook si aspetta le seguenti variabili

wg_interface: wg0
wg_port: 51820
wg_server_address: 192.168.101.1/32

wg_peers:  
  - name: <MY LABEL>
    # publicKey: 
    ip: "192.168.101.4/32"
    allowedIPs : 
      - "192.168.101.0/24"
      - "10.22.0.0/16"
    forceRegeneration: False

Pangolin

Il playbook installa docker e docker compose. Attraverso docker compose vengono poi lanciati i container per pangolin, gerbil e traefik.

Il playbook utilizza : - geerlingguy.docker attraverso ansible galaxy - Il ruolo prepare_node - Il ruolo pangolin preso da pangolin-ansible-terraform

I parametri attesi dal playbook sono quelli definiti nei ruoli da cui dipende.

Forgejo

Il playbook installa docker e docker compose. Attraverso docker compose vengono poi lanciati container per forgejo e newt_client.

Il playbook utilizza : - geerlingguy.docker attraverso ansible galaxy - I ruoli forgejo e newt_client

Authentik

Il playbook installa docker e docker compose. Attraverso docker compose vengono poi lanciati container per authentik e newt_client.

Il playbook utilizza : - geerlingguy.docker attraverso ansible galaxy - ax-bzh.authentik attraverso ansible galaxy - Il ruolo newt_client

Nextcloud

Il playbook installa docker e docker compose. Attraverso docker viene poi lanciato il container per Nextcloud AIO e newt_client.

Il playbook utilizza : - geerlingguy.docker attraverso ansible galaxy - I ruoli newt_client e nextcloud_aio

Static Nginx Page

Il playbook installa docker e docker compose. Attraverso docker viene poi lanciato il container per Nginx e newt_client.

Il playbook utilizza : - geerlingguy.docker attraverso ansible galaxy - I ruoli newt_client e nginx

Borg Backups

Il playbook configura sia i client che il server per i backup effettuati con borg. I client vengono risolti dinamicamente verificando la presenza della seguente configurazione in esempio:

configure_borg_client: True
borg_repos:
  - name: test
    borg_passphrase: "dummy_secret"
    paths_to_backup: 
      - "/home/{{ ansible_user }}"
      - "/proc/version"

Per ogni client vengono configurati : - lutente e relative credenziali per connettersi al borg server - Un servizio systemd borg_backup.service e relativo timer borg_backup.timer per eseguire il backup - Uno script che esegue effettivamente il backup “/home/{{borg_user}}/backup_script.sh” verso “ssh://{{ borg_user }}@{{ borg_backup_server }}/./”

Sul server vengono configurati: - Lutente con cui eseguire borg service - Le credenziali attese utilizzate dai vari client e i rispettivi path permessi per eseguire i report.

Sul server i permessi concessi ai vari client vengono limitati definendo su /home/{{borg_user}}/.ssh/authorized_keys le limitazioni di path (accesso solo al proprio repo) e di operation (solo “borg serve”) con la seguente istruzione :

command=\"cd {{ borg_pool }}/{{ item.host }};borg serve --restrict-to-path {{ borg_pool }}/{{ item.host }}\",restrict

E possibile configurare il server per servire borg anche con altre credenziali e path, per casi non coperti dal playbook (e.g. borg backups usato direttamente da Nextcloud AIO) attraverso il seguente attributo:

borg_auth_users:
  - host: fabotest
    key: "ssh-rsa ********"

Il playbook utilizza il role borg