fscotto/infra
1
0
Fork 0
mirror of https://github.com/fscotto/infra.git synced 2026-07-29 16:20:01 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
7b0e02bc9b5e6f5409c84c871fa112baa22c75bc
infra/README.md
Fabio Scotto di Santolo 7b0e02bc9b Migrate ikaros to Fedora Workstation
2026-07-19 14:50:46 +02:00

22 KiB
Raw Blame History

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/
│   ├── fedora/
│   ├── ubuntu/
│   ├── server/
│   ├── workstation/
│   ├── workstation_host_linux/
│   ├── workstation_dev_wsl/
│   ├── 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, con i filoni workstation Linux nativa e WSL. La nuova direzione del repository separa tre assi indipendenti:

common user environment
+ host-specific platform
+ role-specific software
+ independently selectable desktop
+ host hardware overrides

Matrice target:

Host Platform Role Desktop
ikaros Fedora Personal workstation GNOME
nymph Fedora Desktop laptop GNOME
void-reference Void Linux Lab/reference Current preserved desktop profile

Regola operativa:

ikaros must be boring
nymph is allowed to break

ikaros usa Fedora Workstation/GNOME come desktop personale stabile; nymph usa lo stesso target Fedora Workstation/GNOME come laptop. I gruppi legacy void e desktop restano alias di compatibilita per eventuali host Void futuri mentre i nuovi assi sono platform_*, role_* e desktop_*.

Prima di una migrazione reale degli host e consigliato creare uno snapshot logico, per esempio:

git switch -c refactor/platform-role-desktop
git tag void-desktop-before-platform-refactor

Nota sullo stato attuale del playbook principale:

  • ansible/site.yml applica oggi in automatico GNOME su Fedora e Niri su FreeBSD
  • ansible/site.yml applica anche il ramo workstation_dev_wsl per il modello dev in WSL
  • ansible/site.yml applica anche il profilo ubuntu_server con baseline apt, systemd, dotfiles server e firewall UFW

Desktop

Target operativi:

  • ikaros: Fedora Workstation + GNOME, desktop personale stabile/floating.
  • nymph: Fedora Workstation + GNOME, laptop desktop con dotfiles desktop condivisi e GNOME lasciato al default Fedora.

Il profilo Void desktop resta disponibile come modello riutilizzabile per host futuri. desktop_environment continua a selezionare in modo esclusivo minimal, xfce oppure kde per i desktop Void; Niri, GNOME e Cinnamon sono profili desktop indipendenti via gruppi desktop_niri, desktop_gnome e desktop_cinnamon.

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

  • dotfiles comuni e desktop
  • sessioni sway e Hyprland per eventuali host Void in modalita minimal
  • KDE Plasma con applicazioni KDE curate e SDDM disponibile come alternativa esclusiva
  • XFCE con pannello, keybinding, terminale, tema e workspace dichiarativi, LightDM e Thunderbird come client grafico principale
  • emptty con default host-specific in modalita minimal, con session file Wayland esposti per sway e hyprland
  • pacchetti Void Linux e servizi runit; le liste pacchetti Void desktop sono separate per criterio:
    • void_packages_base per il runtime sistema (init, kernel, audio core, networking, firewall, hw daemons)
    • desktop_common_packages per l'infrastruttura condivisa dalle modalita
    • desktop_minimal_packages per applicazioni GTK/XFCE e emptty
    • desktop_xfce_packages per XFCE, LightDM e le relative integrazioni
    • desktop_kde_packages per Plasma, SDDM e le applicazioni KDE equivalenti
    • desktop_sway_packages e desktop_hyprland_packages per i binari specifici di ciascuna sessione
  • turnstile per i servizi utente Void, incluso ssh-agent
  • ssh-agent con socket stabile condiviso tra shell e SSH in ~/.local/state/ssh-agent/socket
  • Emacs e i relativi dotfile restano nel repo ma sono disabilitati di default tramite emacs_enabled: false
  • tmux con plugin gestiti da TPM al bootstrap del profilo desktop
  • Flatpak con remoto Flathub
  • GNOME Keyring e udiskie nella modalita minimale; KWallet e integrazione UDisks di Plasma nella modalita KDE
  • multi-monitor Void: sotto sway è gestito da kanshi; sotto Hyprland gli override monitor vivono in host_hyprland_dotfiles

Workstation

Sistemi operativi supportati:

  • Fedora Workstation nativa
  • Ubuntu WSL

Desktop environment host Linux:

  • GNOME

Macchine attuali:

  • deadalus-wsl come ambiente dev Ubuntu in WSL sulla workstation Windows deadalus

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

Nel modello Ansible usato qui, un singolo inventory host puo appartenere intenzionalmente a piu gruppi e quindi ricevere piu play nello stesso run: l'associazione non e 1 host = 1 play, ma host + gruppi = layering finale.

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

  • layer dev Ubuntu condiviso tra WSL e server
  • layer dev Fedora nativo disponibile per host futuri
  • layer host Linux GNOME disponibile per host futuri
  • layer WSL dedicato per sviluppo con systemd

