Infra — Personal Infrastructure as Code

Questo repository contiene la configurazione Infrastructure as Code (IaC) utilizzata per gestire e mantenere allineate diverse macchine personali tramite Ansible.

L'obiettivo è avere una singola fonte di verità per:

• configurazione delle macchine
• pacchetti installati
• servizi di sistema
• configurazioni utente (dotfiles)

Il repository consente di gestire più sistemi operativi e profili macchina mantenendo una struttura modulare, riproducibile e idempotente.

---

Architettura del progetto

infra/
├── ansible/
│   ├── ansible.cfg
│   ├── site.yml
│   ├── inventory/
│   │   ├── hosts.yml
│   │   ├── group_vars/
│   │   └── host_vars/
│   ├── templates/
│   └── roles/
│
├── dotfiles/
│   ├── common/
│   ├── desktop/
│   ├── server/
│   ├── workstation/
│   ├── ikaros/
│   └── nymph/
│
├── scripts/
├── secrets/
└── README.md

Il repository è diviso in due componenti principali:

Componente	Scopo
ansible	provisioning e configurazione macchine
dotfiles	configurazioni utente versionate

---

Macchine gestite

Il repository modella attualmente tre tipologie di profilo e prepara due filoni workstation: Linux nativa e Windows + WSL.

Nota sullo stato attuale del playbook principale:

• ansible/site.yml applica oggi in automatico il profilo desktop su host Void Linux
• ansible/site.yml applica la workstation Linux nativa separando il layer dev comune dal layer host GNOME
• ansible/site.yml applica anche il ramo workstation_host_windows + workstation_dev_wsl per il modello Windows 11 + WSL
• ansible/site.yml applica anche il profilo ubuntu_server con baseline apt, systemd, dotfiles server e firewall UFW

Desktop

Sistema operativo:

• Void Linux

Sessioni desktop:

• ikaros: i3
• nymph: i3 + Sway + Hyprland con scelta sessione a login

Macchine:

• ikaros
• nymph

Queste macchine condividono la stessa configurazione base desktop e vengono mantenute allineate tramite Ansible.

Lo stato attuale del profilo desktop include, tra le altre cose:

• dotfiles comuni e desktop
• sessione i3 su tutti i desktop Void e sessioni Sway/Hyprland opzionali su nymph
• emptty con scelta sessione a login su nymph e default host-specific sugli altri desktop
• pacchetti Void Linux e servizi runit
• Flatpak con remoto Flathub
• GNOME Keyring e bootstrap della posta via script dedicato
• Waybar separata per compositor (config-sway.jsonc e config-hyprland.jsonc) con style.css condiviso
• kanshi su nymph per il profilo monitor Wayland, con workspace Sway deterministici: in dual monitor 1 resta su eDP-1 e 2-10 vanno su DP-1, mentre in laptop-only tutti tornano su eDP-1

---

Workstation

Sistemi operativi supportati:

• Ubuntu LTS nativa
• Windows 11 host + Ubuntu WSL

Desktop environment host Linux:

• GNOME

Macchine attuali:

• deadalus come workstation Ubuntu nativa
• supporto attivo per host Windows 11 + WSL tramite deadalus-win e deadalus-wsl

Questo profilo è pensato per sviluppo e lavoro, con separazione tra layer host e layer dev.

Il profilo workstation e agganciato al playbook principale e ora distingue:

• layer dev Ubuntu condiviso tra workstation Linux nativa e Ubuntu in WSL
• layer host Linux GNOME
• layer host Windows 11 con bootstrap WSL, remoting PSRP su HTTPS/5986, gestione app via winget e VS Code lato Windows
• layer WSL dedicato per sviluppo con systemd

Lo stato attuale del profilo workstation include:

• installazione pacchetti base Ubuntu via apt
• installazione e configurazione di Docker dal repository ufficiale
• gestione dei dotfiles workstation e rendering dei template dev condivisi
• installazione di Google Chrome, pacchetti Snap workstation e estensioni GNOME sul solo host Linux nativo
• configurazione del ramo Windows 11 host con app installate dal playbook via winget, tema scuro, taskbar ripulita e profilo predefinito di Windows Terminal impostato su Ubuntu
• preparazione del ramo WSL Ubuntu con systemd per il toolchain di sviluppo
• attivazione del firewall UFW sul solo host Linux nativo

Workflow Windows + WSL previsto:

Prima di eseguire il bootstrap Windows, apri PowerShell come amministratore e verifica la policy di esecuzione:

Get-ExecutionPolicy -List

Se necessario, abilita l'esecuzione degli script per l'utente corrente:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

Se Windows ha bloccato il file di bootstrap, sbloccalo esplicitamente:

Unblock-File .\scripts\bootstrap_windows_workstation.ps1

