hlab/ansible/playbooks
Fabio Sinibaldi 8af5c6bd92 Rootless image 2026-09-23 19:12:17 +02:00
..
roles Rootless image 2026-09-23 19:12:17 +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 l’utente 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 l’utente da utilizzare per connettersi ed esguire il playbook con l’opzione -e’. L’opzione ‘-K’ invece permette di chiedere la password dell’utente 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 l’esecuzione. In caso contrario viene riportata solo la chiave pubblica ed e’ compito dell’utente 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 : - l’utente 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: - L’utente 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