Snap su Linux: installazione, aggiornamento e rimozione

Snap non è solo un altro formato di pacchetto: cambia il modo in cui distribuisci, aggiorni e isoli applicazioni su Linux. In pratica, sposta una parte del lavoro dal gestore tradizionale della distribuzione a un sistema che include dipendenze, revisione, canali di rilascio e rollback integrato. Il punto non è “meglio o peggio” in assoluto: il punto è capire dove Snap semplifica davvero la vita e dove invece introduce vincoli operativi che vanno gestiti con metodo.

Su un server o su una workstation amministrata bene, Snap conviene quando vuoi avere versioni coerenti, aggiornamenti automatici e possibilità di tornare indietro senza ricostruire mezzo ambiente. Conviene meno quando hai bisogno di controllo granulare sulle dipendenze di sistema, di integrazione stretta con librerie locali o di un comportamento perfettamente allineato ai pacchetti della distro. Da qui si parte: installazione, aggiornamento e rimozione vanno letti come operazioni di ciclo di vita, non come semplici comandi.

Come Snap si inserisce nel sistema

Snap usa pacchetti compressi, montati e gestiti dal demone `snapd`. Ogni applicazione gira in un confinamento che può essere più o meno stretto, e il sistema conserva revisioni precedenti per consentire il rollback. Questo significa due cose operative importanti: da un lato l’installazione è spesso molto semplice, dall’altro non puoi ragionare come se stessi copiando binari sotto `/usr/local` e basta.

Per verificare lo stato base dell’infrastruttura Snap, il primo comando utile è controllare il servizio e la presenza del client. Su sistemi recenti con systemd:

systemctl status snapd
snap version

Se `snap version` mostra versione client, server e stato del mounting, la base c’è. Se `snapd` non è attivo, ogni operazione successiva rischia di fermarsi a metà. In ambienti con policy restrittive, conviene verificare anche che il filesystem supporti correttamente i mount necessari e che non ci siano limitazioni anomale su AppArmor o SELinux, perché il confinamento dipende anche da questi componenti.

Installazione di Snap su Linux: il punto non è il pacchetto, è il servizio

Su molte distribuzioni `snapd` è disponibile nei repository standard. L’installazione base è semplice, ma va interpretata come abilitazione del framework, non come installazione di una singola app. Su Debian/Ubuntu e derivate il flusso classico è questo:

sudo apt update
sudo apt install snapd
sudo systemctl enable --now snapd.socket

Dopo l’installazione, il socket o il servizio devono risultare attivi. Un controllo rapido evita di confondere un problema di installazione con un problema di rete o di store:

systemctl is-active snapd.socket
systemctl is-enabled snapd.socket

Su Fedora, Arch e altre distribuzioni la disponibilità varia: in alcuni casi il pacchetto esiste nei repository ufficiali, in altri va installato da repository aggiuntivi o con procedure specifiche della distro. Qui il punto operativo è non dare per scontato che il nome del pacchetto sia identico ovunque. Se il repository non contiene `snapd`, la verifica da fare è banale ma fondamentale: cercare il pacchetto nel gestore della distribuzione prima di inseguire soluzioni manuali.

Una volta presente `snapd`, il sistema può iniziare a gestire snap dal repository centrale. Per installare un’app, il comando base è lineare:

sudo snap install nome-pacchetto

Per esempio, installando un tool ben noto, puoi usare:

sudo snap install lxd

Subito dopo conviene verificare due elementi: lo stato del pacchetto e la revisione installata. Questo evita di ragionare su un’installazione “astratta” quando in realtà hai una specifica build, spesso importante per compatibilità e troubleshooting.

snap list
snap info nome-pacchetto

`snap list` ti dice cosa è installato, quale revisione è attiva e quali versioni sono presenti localmente. `snap info` aggiunge canali, publisher e dettagli utili per capire se stai usando stable, candidate, beta o edge. Se questi dati non tornano con l’aspettativa operativa, il problema non è nello snap in sé ma nella scelta del canale o nella sincronizzazione dello store.

Canali di rilascio: stable, candidate, beta, edge

Snap introduce un concetto che nei pacchetti classici è meno esplicito: il canale di rilascio. È una leva utile perché separa il codice pronto per l’uso da quello in validazione. In pratica, puoi tenere in produzione `stable` e testare una nuova versione in `candidate` o `beta` senza cambiare completamente la strategia di distribuzione.