1. eseguire scripts/bootstrap_windows_workstation.ps1 su Windows come amministratore
2. riavviare Windows se richiesto dalle feature WSL
3. avviare Ubuntu WSL almeno una volta e completare la creazione dell'utente Linux
4. installare Ansible dentro WSL Ubuntu
5. lanciare il playbook da WSL su deadalus-wsl per configurare l'ambiente dev locale
6. lanciare da WSL anche il playbook su deadalus-win via psrp per configurare l'host Windows
7. usare VS Code con le estensioni Remote (WSL, SSH, Dev Containers) dal lato Windows

Per il remoting Windows il repository usa di default PSRP con Negotiate su HTTPS/5986. L'utente di default puo essere un MicrosoftAccount\..., con host, utente e password forniti via vault o extra vars.

---

Server

Sistema operativo:

• Ubuntu LTS

Configurazione:

• nessun ambiente grafico

Macchina:

• prometheus

Profilo orientato a servizi server e gestione di dotfiles dedicati.

Lo stato attuale del profilo server include:

• installazione pacchetti base Ubuntu via apt
• installazione e configurazione di Docker dal repository ufficiale
• abilitazione dei servizi systemd dichiarati in inventory/group vars
• copia dei dotfiles server e rendering dei template server
• attivazione del firewall UFW con regola SSH esplicita

Utente del profilo server:

• il profilo usa server_username, server_user_group e server_user_home definiti in ansible/inventory/group_vars/server.yml
• per default server_username eredita username, ma puo essere sovrascritto per tutti gli host server via inventory oppure a runtime con extra vars
• esempio override da CLI:

ansible-playbook ansible/site.yml --limit prometheus -e server_username=myuser

• se necessario puoi passare anche:

ansible-playbook ansible/site.yml --limit prometheus -e server_username=myuser -e server_user_group=mygroup -e server_user_home=/srv/myuser

---

Composizione della configurazione

La configurazione finale di una macchina è ottenuta combinando più livelli.

common configuration
+ OS configuration
+ profile configuration
+ host overrides

Esempio per ikaros:

common + void + desktop + ikaros

Esempio per nymph:

common + void + desktop + nymph

Questo approccio consente di:

• mantenere configurazioni condivise
• applicare override specifici per host
• evitare duplicazioni

---

Ruoli Ansible

I principali ruoli attualmente presenti sono:

Role	Descrizione
base	configurazione base comune
packages_void	installazione pacchetti su Void
packages_ubuntu	installazione pacchetti su Ubuntu
services_runit	gestione servizi runit
services_systemd	gestione servizi systemd
profile_desktop_common	bootstrap desktop Void condiviso
profile_desktop_i3	sessione desktop i3
profile_desktop_sway	sessione desktop Sway
profile_desktop_hyprland	sessione desktop Hyprland
profile_desktop_host	override desktop specifici per host
profile_workstation_dev_common	configurazione dev Ubuntu condivisa
profile_workstation_gnome	configurazione host workstation GNOME
profile_workstation_dev_wsl	configurazione WSL Ubuntu per sviluppo
profile_workstation_host_windows	configurazione host Windows 11 workstation
profile_server	configurazione server
dotfiles_common	distribuzione dotfiles comuni
dotfiles	distribuzione configurazioni utente

---

Stato attuale del playbook principale

Il playbook ansible/site.yml e attualmente composto da sei blocchi:

all:!workstation_host_windows -> dotfiles_common
void -> packages_void + services_runit + profile_desktop_common + profile_desktop_i3 + profile_desktop_sway + profile_desktop_hyprland + profile_desktop_host
workstation_dev_ubuntu -> packages_ubuntu + services_systemd + profile_workstation_dev_common
workstation_host_linux -> profile_workstation_gnome
workstation_dev_wsl -> packages_ubuntu + services_systemd + profile_workstation_dev_common + profile_workstation_dev_wsl
workstation_host_windows -> profile_workstation_host_windows
ubuntu_server -> packages_ubuntu + services_systemd + profile_server

Questo significa che, allo stato attuale:

• i desktop Void (ikaros, nymph) restano il target operativo piu completo
• la workstation Ubuntu (deadalus) e gestita separando ambiente dev e layer host GNOME
• il ramo Windows + WSL e predisposto con bootstrap PowerShell e play Windows/WSL dedicati
• il server Ubuntu (prometheus) e gestito con pacchetti, servizi, dotfiles server e firewall

Dotfiles

La directory dotfiles/ contiene le configurazioni utente versionate.

dotfiles/
├── common
├── desktop
├── server
├── workstation
├── ikaros
└── nymph

Le configurazioni sono applicate tramite Ansible e organizzate per livelli:

