fscotto/infra
1
0
Fork 0
mirror of https://github.com/fscotto/infra.git synced 2026-05-30 15:39:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

Added npm tag

Browse Source
This commit is contained in:
Fabio Scotto di Santolo
2026-05-10 09:02:08 +02:00
parent 95c7531db4
commit e4d6deb3c5
3 changed files with 347 additions and 346 deletions
Download Patch File Download Diff File Expand all files Collapse all files

689
README.md
View File

@@ -15,26 +15,26 @@ Il repository consente di gestire più sistemi operativi e profili macchina mant
# Architettura del progetto # Architettura del progetto
```text ```text
infra/ infra/
├── ansible/ ├── ansible/
│ ├── ansible.cfg │ ├── ansible.cfg
│ ├── site.yml │ ├── site.yml
│ ├── inventory/ │ ├── inventory/
│ │ ├── hosts.yml │ │ ├── hosts.yml
│ │ ├── group_vars/ │ │ ├── group_vars/
│ │ └── host_vars/ │ │ └── host_vars/
│ ├── templates/ │ ├── templates/
│ └── roles/ │ └── roles/
│ │
├── dotfiles/ ├── dotfiles/
│ ├── common/ │ ├── common/
│ ├── desktop/ │ ├── desktop/
│ ├── fedora/ │ ├── fedora/
│ ├── server/ │ ├── server/
│ ├── workstation/ │ ├── workstation/
│ ├── ikaros/ │ ├── ikaros/
│ └── nymph/ │ └── nymph/
│ │
├── scripts/ ├── scripts/
├── secrets/ ├── secrets/
@@ -50,16 +50,16 @@ Il repository è diviso in due componenti principali:
--- ---
# Macchine gestite # Macchine gestite
Il repository modella attualmente tre tipologie di profilo e prepara due filoni workstation: Linux nativa e Windows + WSL. 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: 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 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 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 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 - `ansible/site.yml` applica anche il profilo `ubuntu_server` con baseline apt, systemd, dotfiles server e firewall UFW
## Desktop ## Desktop
@@ -67,18 +67,18 @@ Sistema operativo:
- Void Linux - Void Linux
Sessioni desktop: Sessioni desktop:
- `ikaros`: i3 - `ikaros`: i3
- `nymph`: SwayFX - `nymph`: SwayFX
Macchine: Macchine:
- `ikaros` - `ikaros`
- `nymph` - `nymph`
Queste macchine condividono la stessa configurazione base desktop e vengono mantenute allineate tramite Ansible. 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: Lo stato attuale del profilo desktop include, tra le altre cose:
- dotfiles comuni e desktop - dotfiles comuni e desktop
@@ -94,84 +94,84 @@ Lo stato attuale del profilo desktop include, tra le altre cose:
- shell Noctalia su Sway su `nymph`, con plugin ufficiali per clipboard (`clipper`), polkit (`polkit-agent`), screenshot (`screenshot`) e gestione USB (`usb-drive-manager`); config condivisa in `dotfiles/desktop/.config/noctalia/` e `settings.json` renderizzato da template Ansible con variabili host-specifiche - shell Noctalia su Sway su `nymph`, con plugin ufficiali per clipboard (`clipper`), polkit (`polkit-agent`), screenshot (`screenshot`) e gestione USB (`usb-drive-manager`); config condivisa in `dotfiles/desktop/.config/noctalia/` e `settings.json` renderizzato da template Ansible con variabili host-specifiche
- `udiskie` come backend per automount/LUKS su Sway, senza tray; la UI dei dispositivi removibili è demandata a `usb-drive-manager` - `udiskie` come backend per automount/LUKS su Sway, senza tray; la UI dei dispositivi removibili è demandata a `usb-drive-manager`
- `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` - `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`
- monitor Noctalia e `screenOverrides` dichiarati in inventory (`noctalia_bar_monitors`, `noctalia_screen_overrides`) per host `nymph` - monitor Noctalia e `screenOverrides` dichiarati in inventory (`noctalia_bar_monitors`, `noctalia_screen_overrides`) per host `nymph`
--- ---
## Workstation ## Workstation
Sistemi operativi supportati: Sistemi operativi supportati:
- Ubuntu LTS nativa
- Fedora Workstation nativa
- Windows 11 host + Ubuntu WSL
Desktop environment host Linux: - Ubuntu LTS nativa
- Fedora Workstation nativa
- GNOME - Windows 11 host + Ubuntu WSL
Macchine attuali: Desktop environment host Linux:
- `deadalus-ubuntu` come workstation Ubuntu nativa - GNOME
- `deadalus-fedora` come workstation Fedora nativa
- supporto attivo per host Windows 11 + WSL tramite `deadalus-win` e `deadalus-wsl` Macchine attuali:
Questo profilo è pensato per sviluppo e lavoro, con separazione tra layer host e layer dev. - `deadalus-ubuntu` come workstation Ubuntu nativa
- `deadalus-fedora` come workstation Fedora nativa
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`. - supporto attivo per host Windows 11 + WSL tramite `deadalus-win` e `deadalus-wsl`
Il profilo workstation e agganciato al playbook principale e ora distingue: Questo profilo è pensato per sviluppo e lavoro, con separazione tra layer host e layer dev.
- layer dev Ubuntu condiviso tra workstation Linux nativa e Ubuntu in WSL 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`.
- layer dev Fedora nativo parallelo a Ubuntu
- layer host Linux GNOME Il profilo workstation e agganciato al playbook principale e ora distingue:
- layer host Windows 11 con bootstrap WSL, remoting `PSRP` su `HTTPS/5986`, gestione app via `winget` con backend configurabile e VS Code lato Windows
- layer WSL dedicato per sviluppo con `systemd` - layer dev Ubuntu condiviso tra workstation Linux nativa e Ubuntu in WSL
- layer dev Fedora nativo parallelo a Ubuntu
Per esempio, lo stesso host Linux puo stare in `workstation_host_linux` e in `workstation_dev_fedora` oppure `workstation_dev_ubuntu`, a seconda del layering che vuoi comporre. - layer host Linux GNOME
- layer host Windows 11 con bootstrap WSL, remoting `PSRP` su `HTTPS/5986`, gestione app via `winget` con backend configurabile e VS Code lato Windows
Lo stato attuale del profilo workstation include: - layer WSL dedicato per sviluppo con `systemd`
- installazione pacchetti base Ubuntu via apt Per esempio, lo stesso host Linux puo stare in `workstation_host_linux` e in `workstation_dev_fedora` oppure `workstation_dev_ubuntu`, a seconda del layering che vuoi comporre.
- installazione pacchetti base Fedora via dnf per il ramo workstation nativo
- installazione e configurazione di Docker dal repository ufficiale Lo stato attuale del profilo workstation include:
- gestione dei dotfiles workstation e rendering dei template dev condivisi
- installazione di Google Chrome su Ubuntu e 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 - installazione pacchetti base Ubuntu via apt
- installazione di applicazioni workstation su Ubuntu nativa via Snap, oltre alle estensioni GNOME sul solo host Linux nativo - installazione pacchetti base Fedora via dnf per il ramo workstation nativo
- configurazione del ramo Windows 11 host con app installate dal playbook via `winget`, con backend predefinito `winget_psrp`, tema scuro, pin della taskbar gestiti via policy locale e profilo predefinito di Windows Terminal impostato su `Ubuntu` - installazione e configurazione di Docker dal repository ufficiale
- preparazione del ramo WSL Ubuntu con `systemd` per il toolchain di sviluppo - gestione dei dotfiles workstation e rendering dei template dev condivisi
- attivazione del firewall UFW su Ubuntu nativa e `firewalld` su Fedora nativa - installazione di Google Chrome su Ubuntu e 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
- gestione di `gsettings` GNOME host-specifici su `deadalus-fedora`, inclusi shell, Files/Nautilus, file chooser GTK e GNOME Text Editor, allineati allo stato reale della macchina - installazione di applicazioni workstation su Ubuntu nativa via Snap, oltre alle estensioni GNOME sul solo host Linux nativo
- configurazione del ramo Windows 11 host con app installate dal playbook via `winget`, con backend predefinito `winget_psrp`, tema scuro, pin della taskbar gestiti via policy locale e profilo predefinito di Windows Terminal impostato su `Ubuntu`
Workflow Windows + WSL previsto: - preparazione del ramo WSL Ubuntu con `systemd` per il toolchain di sviluppo
- attivazione del firewall UFW su Ubuntu nativa e `firewalld` su Fedora nativa
Prima di eseguire il bootstrap Windows, apri PowerShell come amministratore e verifica la policy di esecuzione: - gestione di `gsettings` GNOME host-specifici su `deadalus-fedora`, inclusi shell, Files/Nautilus, file chooser GTK e GNOME Text Editor, allineati allo stato reale della macchina
```powershell Workflow Windows + WSL previsto:
Get-ExecutionPolicy -List
``` Prima di eseguire il bootstrap Windows, apri PowerShell come amministratore e verifica la policy di esecuzione:
Se necessario, abilita l'esecuzione degli script per l'utente corrente: ```powershell
Get-ExecutionPolicy -List
```powershell ```
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
``` Se necessario, abilita l'esecuzione degli script per l'utente corrente:
Se Windows ha bloccato il file di bootstrap, sbloccalo esplicitamente: ```powershell
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
```powershell ```
Unblock-File .\scripts\bootstrap_windows_workstation.ps1
``` Se Windows ha bloccato il file di bootstrap, sbloccalo esplicitamente:
1. eseguire `scripts/bootstrap_windows_workstation.ps1` su Windows come amministratore ```powershell
2. riavviare Windows se richiesto dalle feature WSL Unblock-File .\scripts\bootstrap_windows_workstation.ps1
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 1. eseguire `scripts/bootstrap_windows_workstation.ps1` su Windows come amministratore
6. lanciare da WSL anche il playbook su `deadalus-win` via `psrp` per configurare l'host Windows; per default il backend pacchetti Windows e `winget_psrp` 2. riavviare Windows se richiesto dalle feature WSL
7. usare VS Code con le estensioni Remote (`WSL`, `SSH`, `Dev Containers`) dal lato Windows 3. avviare Ubuntu WSL almeno una volta e completare la creazione dell'utente Linux
4. installare Ansible dentro WSL Ubuntu
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. Il backend pacchetti Windows e configurabile con `windows_package_backend` oppure `vault_windows_package_backend`; il default e `winget_psrp`. 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; per default il backend pacchetti Windows e `winget_psrp`
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. Il backend pacchetti Windows e configurabile con `windows_package_backend` oppure `vault_windows_package_backend`; il default e `winget_psrp`.
--- ---
@@ -189,43 +189,43 @@ Macchina:
- `prometheus` - `prometheus`
Profilo orientato a servizi server e gestione di dotfiles dedicati. Profilo orientato a servizi server e gestione di dotfiles dedicati.
Lo stato attuale del profilo server include: Lo stato attuale del profilo server include:
- installazione pacchetti base Ubuntu via apt - installazione pacchetti base Ubuntu via apt
- installazione e configurazione di Docker dal repository ufficiale - installazione e configurazione di Docker dal repository ufficiale
- abilitazione dei servizi systemd dichiarati in inventory/group vars - 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 - 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 - 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 - apertura delle porte Syncthing `22000/tcp`, `22000/udp` e `21027/udp`, lasciando la GUI non esposta direttamente su UFW
Utente del profilo server: Utente del profilo server:
- il profilo usa `server_username`, `server_user_group` e `server_user_home` definiti in `ansible/inventory/group_vars/server.yml` - 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 - 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: - esempio override da CLI:
```bash ```bash
ansible-playbook ansible/site.yml --limit prometheus -e server_username=myuser ansible-playbook ansible/site.yml --limit prometheus -e server_username=myuser
``` ```
- se necessario puoi passare anche: - se necessario puoi passare anche:
```bash ```bash
ansible-playbook ansible/site.yml --limit prometheus -e server_username=myuser -e server_user_group=mygroup -e server_user_home=/srv/myuser 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 # Composizione della configurazione
Deploy mirato della configurazione Emacs sui desktop Void: Deploy mirato della configurazione Emacs sui desktop Void:
```bash ```bash
ansible-playbook ansible/site.yml --limit ikaros --tags emacs ansible-playbook ansible/site.yml --limit ikaros --tags emacs
ansible-playbook ansible/site.yml --limit nymph --tags emacs ansible-playbook ansible/site.yml --limit nymph --tags emacs
``` ```
La configurazione finale di una macchina è ottenuta combinando più livelli. La configurazione finale di una macchina è ottenuta combinando più livelli.
@@ -258,67 +258,67 @@ Questo approccio consente di:
# Ruoli Ansible # Ruoli Ansible
I principali ruoli attualmente presenti sono: I principali ruoli attualmente presenti sono:
| Role | Descrizione | | Role | Descrizione |
| ------------------------- | ----------------------------------- | | ------------------------- | ----------------------------------- |
| base | configurazione base comune | | base | configurazione base comune |
| packages_void | installazione pacchetti su Void | | packages_void | installazione pacchetti su Void |
| packages_ubuntu | installazione pacchetti su Ubuntu | | packages_ubuntu | installazione pacchetti su Ubuntu |
| packages_fedora | installazione pacchetti su Fedora | | packages_fedora | installazione pacchetti su Fedora |
| services_runit | gestione servizi runit | | services_runit | gestione servizi runit |
| services_systemd | gestione servizi systemd | | services_systemd | gestione servizi systemd |
| profile_desktop_common | bootstrap desktop Void condiviso | | profile_desktop_common | bootstrap desktop Void condiviso |
| profile_desktop_i3 | sessione desktop i3 | | profile_desktop_i3 | sessione desktop i3 |
| profile_desktop_sway | sessione desktop Sway | | profile_desktop_sway | sessione desktop Sway |
| profile_desktop_host | override desktop specifici per host | | profile_desktop_host | override desktop specifici per host |
| profile_workstation_dev_common | configurazione dev workstation condivisa | | profile_workstation_dev_common | configurazione dev workstation condivisa |
| profile_workstation_gnome | configurazione host workstation GNOME | | profile_workstation_gnome | configurazione host workstation GNOME |
| profile_workstation_dev_wsl | configurazione WSL Ubuntu per sviluppo | | profile_workstation_dev_wsl | configurazione WSL Ubuntu per sviluppo |
| profile_workstation_host_windows | configurazione host Windows 11 workstation | | profile_workstation_host_windows | configurazione host Windows 11 workstation |
| profile_server | configurazione server | | profile_server | configurazione server |
| dotfiles_common | distribuzione dotfiles comuni | | dotfiles_common | distribuzione dotfiles comuni |
| dotfiles | distribuzione configurazioni utente | | dotfiles | distribuzione configurazioni utente |
--- ---
# Stato attuale del playbook principale # Stato attuale del playbook principale
Il playbook `ansible/site.yml` e attualmente composto da sette blocchi: Il playbook `ansible/site.yml` e attualmente composto da sette blocchi:
```text ```text
all:!workstation_host_windows -> dotfiles_common all:!workstation_host_windows -> dotfiles_common
void -> packages_void + services_runit + profile_desktop_common + profile_desktop_i3 + profile_desktop_sway + profile_desktop_host void -> packages_void + services_runit + profile_desktop_common + profile_desktop_i3 + profile_desktop_sway + profile_desktop_host
workstation_dev_ubuntu -> packages_ubuntu + services_systemd + profile_workstation_dev_common workstation_dev_ubuntu -> packages_ubuntu + services_systemd + profile_workstation_dev_common
workstation_dev_fedora -> packages_fedora + services_systemd + profile_workstation_dev_common workstation_dev_fedora -> packages_fedora + services_systemd + profile_workstation_dev_common
workstation_host_linux -> profile_workstation_gnome workstation_host_linux -> profile_workstation_gnome
workstation_dev_wsl -> packages_ubuntu + services_systemd + profile_workstation_dev_common + profile_workstation_dev_wsl workstation_dev_wsl -> packages_ubuntu + services_systemd + profile_workstation_dev_common + profile_workstation_dev_wsl
workstation_host_windows -> profile_workstation_host_windows workstation_host_windows -> profile_workstation_host_windows
ubuntu_server -> packages_ubuntu + services_systemd + profile_server ubuntu_server -> packages_ubuntu + services_systemd + profile_server
``` ```
Questo significa che, allo stato attuale: Questo significa che, allo stato attuale:
- i desktop Void (`ikaros`, `nymph`) restano il target operativo piu completo - i desktop Void (`ikaros`, `nymph`) restano il target operativo piu completo
- la workstation Ubuntu (`deadalus-ubuntu`) e gestita separando ambiente dev e layer host GNOME - la workstation Ubuntu (`deadalus-ubuntu`) e gestita separando ambiente dev e layer host GNOME
- la workstation Fedora (`deadalus-fedora`) usa lo stesso principio di composizione a gruppi con il ramo Fedora dedicato e con `gsettings` host-specifici dichiarati in inventory - la workstation Fedora (`deadalus-fedora`) usa lo stesso principio di composizione a gruppi con il ramo Fedora dedicato e con `gsettings` host-specifici dichiarati in inventory
- il ramo Windows + WSL e predisposto con bootstrap PowerShell e play Windows/WSL dedicati - 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 - 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` - lo stack container server include `navidrome`, `postgres`, `gitea`, `nginx-proxy-manager` e `syncthing`, con GUI Syncthing raggiungibile tramite la rete Docker `web`
# Dotfiles # Dotfiles
La directory `dotfiles/` contiene le configurazioni utente versionate. La directory `dotfiles/` contiene le configurazioni utente versionate.
```text ```text
dotfiles/ dotfiles/
├── common ├── common
├── desktop ├── desktop
├── server ├── server
├── fedora ├── fedora
├── workstation ├── workstation
├── ikaros ├── ikaros
└── nymph └── nymph
``` ```
Le configurazioni sono applicate tramite Ansible e organizzate per livelli: Le configurazioni sono applicate tramite Ansible e organizzate per livelli:
@@ -333,153 +333,154 @@ Le configurazioni sono applicate tramite Ansible e organizzate per livelli:
# Requisiti # Requisiti
Per utilizzare il repository sono necessari: Per utilizzare il repository sono necessari:
- Python 3 - Python 3
- Ansible - Ansible
- `ansible-lint` - `ansible-lint`
- `yamllint` - `yamllint`
- `shellcheck` - `shellcheck`
- collection definite in `ansible/collections/requirements.yml` - collection definite in `ansible/collections/requirements.yml`
- accesso locale o SSH alle macchine target, in base a come e definito l'inventory - accesso locale o SSH alle macchine target, in base a come e definito l'inventory
Installazione base: Installazione base:
```bash ```bash
python3 -m pip install ansible ansible-lint yamllint shellcheck-py python3 -m pip install ansible ansible-lint yamllint shellcheck-py
ansible-galaxy collection install -r ansible/collections/requirements.yml ansible-galaxy collection install -r ansible/collections/requirements.yml
``` ```
Gestione segreti: Gestione segreti:
- il repository supporta il caricamento opzionale di `secrets/vault.yml` - il repository supporta il caricamento opzionale di `secrets/vault.yml`
- il repository supporta anche `secrets/vault.local.yml` per override locali non versionati - il repository supporta anche `secrets/vault.local.yml` per override locali non versionati
- `secrets/vault.yml.example` funge da template/esempio - `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.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 - 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
- per il ramo Windows puoi anche definire `vault_windows_package_backend`, con valori supportati `winget_psrp` e `winget_wsl_local`; il default e `winget_psrp` - per il ramo Windows puoi anche definire `vault_windows_package_backend`, con valori supportati `winget_psrp` e `winget_wsl_local`; il default e `winget_psrp`
--- ---
# Utilizzo # Utilizzo
Eseguire il playbook principale: Eseguire il playbook principale:
```bash ```bash
ansible-playbook ansible/site.yml ansible-playbook ansible/site.yml
``` ```
Allo stato attuale questo comando: Allo stato attuale questo comando:
- distribuisce i dotfiles comuni a tutti gli host - distribuisce i dotfiles comuni a tutti gli host
- per gli host Void applica bootstrap desktop condiviso, sessioni i3/Sway e override specifici per host - per gli host Void applica bootstrap desktop condiviso, sessioni i3/Sway e override specifici per host
- per `workstation_dev_ubuntu` applica pacchetti Ubuntu, servizi systemd e profilo dev comune - per `workstation_dev_ubuntu` applica pacchetti Ubuntu, servizi systemd e profilo dev comune
- per `workstation_dev_fedora` applica pacchetti Fedora, servizi systemd e profilo dev comune - per `workstation_dev_fedora` applica pacchetti Fedora, servizi systemd e profilo dev comune
- per `workstation_host_linux` applica il layer host Linux GNOME - 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_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, con installazione pacchetti Windows eseguita di default tramite `winget_psrp` - per `workstation_host_windows` applica il layer host Windows 11 via PSRP, con installazione pacchetti Windows eseguita di default tramite `winget_psrp`
- per gli host `ubuntu_server` applica pacchetti Ubuntu, servizi systemd, profilo server, UFW, dotfiles 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 - 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.yml` solo se presente
- carica `secrets/vault.local.yml` solo se presente, dopo `vault.yml`, cosi gli override locali hanno precedenza - carica `secrets/vault.local.yml` solo se presente, dopo `vault.yml`, cosi gli override locali hanno precedenza
Per validare prima di applicare: Per validare prima di applicare:
```bash ```bash
ansible-playbook ansible/site.yml --syntax-check ansible-playbook ansible/site.yml --syntax-check
ansible-playbook ansible/site.yml --limit ikaros --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 nymph --check --diff
ansible-playbook ansible/site.yml --limit deadalus-ubuntu --check --diff ansible-playbook ansible/site.yml --limit deadalus-ubuntu --check --diff
ansible-playbook ansible/site.yml --limit deadalus-fedora --check --diff ansible-playbook ansible/site.yml --limit deadalus-fedora --check --diff
ansible-playbook ansible/site.yml --limit deadalus-wsl --check --diff ansible-playbook ansible/site.yml --limit deadalus-wsl --check --diff
ansible-playbook ansible/site.yml --limit prometheus --check --diff ansible-playbook ansible/site.yml --limit prometheus --check --diff
ansible-lint ansible/site.yml ansible-lint ansible/site.yml
ansible-lint ansible/roles ansible-lint ansible/roles
yamllint ansible/ yamllint ansible/
``` ```
Per testare un override dell'utente server senza modificare l'inventory: Per testare un override dell'utente server senza modificare l'inventory:
```bash ```bash
ansible-playbook ansible/site.yml --limit prometheus --check --diff -e server_username=myuser ansible-playbook ansible/site.yml --limit prometheus --check --diff -e server_username=myuser
``` ```
Per validazioni piu mirate: Per validazioni piu mirate:
```bash ```bash
ansible-playbook ansible/site.yml --limit <host> --tags <tag1>,<tag2> --check --diff 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-playbook ansible/site.yml --limit <host> --start-at-task "<task name>" --check --diff
ansible-lint ansible/roles/<role> ansible-lint ansible/roles/<role>
yamllint ansible/path/to/file.yml yamllint ansible/path/to/file.yml
docker compose -f /opt/docker/server/docker-compose.yml config docker compose -f /opt/docker/server/docker-compose.yml config
``` ```
## Tag supportati dal playbook ## Tag supportati dal playbook
Per vedere l'elenco reale aggiornato dei tag disponibili: Per vedere l'elenco reale aggiornato dei tag disponibili:
```bash ```bash
ansible-playbook ansible/site.yml --list-tags ansible-playbook ansible/site.yml --list-tags
``` ```
Allo stato attuale `ansible/site.yml` espone questi tag: Allo stato attuale `ansible/site.yml` espone questi tag:
| Tag | Scopo | Ambito principale | | Tag | Scopo | Ambito principale |
| --- | --- | --- | | --- | --- | --- |
| `always` | pre-task sempre eseguiti, inclusi caricamento vault e validazioni preliminari | common, Windows | | `always` | pre-task sempre eseguiti, inclusi caricamento vault e validazioni preliminari | common, Windows |
| `dotfiles` | distribuzione/configurazione dotfiles | tutti i profili | | `dotfiles` | distribuzione/configurazione dotfiles | tutti i profili |
| `dotfiles:common` | dotfiles comuni condivisi | common, workstation, server | | `dotfiles:common` | dotfiles comuni condivisi | common, workstation, server |
| `dotfiles:desktop` | dotfiles desktop | desktop Void | | `dotfiles:desktop` | dotfiles desktop | desktop Void |
| `dotfiles:host` | override host-specifici desktop | desktop Void | | `dotfiles:host` | override host-specifici desktop | desktop Void |
| `dotfiles:server` | dotfiles dedicati al profilo server | server | | `dotfiles:server` | dotfiles dedicati al profilo server | server |
| `dotfiles:workstation` | dotfiles dedicati alle workstation | workstation Linux, WSL | | `dotfiles:workstation` | dotfiles dedicati alle workstation | workstation Linux, WSL |
| `emptty` | gestione display manager `emptty` | desktop Void | | `emptty` | gestione display manager `emptty` | desktop Void |
| `gnome` | configurazione host GNOME | workstation host Linux, parte desktop | | `gnome` | configurazione host GNOME | workstation host Linux, parte desktop |
| `i3` | sessione/configurazione i3 | desktop Void | | `i3` | sessione/configurazione i3 | desktop Void |
| `nvidia` | componenti NVIDIA desktop | desktop Void | | `npm` | installazione pacchetti npm globali | desktop Void, workstation Linux, WSL |
| `packages` | installazione e aggiornamento pacchetti | tutti i profili | | `nvidia` | componenti NVIDIA desktop | desktop Void |
| `services` | gestione servizi runit/systemd/Windows | tutti i profili | | `packages` | installazione e aggiornamento pacchetti | tutti i profili |
| `sway` | sessione/configurazione Sway | desktop Void | | `services` | gestione servizi runit/systemd/Windows | tutti i profili |
| `vscode` | installazione/configurazione VS Code | Fedora, host Linux, Windows | | `sway` | sessione/configurazione Sway | desktop Void |
| `wsl` | bootstrap e configurazione WSL | WSL, Windows | | `vscode` | installazione/configurazione VS Code | Fedora, host Linux, Windows |
| `wsl` | bootstrap e configurazione WSL | WSL, Windows |
Esempi pratici:
Esempi pratici:
```bash
ansible-playbook ansible/site.yml --limit nymph --tags dotfiles:desktop,sway --check --diff ```bash
ansible-playbook ansible/site.yml --limit deadalus-fedora --tags packages,vscode --check --diff ansible-playbook ansible/site.yml --limit nymph --tags dotfiles:desktop,sway --check --diff
ansible-playbook ansible/site.yml --limit prometheus --tags services,dotfiles:server --check --diff ansible-playbook ansible/site.yml --limit deadalus-fedora --tags packages,vscode --check --diff
``` ansible-playbook ansible/site.yml --limit prometheus --tags services,dotfiles:server --check --diff
```
---
---
# Bootstrap di una nuova macchina # Bootstrap di una nuova macchina
Una nuova macchina può essere inizializzata con i seguenti passaggi: Una nuova macchina può essere inizializzata con i seguenti passaggi:
```bash ```bash
git clone <repo> git clone <repo>
cd <repo-dir> cd <repo-dir>
ansible-galaxy collection install -r ansible/collections/requirements.yml ansible-galaxy collection install -r ansible/collections/requirements.yml
ansible-playbook ansible/site.yml ansible-playbook ansible/site.yml
``` ```
Dopo l'esecuzione del playbook la macchina verra configurata secondo il profilo definito e i ruoli attualmente orchestrati. 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: Per il flusso mail desktop esiste inoltre uno script dedicato:
```bash ```bash
scripts/bootstrap_mail.sh 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. 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: Se modifichi questo script, valida almeno con:
```bash ```bash
sh -n scripts/bootstrap_mail.sh sh -n scripts/bootstrap_mail.sh
shellcheck scripts/bootstrap_mail.sh shellcheck scripts/bootstrap_mail.sh
``` ```
--- ---
@@ -499,13 +500,13 @@ Questo consente di ricreare qualsiasi macchina partendo esclusivamente dal repos
# Roadmap # Roadmap
Possibili evoluzioni future: Possibili evoluzioni future:
- hardening sicurezza server - hardening sicurezza server
- configurazione backup - configurazione backup
- testing automatico playbook - testing automatico playbook
- integrazione CI - integrazione CI
- supporto ad altre distribuzioni Linux - supporto ad altre distribuzioni Linux
--- ---

2
ansible/roles/profile_desktop_common/tasks/main.yml
View File

@@ -518,7 +518,7 @@
label: "{{ binary_tool.name }}" label: "{{ binary_tool.name }}"
- name: Install desktop npm packages - name: Install desktop npm packages
tags: [packages] tags: [packages, npm]
community.general.npm: community.general.npm:
name: "{{ item.name }}" name: "{{ item.name }}"
global: true global: true

2
ansible/roles/profile_workstation_dev_common/tasks/main.yml
View File

@@ -36,7 +36,7 @@
label: "{{ item.dest }}" label: "{{ item.dest }}"
- name: Install workstation npm packages - name: Install workstation npm packages
tags: [packages] tags: [packages, npm]
community.general.npm: community.general.npm:
name: "{{ item.name }}" name: "{{ item.name }}"
global: true global: true