Per esempio, lo stesso host Linux puo stare in workstation_host_linux e in workstation_dev_fedora, a seconda del layering che vuoi comporre.

Lo stato attuale del profilo workstation include:

  • installazione pacchetti base Ubuntu via apt
  • installazione pacchetti base Fedora via dnf per il ramo workstation nativo
  • installazione e configurazione di Docker dal repository ufficiale
  • gestione dei dotfiles workstation e rendering dei template dev condivisi
  • installazione di Google Chrome su Fedora, VS Code su Fedora via repository RPM Microsoft, IntelliJ IDEA Ultimate su Fedora via COPR RPM, e applicazioni workstation residue su Fedora via Flatpak
  • estensioni GNOME sul solo host Linux nativo
  • preparazione del ramo WSL Ubuntu con systemd per il toolchain di sviluppo
  • attivazione del firewall firewalld su Fedora

Workflow WSL previsto:

  1. avviare Ubuntu WSL almeno una volta e completare la creazione dell'utente Linux
  2. installare Ansible dentro WSL Ubuntu
  3. lanciare il playbook da WSL su deadalus-wsl per configurare l'ambiente dev locale
  4. usare VS Code con le estensioni Remote (WSL, SSH, Dev Containers) dal lato Windows

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, incluso il docker-compose.yml dello stack servizi
  • attivazione del firewall UFW con regola SSH esplicita
  • apertura delle porte Syncthing 22000/tcp, 22000/udp e 21027/udp, lasciando la GUI non esposta direttamente su UFW

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

Emacs è disabilitato di default. Per riattivare temporaneamente il deploy Emacs:

ansible-playbook ansible/site.yml --limit <host> --tags emacs -e emacs_enabled=true

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

common configuration
+ platform configuration
+ role configuration
+ desktop configuration
+ host overrides

Esempi correnti:

ikaros -> common + platform_fedora + role_personal_workstation + graphical_desktop + desktop_gnome + ikaros
nymph  -> common + platform_fedora + graphical_desktop + desktop_gnome + nymph

Questo approccio consente di:

  • mantenere configurazioni condivise
  • applicare override specifici per host
  • evitare duplicazioni
  • riutilizzare il profilo Void corrente su un host futuro assegnandolo a platform_void + graphical_desktop + role_lab + desktop_hyprland

Ruoli Ansible

I principali ruoli attualmente presenti sono:

Role Descrizione
base configurazione base comune
packages_void installazione pacchetti su Void
packages_mint installazione pacchetti su Linux Mint via APT
packages_freebsd installazione pacchetti su FreeBSD via pkg
packages_ubuntu installazione pacchetti su Ubuntu
packages_fedora installazione pacchetti su Fedora
services_runit gestione servizi runit
services_systemd gestione servizi systemd
services_freebsd gestione servizi FreeBSD rc.conf/rc.d
profile_desktop_common bootstrap desktop Void condiviso
profile_desktop_gnome dotfiles desktop condivisi per Fedora/GNOME
profile_desktop_sway sessione desktop sway / SwayFX (Wayland)
profile_desktop_hyprland sessione desktop Hyprland (Wayland)
profile_desktop_niri_freebsd adattamenti FreeBSD per Niri
profile_desktop_cinnamon impostazioni Cinnamon circoscritte
profile_desktop_host override desktop specifici per host
profile_personal_workstation layer stabile per workstation personale
profile_lab layer sperimentale/lab
profile_workstation_dev_common configurazione dev workstation condivisa
profile_workstation_gnome configurazione host workstation GNOME
profile_workstation_dev_wsl configurazione WSL Ubuntu per sviluppo
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 blocchi per asse:

all -> dotfiles_common
platform_void -> packages_void + services_runit
platform_void & graphical_desktop -> profile_desktop_common + profile_desktop_sway + profile_desktop_hyprland + profile_desktop_kde + profile_desktop_xfce + profile_desktop_host
platform_mint -> packages_mint + services_systemd
platform_mint & role_personal_workstation -> profile_personal_workstation
platform_mint & desktop_cinnamon -> profile_desktop_cinnamon
platform_freebsd -> packages_freebsd + services_freebsd
platform_freebsd & role_lab -> profile_lab
platform_freebsd & desktop_niri -> profile_desktop_niri_freebsd
platform_fedora -> packages_fedora + services_systemd
platform_fedora & role_personal_workstation -> profile_personal_workstation
platform_fedora & desktop_gnome -> profile_desktop_gnome
workstation_dev_fedora -> 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
ubuntu_server -> packages_ubuntu + services_systemd + profile_server

Questo significa che, allo stato attuale:

  • ikaros riceve Fedora Workstation/GNOME come target desktop personale stabile
  • nymph riceve Fedora Workstation/GNOME come target laptop
  • il profilo Void resta selezionabile tramite platform_void + graphical_desktop per host futuri
  • il ramo WSL (deadalus-wsl) e predisposto con play dev dedicato
  • il server Ubuntu (prometheus) e gestito con pacchetti, servizi, dotfiles server e firewall
  • lo stack container server include navidrome, postgres, gitea, nginx-proxy-manager e syncthing, con GUI Syncthing raggiungibile tramite la rete Docker web