La scelta del canale non è cosmetica. Se ad esempio vuoi validare una nuova release di un componente critico prima di promuoverla, puoi installare o passare a un canale diverso in modo esplicito:

sudo snap refresh nome-pacchetto --channel=candidate

Qui la verifica immediata è nel risultato di `snap list` e nella revisione attiva. Se il comportamento cambia dopo il refresh, hai almeno una traccia chiara di quale versione è entrata in gioco. In ambienti con finestre di manutenzione strette, questa granularità vale più di quanto sembri: riduce il tempo perso a ricostruire quale aggiornamento abbia introdotto un regressione.

Un uso maturo dei canali è questo: stable in produzione, candidate su una macchina di pre-produzione e beta solo per test funzionali. Edge va trattato come ramo sperimentale, non come canale da lasciare in giro su host che devono stare su.

Aggiornamento automatico e finestra di manutenzione

Snap aggiorna automaticamente i pacchetti secondo una logica propria. Questa è una delle caratteristiche più apprezzate in ambiente desktop e una delle più controverse in ambienti server, perché sposta il controllo temporale sugli update. Se il tuo servizio non tollera restart imprevedibili, devi conoscere come limitare o schedulare gli aggiornamenti.

Per vedere gli aggiornamenti disponibili:

snap refresh --list

Per forzare un refresh manuale di un pacchetto specifico:

sudo snap refresh nome-pacchetto

Se vuoi ridurre il rischio operativo, il concetto importante è la finestra di refresh. Snap consente di configurare quando gli aggiornamenti automatici possono avvenire, così da evitare che una macchina critica si riavvii o aggiorni componenti nel momento sbagliato. Questa impostazione è da trattare come cambio controllato: va documentata, verificata e, se necessario, riportata indietro.

Un controllo utile è osservare se un servizio snap ha subito un refresh recente rispetto a un problema comparso in produzione. In molti casi, l’evidenza si trova già in `snap changes`:

snap changes
snap tasks <ID-CAMBIO>

Questi comandi aiutano a risalire a installazioni, refresh, revert e operazioni fallite. Se un’app ha iniziato a comportarsi male dopo un aggiornamento, la timeline di `snap changes` vale più di una caccia cieca nei log applicativi.

Rollback: il vantaggio pratico che spesso giustifica Snap

Il rollback è uno dei motivi più solidi per adottare Snap in contesti dove il cambio versione è frequente. Se una release introduce un bug, puoi tornare rapidamente alla revisione precedente senza reinstallare da zero. Questo non elimina il bisogno di test, ma riduce il tempo di ripristino.

Il comando tipico è:

sudo snap revert nome-pacchetto

Prima di usarlo in produzione, conviene sapere due cose: non tutti i pacchetti hanno revisioni revertibili disponibili all’infinito, e il rollback può non essere sufficiente se il problema deriva da dati già migrati dal nuovo rilascio. Quindi il revert è una mitigazione, non una bacchetta magica.

La sequenza sensata è sempre la stessa: osservi il sintomo, controlli `snap changes`, verifichi quale revisione è attiva, e solo dopo esegui il revert. Se il servizio resta instabile, la causa potrebbe essere nel database, nel filesystem o in una dipendenza esterna, non nel binario snap in sé.

Confinamento, permessi e interfacce

Snap non si limita a distribuire software: lo incapsula in un modello di permessi basato su interfacce. Una app può avere accesso a rete, home directory, dispositivi, socket o altre risorse solo se l’interfaccia è concessa. Questo è utile per limitare il danno in caso di compromissione, ma può generare comportamenti “strani” se non sai che la mancanza di accesso è intenzionale.

Per vedere le connessioni di un pacchetto:

snap connections nome-pacchetto

Se un’app non vede una directory o non riesce a parlare con una periferica, il primo controllo non è “riavvio tutto”: è verificare se l’interfaccia necessaria è collegata. In alcuni casi l’associazione è automatica, in altri va valutata manualmente. Qui bisogna essere rigorosi: concedere interfacce in più aumenta la superficie d’attacco, quindi ogni connessione va giustificata dal requisito reale.

Per un audit minimo, ha senso elencare i pacchetti installati e le connessioni attive, soprattutto su host condivisi o workstation di amministrazione:

snap list
snap connections