Livello	Scopo
common	configurazioni condivise
profile	configurazioni per tipo macchina
host	override specifici

---

Requisiti

Per utilizzare il repository sono necessari:

• Python 3
• Ansible
• ansible-lint
• yamllint
• shellcheck
• collection definite in ansible/collections/requirements.yml
• accesso locale o SSH alle macchine target, in base a come e definito l'inventory

Installazione base:

python3 -m pip install ansible ansible-lint yamllint shellcheck-py
ansible-galaxy collection install -r ansible/collections/requirements.yml

Gestione segreti:

• il repository supporta il caricamento opzionale di secrets/vault.yml
• il repository supporta anche secrets/vault.local.yml per override locali non versionati
• secrets/vault.yml.example funge da template/esempio
• se secrets/vault.yml non e presente, il playbook continua comunque senza caricare variabili locali opzionali
• se secrets/.vault_pass esiste viene usato automaticamente per sbloccare i vault; altrimenti Ansible richiede la password in modo interattivo

---

Utilizzo

Eseguire il playbook principale:

ansible-playbook ansible/site.yml

Allo stato attuale questo comando:

• distribuisce i dotfiles comuni a tutti gli host
• per gli host Void applica bootstrap desktop condiviso, sessioni i3/Sway/Hyprland e override specifici per host
• per workstation_dev_ubuntu applica pacchetti Ubuntu, servizi systemd e profilo dev comune
• per workstation_host_linux applica il layer host Linux GNOME
• per workstation_dev_wsl applica pacchetti Ubuntu, servizi systemd, profilo dev comune e tweak WSL dedicati
• per workstation_host_windows applica il layer host Windows 11 via PSRP
• per gli host ubuntu_server applica pacchetti Ubuntu, servizi systemd, profilo server, UFW, dotfiles e template dedicati
• non riavvia automaticamente emptty; le modifiche al display manager vanno applicate manualmente da SSH o da una TTY separata
• carica secrets/vault.yml solo se presente
• carica secrets/vault.local.yml solo se presente, dopo vault.yml, cosi gli override locali hanno precedenza

Per validare prima di applicare:

ansible-playbook ansible/site.yml --syntax-check
ansible-playbook ansible/site.yml --limit ikaros --check --diff
ansible-playbook ansible/site.yml --limit nymph --check --diff
ansible-playbook ansible/site.yml --limit deadalus --check --diff
ansible-playbook ansible/site.yml --limit deadalus-wsl --check --diff
ansible-playbook ansible/site.yml --limit prometheus --check --diff
ansible-lint ansible/site.yml
ansible-lint ansible/roles
yamllint ansible/

Per testare un override dell'utente server senza modificare l'inventory:

ansible-playbook ansible/site.yml --limit prometheus --check --diff -e server_username=myuser

Per validazioni piu mirate:

ansible-playbook ansible/site.yml --limit <host> --tags <tag1>,<tag2> --check --diff
ansible-playbook ansible/site.yml --limit <host> --start-at-task "<task name>" --check --diff
ansible-lint ansible/roles/<role>
yamllint ansible/path/to/file.yml

Se tocchi Waybar, valida anche i config JSONC con:

python3 -m json.tool dotfiles/desktop/.config/waybar/config-sway.jsonc >/dev/null
python3 -m json.tool dotfiles/desktop/.config/waybar/config-hyprland.jsonc >/dev/null

---

Bootstrap di una nuova macchina

Una nuova macchina può essere inizializzata con i seguenti passaggi:

git clone <repo>
cd <repo-dir>
ansible-galaxy collection install -r ansible/collections/requirements.yml
ansible-playbook ansible/site.yml

Dopo l'esecuzione del playbook la macchina verra configurata secondo il profilo definito e i ruoli attualmente orchestrati.

Per il flusso mail desktop esiste inoltre uno script dedicato:

scripts/bootstrap_mail.sh

Lo script si occupa del bootstrap dei secret nel keyring, del primo sync con mbsync e dell'inizializzazione di mu usando la configurazione mail generata dai template.

Se modifichi questo script, valida almeno con:

sh -n scripts/bootstrap_mail.sh
shellcheck scripts/bootstrap_mail.sh

---

Filosofia del progetto

Il repository segue alcuni principi chiave:

• Infrastructure as Code
• configurazione dichiarativa
• idempotenza
• ambienti riproducibili
• separazione tra configurazione sistema e configurazione utente

Questo consente di ricreare qualsiasi macchina partendo esclusivamente dal repository.

---

Roadmap

Possibili evoluzioni future:

• hardening sicurezza server
• configurazione backup
• testing automatico playbook
• integrazione CI
• supporto ad altre distribuzioni Linux

---

Licenza

Questo progetto è distribuito sotto licenza LGPL-3.0.