mirror of
https://github.com/fscotto/infra.git
synced 2026-05-30 15:39:58 +00:00
Added npm tag
This commit is contained in:
Fabio Scotto di Santolo
689
README.md
689
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 <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:
|
||||
|
||||
```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 <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:
|
||||
|
||||
```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 <repo>
|
||||
cd <repo-dir>
|
||||
ansible-galaxy collection install -r ansible/collections/requirements.yml
|
||||
ansible-playbook ansible/site.yml
|
||||
```
|
||||
|
||||
Dopo l'esecuzione del playbook la macchina verra configurata secondo il profilo definito e i ruoli attualmente orchestrati.
|
||||
|
||||
Per il flusso mail desktop esiste inoltre uno script dedicato:
|
||||
|
||||
```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 <repo>
|
||||
cd <repo-dir>
|
||||
ansible-galaxy collection install -r ansible/collections/requirements.yml
|
||||
ansible-playbook ansible/site.yml
|
||||
```
|
||||
|
||||
Dopo l'esecuzione del playbook la macchina verra configurata secondo il profilo definito e i ruoli attualmente orchestrati.
|
||||
|
||||
Per il flusso mail desktop esiste inoltre uno script dedicato:
|
||||
|
||||
```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
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user