Se trovi un pacchetto inatteso, non limitarti a rimuoverlo alla cieca: prima identifica chi lo usa e se è stato installato come dipendenza di un altro snap. La rimozione frettolosa di un componente condiviso può lasciare servizi non funzionanti e aprire un incidente secondario.

Rimozione di uno snap: pulita, ma non superficiale

La rimozione è semplice sul piano sintattico, ma va trattata come un’operazione con impatto potenziale. Se elimini un’app, potresti lasciare dati utente, configurazioni locali o revisioni residue. Il comando base è:

sudo snap remove nome-pacchetto

Se l’app è in uso o se vuoi prima capire l’effetto, conviene controllare lo stato del servizio e i processi associati. Alcuni snap espongono anche un servizio systemd correlato, quindi una verifica mirata può essere utile:

systemctl list-units | grep snap
snap services

Dopo la rimozione, `snap list` deve mostrare che il pacchetto non è più presente. Se vuoi capire se restano revisioni o dati, puoi controllare la directory di dati dell’app, in genere sotto `~/snap/` per l’utente e sotto `/var/snap/` o `/var/lib/snapd/` per componenti di sistema. Il punto non è cancellare tutto automaticamente: il punto è sapere cosa stai lasciando sul disco e perché.

Se devi rimuovere uno snap ma mantenere il rischio basso, fai così: prima verifica dipendenze e servizi attivi, poi esegui la rimozione, infine controlla che non siano rimasti mount o unità orfane. Questo approccio evita di scoprire dopo che un demone è ancora registrato ma senza binario valido.

Quando Snap crea attrito operativo

Il primo attrito tipico è l’integrazione con percorsi e librerie tradizionali. Se sei abituato a intervenire direttamente su file in `/usr/bin`, `/etc` o `/var/www`, Snap ti impone un confine diverso. Le configurazioni possono stare in directory specifiche del pacchetto, e il comportamento va letto secondo la documentazione dello snap, non secondo l’abitudine della distro.

Il secondo attrito è l’aggiornamento automatico. Su desktop è un vantaggio, in produzione può essere un rischio se non hai finestre definite. Il terzo è il confinamento: protegge, ma può bloccare l’accesso a risorse che un’app legacy dava per scontate. In questi casi il problema non è “Snap non funziona”, ma “Snap sta facendo esattamente quello per cui è stato progettato”.

Un esempio pratico: un tool amministrativo installato come snap può non vedere una share montata in modo non standard. Prima di pensare a bug del pacchetto, controlla interfacce, mount namespace e permessi reali. L’ordine giusto è osservare, misurare, poi cambiare.

Uso sensato in ambiente server e workstation

Su workstation admin, Snap è spesso comodo per strumenti che devono essere aggiornati rapidamente e mantenere una versione coerente tra più macchine. Su server, il suo valore cresce quando vuoi semplificare rollback e controllo della release, ma solo se accetti il modello di aggiornamento e confinamento. Se hai un’infrastruttura con standard molto rigidi su filesystem, hardening e change management, devi valutare se il guadagno operativo compensa il nuovo livello di complessità.

La regola pratica è questa: usa Snap per applicazioni che beneficiano di versioning esplicito, aggiornamenti frequenti e rollback semplice. Evitalo per servizi dove il packaging tradizionale o un container orchestrato ti danno più controllo sul ciclo di vita. Non è una scelta ideologica, è una scelta di manutenzione.

Checklist operativa rapida

1. Verifica che `snapd` sia attivo con `systemctl status snapd` e `snap version`.
2. Installa lo snap con `sudo snap install nome-pacchetto` e controlla la revisione con `snap list`.
3. Se devi cambiare ramo, usa `sudo snap refresh nome-pacchetto --channel=...` e conferma con `snap info nome-pacchetto`.
4. Prima di un rollback, consulta `snap changes` e `snap tasks <ID-CAMBIO>` per avere la timeline.
5. Per rimuovere, esegui `sudo snap remove nome-pacchetto` e poi verifica residui con `snap list` e `snap services`.

Se tratti Snap come parte del lifecycle del servizio e non come un semplice “installer”, diventa uno strumento utile. Se invece lo usi senza controllare canali, refresh e confinamento, rischi di attribuirgli problemi che in realtà derivano da una gestione incompleta. La differenza sta tutta nella disciplina operativa.