From e4d6deb3c57ca81d8ee3bb946710aca86b643224 Mon Sep 17 00:00:00 2001 From: Fabio Scotto di Santolo Date: Sun, 10 May 2026 09:02:08 +0200 Subject: [PATCH] Added npm tag --- README.md | 689 +++++++++--------- .../profile_desktop_common/tasks/main.yml | 2 +- .../tasks/main.yml | 2 +- 3 files changed, 347 insertions(+), 346 deletions(-) diff --git a/README.md b/README.md index d86fb2c..1277fa2 100644 --- a/README.md +++ b/README.md @@ -15,26 +15,26 @@ Il repository consente di gestire più sistemi operativi e profili macchina mant # Architettura del progetto -```text -infra/ -├── ansible/ -│ ├── ansible.cfg -│ ├── site.yml -│ ├── inventory/ -│ │ ├── hosts.yml -│ │ ├── group_vars/ -│ │ └── host_vars/ -│ ├── templates/ -│ └── roles/ -│ -├── dotfiles/ -│ ├── common/ -│ ├── desktop/ -│ ├── fedora/ -│ ├── server/ -│ ├── workstation/ -│ ├── ikaros/ -│ └── nymph/ +```text +infra/ +├── ansible/ +│ ├── ansible.cfg +│ ├── site.yml +│ ├── inventory/ +│ │ ├── hosts.yml +│ │ ├── group_vars/ +│ │ └── host_vars/ +│ ├── templates/ +│ └── roles/ +│ +├── dotfiles/ +│ ├── common/ +│ ├── desktop/ +│ ├── fedora/ +│ ├── server/ +│ ├── workstation/ +│ ├── ikaros/ +│ └── nymph/ │ ├── scripts/ ├── secrets/ @@ -50,16 +50,16 @@ Il repository è diviso in due componenti principali: --- -# 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 +# 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 @@ -67,18 +67,18 @@ Sistema operativo: - Void Linux -Sessioni desktop: - -- `ikaros`: i3 -- `nymph`: SwayFX +Sessioni desktop: + +- `ikaros`: i3 +- `nymph`: SwayFX Macchine: - `ikaros` - `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: - 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 - `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` -- 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: - -- Ubuntu LTS nativa -- Fedora Workstation nativa -- Windows 11 host + Ubuntu WSL +Sistemi operativi supportati: -Desktop environment host Linux: - -- GNOME - -Macchine attuali: - -- `deadalus-ubuntu` come workstation Ubuntu nativa -- `deadalus-fedora` come workstation Fedora 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. - -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 workstation Linux nativa e Ubuntu in WSL -- layer dev Fedora nativo parallelo a Ubuntu -- 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 -- layer WSL dedicato per sviluppo con `systemd` - -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. - -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 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 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` -- preparazione del ramo WSL Ubuntu con `systemd` per il toolchain di sviluppo -- attivazione del firewall UFW su Ubuntu nativa e `firewalld` su Fedora nativa -- 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 - -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; 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`. +- Ubuntu LTS nativa +- Fedora Workstation nativa +- Windows 11 host + Ubuntu WSL + +Desktop environment host Linux: + +- GNOME + +Macchine attuali: + +- `deadalus-ubuntu` come workstation Ubuntu nativa +- `deadalus-fedora` come workstation Fedora 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. + +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 workstation Linux nativa e Ubuntu in WSL +- layer dev Fedora nativo parallelo a Ubuntu +- 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 +- layer WSL dedicato per sviluppo con `systemd` + +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. + +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 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 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` +- preparazione del ramo WSL Ubuntu con `systemd` per il toolchain di sviluppo +- attivazione del firewall UFW su Ubuntu nativa e `firewalld` su Fedora nativa +- 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 + +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; 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` -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: - -```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 -``` +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: + +```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 - -Deploy mirato della configurazione Emacs sui desktop Void: - -```bash -ansible-playbook ansible/site.yml --limit ikaros --tags emacs -ansible-playbook ansible/site.yml --limit nymph --tags emacs -``` +# Composizione della configurazione + +Deploy mirato della configurazione Emacs sui desktop Void: + +```bash +ansible-playbook ansible/site.yml --limit ikaros --tags emacs +ansible-playbook ansible/site.yml --limit nymph --tags emacs +``` La configurazione finale di una macchina è ottenuta combinando più livelli. @@ -258,67 +258,67 @@ Questo approccio consente di: # Ruoli Ansible -I principali ruoli attualmente presenti sono: +I principali ruoli attualmente presenti sono: | Role | Descrizione | | ------------------------- | ----------------------------------- | -| base | configurazione base comune | -| packages_void | installazione pacchetti su Void | -| packages_ubuntu | installazione pacchetti su Ubuntu | -| packages_fedora | installazione pacchetti su Fedora | -| 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_host | override desktop specifici per host | -| 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_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 sette blocchi: - -```text -all:!workstation_host_windows -> dotfiles_common -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_fedora -> packages_fedora + 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-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 -- 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 -- lo stack container server include `navidrome`, `postgres`, `gitea`, `nginx-proxy-manager` e `syncthing`, con GUI Syncthing raggiungibile tramite la rete Docker `web` - -# Dotfiles +| base | configurazione base comune | +| packages_void | installazione pacchetti su Void | +| packages_ubuntu | installazione pacchetti su Ubuntu | +| packages_fedora | installazione pacchetti su Fedora | +| 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_host | override desktop specifici per host | +| 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_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 sette blocchi: + +```text +all:!workstation_host_windows -> dotfiles_common +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_fedora -> packages_fedora + 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-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 +- 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 +- 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. -```text -dotfiles/ -├── common -├── desktop -├── server -├── fedora -├── workstation -├── ikaros -└── nymph +```text +dotfiles/ +├── common +├── desktop +├── server +├── fedora +├── workstation +├── ikaros +└── nymph ``` 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 -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: - -```bash -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 -- 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 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: + +```bash +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 +- 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 -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 e override specifici per host -- 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_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, 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 -- 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-ubuntu --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 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 -docker compose -f /opt/docker/server/docker-compose.yml config -``` - -## Tag supportati dal playbook - -Per vedere l'elenco reale aggiornato dei tag disponibili: - -```bash -ansible-playbook ansible/site.yml --list-tags -``` - -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, Windows | -| `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 | -| `gnome` | configurazione host GNOME | workstation host Linux, parte desktop | -| `i3` | sessione/configurazione i3 | desktop Void | -| `nvidia` | componenti NVIDIA desktop | desktop Void | -| `packages` | installazione e aggiornamento pacchetti | tutti i profili | -| `services` | gestione servizi runit/systemd/Windows | tutti i profili | -| `sway` | sessione/configurazione Sway | desktop Void | -| `vscode` | installazione/configurazione VS Code | Fedora, host Linux, Windows | -| `wsl` | bootstrap e configurazione WSL | WSL, Windows | - -Esempi pratici: - -```bash -ansible-playbook ansible/site.yml --limit nymph --tags dotfiles:desktop,sway --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 -``` - ---- +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 e override specifici per host +- 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_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, 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 +- 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-ubuntu --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 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 +docker compose -f /opt/docker/server/docker-compose.yml config +``` + +## Tag supportati dal playbook + +Per vedere l'elenco reale aggiornato dei tag disponibili: + +```bash +ansible-playbook ansible/site.yml --list-tags +``` + +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, Windows | +| `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 | +| `gnome` | configurazione host GNOME | workstation host Linux, parte desktop | +| `i3` | sessione/configurazione i3 | desktop Void | +| `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/Windows | tutti i profili | +| `sway` | sessione/configurazione Sway | desktop Void | +| `vscode` | installazione/configurazione VS Code | Fedora, host Linux, Windows | +| `wsl` | bootstrap e configurazione WSL | WSL, Windows | + +Esempi pratici: + +```bash +ansible-playbook ansible/site.yml --limit nymph --tags dotfiles:desktop,sway --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 -Una nuova macchina può essere inizializzata con i seguenti passaggi: - -```bash -git clone -cd -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: - -```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 -``` +Una nuova macchina può essere inizializzata con i seguenti passaggi: + +```bash +git clone +cd +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: + +```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 +``` --- @@ -499,13 +500,13 @@ Questo consente di ricreare qualsiasi macchina partendo esclusivamente dal repos # Roadmap -Possibili evoluzioni future: - -- hardening sicurezza server -- configurazione backup -- testing automatico playbook -- integrazione CI -- supporto ad altre distribuzioni Linux +Possibili evoluzioni future: + +- hardening sicurezza server +- configurazione backup +- testing automatico playbook +- integrazione CI +- supporto ad altre distribuzioni Linux --- diff --git a/ansible/roles/profile_desktop_common/tasks/main.yml b/ansible/roles/profile_desktop_common/tasks/main.yml index e429eba..3758556 100644 --- a/ansible/roles/profile_desktop_common/tasks/main.yml +++ b/ansible/roles/profile_desktop_common/tasks/main.yml @@ -518,7 +518,7 @@ label: "{{ binary_tool.name }}" - name: Install desktop npm packages - tags: [packages] + tags: [packages, npm] community.general.npm: name: "{{ item.name }}" global: true diff --git a/ansible/roles/profile_workstation_dev_common/tasks/main.yml b/ansible/roles/profile_workstation_dev_common/tasks/main.yml index a377a96..eb3808f 100644 --- a/ansible/roles/profile_workstation_dev_common/tasks/main.yml +++ b/ansible/roles/profile_workstation_dev_common/tasks/main.yml @@ -36,7 +36,7 @@ label: "{{ item.dest }}" - name: Install workstation npm packages - tags: [packages] + tags: [packages, npm] community.general.npm: name: "{{ item.name }}" global: true