Dotfiles

La directory dotfiles/ contiene le configurazioni utente versionate.

dotfiles/
├── common
├── desktop
├── server
├── fedora
├── ubuntu
├── workstation
├── workstation_host_linux
├── workstation_dev_wsl
├── 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.gpg esiste viene usato automaticamente per sbloccare i vault tramite gpg; in alternativa resta supportato secrets/.vault_pass come fallback legacy locale; se nessuno dei due file esiste 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 platform_void applica pacchetti Void e servizi runit
  • per platform_void + graphical_desktop applica bootstrap desktop condiviso, sessioni sway/Hyprland/Niri e override specifici per host
  • per platform_mint e platform_freebsd applica solo host presenti esplicitamente in quei gruppi; nell'inventory principale iniziale questi gruppi sono vuoti
  • per platform_fedora applica pacchetti Fedora e servizi systemd
  • per workstation_dev_fedora applica il 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 gli host ubuntu_server applica pacchetti Ubuntu, servizi systemd, profilo server, UFW, dotfiles e template dedicati
  • non riavvia automaticamente il display manager; i passaggi tra emptty, LightDM e SDDM vanno applicati 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,nymph --check --diff
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-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
docker compose -f /opt/docker/server/docker-compose.yml config

Tag supportati dal playbook

Per vedere l'elenco reale aggiornato dei tag disponibili:

ansible-playbook ansible/site.yml --list-tags

Per attivare XFCE o KDE su un host, impostare rispettivamente desktop_environment: xfce o desktop_environment: kde nei relativi host_vars ed eseguire prima un dry run. Il primo play configura il profilo ma, se un altro display manager e ancora attivo, rinvia il cambio. Da una TTY o sessione SSH separata, con la sessione grafica chiusa, applicare quindi il passaggio esplicito:

ansible-playbook ansible/site.yml --limit <host> -e desktop_allow_display_manager_switch=true

La stessa procedura vale per ogni passaggio tra minimal, xfce e kde. Gli XML XFCE sono autorevoli: applicare i relativi aggiornamenti mentre XFCE e disconnesso evita che xfconfd ripristini lo stato in memoria.

Allo stato attuale ansible/site.yml espone questi tag:

Tag Scopo Ambito principale
always pre-task sempre eseguiti, inclusi caricamento vault e validazioni preliminari common
dotfiles distribuzione/configurazione dotfiles tutti i profili
dotfiles:common dotfiles comuni condivisi common, workstation, server
dotfiles:desktop dotfiles desktop desktop Void
dotfiles:host override host-specifici desktop desktop Void
dotfiles:server dotfiles dedicati al profilo server server
dotfiles:workstation dotfiles dedicati alle workstation workstation Linux, WSL
emptty gestione display manager emptty desktop Void
display-manager selezione protetta tra emptty, LightDM e SDDM desktop Void
kde profilo KDE Plasma e relativa pulizia desktop Void
xfce profilo XFCE, LightDM e relativa pulizia desktop Void
cinnamon impostazioni Cinnamon circoscritte Linux Mint desktop
gnome configurazione host GNOME workstation host Linux, parte desktop
sway sessione/configurazione sway / SwayFX (Wayland) desktop Void
hyprland sessione/configurazione Hyprland (Wayland) desktop Void
niri sessione/configurazione Niri (Wayland) FreeBSD laptop
npm installazione pacchetti npm globali desktop Void, workstation Linux, WSL
nvidia componenti NVIDIA desktop desktop Void
packages installazione e aggiornamento pacchetti tutti i profili
services gestione servizi runit/systemd tutti i profili
vscode installazione/configurazione VS Code Fedora, host Linux
wsl bootstrap e configurazione WSL WSL

Esempi pratici:

ansible-playbook ansible/site.yml --limit nymph --tags dotfiles:desktop,niri --check --diff
ansible-playbook ansible/site.yml --limit ikaros --tags gnome --check --diff
ansible-playbook ansible/site.yml --limit prometheus --tags services,dotfiles:server --check --diff

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 aggiungere un nuovo host Void che riusa il profilo desktop preservato:

  1. aggiungere l'host a platform_void;
  2. aggiungerlo a graphical_desktop;
  3. scegliere il ruolo, per esempio role_lab;
  4. scegliere il desktop, per esempio desktop_hyprland;
  5. lasciare eventuali dettagli hardware in host_vars/<host>.yml.

I gruppi legacy void e desktop sono parent di compatibilita, quindi un host in platform_void e graphical_desktop continua a ricevere anche le variabili Void e desktop esistenti.

Per prove in VM sono disponibili gruppi di esempio in ansible/inventory/examples/platform-test-hosts.yml, da passare esplicitamente con -i insieme all'inventory principale.

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.

Reference in New Issue View Git Blame Copy Permalink