# 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 ```text 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` prepara anche il ramo `windows_workstation_host` + `workstation_dev_wsl` per il modello Windows + 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 host + Ubuntu WSL Desktop environment host Linux: - GNOME Macchine attuali: - `deadalus` come workstation Ubuntu nativa - supporto strutturale preparato per futuri host Windows + 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 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 - preparazione del ramo Windows host con app installate dal playbook via `winget` - 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: ```powershell Get-ExecutionPolicy -List ``` Se necessario, abilita l'esecuzione degli script per l'utente corrente: ```powershell Set-ExecutionPolicy -Scope CurrentUser RemoteSigned ``` Se Windows ha bloccato il file di bootstrap, sbloccalo esplicitamente: ```powershell 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: ```bash ansible-playbook ansible/site.yml --limit prometheus -e server_username=myuser ``` - se necessario puoi passare anche: ```bash 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. ```text common configuration + OS configuration + profile configuration + host overrides ``` Esempio per `ikaros`: ```text common + void + desktop + ikaros ``` Esempio per `nymph`: ```text 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 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: ```text 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. ```text 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 `community.general` - accesso locale o SSH alle macchine target, in base a come e definito l'inventory Installazione base: ```bash python3 -m pip install ansible ansible-lint yamllint shellcheck-py ansible-galaxy collection install community.general ``` 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: ```bash 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 gli host `ubuntu_workstation` applica pacchetti Ubuntu, servizi systemd, profilo workstation GNOME, UFW, dotfiles, Snap e template dedicati - 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: ```bash 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 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: ```bash ansible-playbook ansible/site.yml --limit prometheus --check --diff -e server_username=myuser ``` Per validazioni piu mirate: ```bash ansible-playbook ansible/site.yml --limit --tags , --check --diff ansible-playbook ansible/site.yml --limit --start-at-task "" --check --diff ansible-lint ansible/roles/ yamllint ansible/path/to/file.yml ``` Se tocchi `Waybar`, valida anche i config JSONC con: ```bash 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: ```bash git clone cd ansible-galaxy collection install community.general 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: ```bash 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: ```bash 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**.