Ho sempre avuto un rapporto di amore/odio con le distro basate su RPM.
Non si può discutere la qualità (ed il contributo determinante nell'ambiente GNU/Linux) dei prodotti di colossi come Red Hat o SUSE, ma spesso mi sono imbattuto in problematiche non riscontrate su altre distro (principalmente Debian, Arch o Void Linux).
Scanso agli equivoci, e niente accuse; solo una visione soggettiva dettata molto probabilmente da miei errori, o perlomeno interpretazioni poco corrette.
Comunque non sono uno che si arrende tanto facilmente...
Ahimè, la prime esperienze con openSUSE MicroOS non fecero eccezione.
Spinto dal proposito di rendermi la vita più semplice sul ThinkPad, optai per la versione Aeon, ossia quella che prevede GNOME come desktop environment.
Non così male in verità, squisitamente essenziale, ma un po' noiosa per i miei canoni, e appena troppo pesante con l'hardware che mi ritrovo.
Decisi allora di tornare sui miei passi e partire da un'installazione minimale, per poi tirare su un ambiente composto dal window manager Sway e poco altro. Di male in peggio.
Lightdm faceva i capricci pur avendo adattato la mia solita configurazione per l'autologin priva di greeter, alcuni dotfile sembravano essere ignorati, l'OS pareva non volesse piegarsi alle mie esigenze.
Ma è una distro immutabile dopotutto, mi dissi, sono io che cerco di modificarla troppo!
Ultima chance: Kalpa (Plasma preinstallato) sul mini pc dell'ufficio.
Anche qui non resistetti molto. Non si poteva certo definire un sistema inutilizzabile, ma mi scontrai presto in traduzioni mancanti e non facilmente integrabili, autologin non funzionante nemmeno con attivazione dal pannello grafico delle impostazioni, pacchetti brandizzati non voluti e problemi vari.
Reinstallai Arch Linux, anch'esso con Plasma (dallo script di installazione archinstall), distro che utilizzo tutto'ora senza particolari problematiche.
Ciò che aveva attirato la mia attenzione nei confronti di questa distribuzione sono alcune sue caratteristiche peculiari.
Innanzitutto si coniuga l'immutabilità ad un rilascio di tipo rolling release.
Poi ci sono gli aggiornamenti atomici, che derivano dai sempre freschi repository di Tumbleweed e si appoggiano sugli snapshot di Btrfs.
È evidente inoltre una predisposizione alla containerizzazione, con la possibilità di un'installazione con Podman e Distrobox pronti all'uso.
Il comando transactional-update è utile per modificare le "zone proibite" del sistema, oltre che indispensabile per la gestione dei pacchetti al di fuori di Flatpak e container (gli unici metodi raccomandati per installare programmi, ma solo a livello utente).
L'interfaccia per RPM Zypper, richiamata da transactional-update per effettuare la maggior parte delle operazioni, è un tool snello ed elegante e con un'ottima sintassi dei suoi comandi.
Dopo le "specifiche tecniche", cerchiamo di capirci qualcosa.
Un sistema operativo immutabile si distingue da uno più "tradizionale" per via della sua struttura che non permette modifiche.
Questo si traduce in molte parti del file system montate in read only, ossia in sola lettura. Con questo stratagemma si riduce la possibilità di intervento delle applicazioni e dell'utente stesso, con ripercussioni positive su sicurezza e stabilità.
Nel caso di MicroOS l'accesso completo è riservato solo ad alcune cartelle: /etc, /home, /root e /var (fondamentalmente per i dati degli utenti e alcune configurazioni).
Tutto il resto, comprese le directory dove di solito risiedono le applicazioni, non può essere modificato direttamente.
A questo punto il concetto di distro immutabile e quello di rilascio continuo (o rolling release), dove gli aggiornamenti sono costanti e non c'è necessità di cambio di versione, potrebbero sembrare agli antipodi.
In realtà l'immutabilità è un buon modo per ottenere maggiore stabilità anche l'addove gli update siano molto frequenti, specie con l'ausilio di aggiornamenti atomici e snapshot.
Ciò significa che gli aggiornamenti vengono scaricati, ma non vanno ad inficiare mai sulla sessione corrente, perché la loro installazione avviene effettivamente solo dopo un riavvio.
Ad ogni update del sistema viene creato anche un nuovo snapshot, letteralmente una "fotografia" dello stato attuale di tutta la parte immutabile del file system. In caso di problemi si può facilmente ripristinare un vecchio snapshot con la procedura di rollback.
Le cartelle "mutabili" sopracitate non vengono incluse negli snapshot, restando persistenti.
Per consuetudine la rappresentazione dei comandi da impartire con sudo o con l'utente root avviene con il prefisso "# ", che non va digitato nella shell.
Allora è impossibile modificare ciò che gli sviluppatori hanno deciso di bloccare? Non proprio.
Si tratta di una pratica sconsigliata, ma che resta possibile.
Su MicroOS ci viene in soccorso il comando transactional-update. Se invocato senza nessun parametro, si occuperà della ricerca ed installazione di eventuali aggiornamenti di tutti i pacchetti di sistema (e fin qui niente di non raccomandato, anzi!).
Con alcuni parametri aggiuntivi le cose si fanno più interessanti.
Come installare un pacchetto (per esempio htop) a livello di sistema:
# transactional-update pkg in htop
Ora la rimozione:
# transactional-update pkg rm htop
Tutto ciò che ci occorre per ottenere una shell completa, come se stessimo lavorando su una distribuzione non immutabile:
# transactional-update shell
Questi ultimi comandi andrebbero evitati se non si vuole rischiare di compromettere l'integrità del sistema, ma permettono di compiere operazioni fondamentali altrimenti impossibili, come installare dei driver specifici.
Dopo ogni operazione svolta con transactional-update, vi verrà chiesto di riavviare per consentire l'applicazione del nuovo snapshot con le modifiche apportate. A tal proposito il parametro shell può tornare utile per aggregare più comandi e ridurre la necessità di reboot.
Un piccolo trucchetto (da non abusare, ed altamente sconsigliato per modifiche molto rilevanti) per applicare un nuovo snapshot senza riavviare:
# transactional-update apply
Bene ma non benissimo su desktop dunque, eppure non me la sentii di abbandonare definitivamente un progetto con tutte queste potenzialità.
Per questo feci un altro tentativo, che stavolta andò piuttosto bene: usare MicroOS per un piccolo server dedito ad un po' di virtualizzazione leggera, condivisioni con Samba, ed eventualmente qualche container su Podman (che tendenzialmente preferisco a Docker).
Come detto in precedenza, l'installer della distribuzione facilità la creazione di un ambiente adatto ai container, ma non solo.
Nonostante l'aspetto austero ed istituzionale, ben diverso da quello di alternative come Calamares, la procedura di installazione di MicroOS (ed in generale di tutte le distro di openSUSE) è abbastanza semplice da gestire e permette una personalizzazione profonda.
Se la scelta dei pacchetti da comprendere nell'installazione è un po' macchinosa e limitata a quelli presenti nella ISO, opzioni come il partizionamento, la configurazione del bootloader, la gestione del firewall e dei meccanismi di sandboxing riservano sorprese in positivo.
Le impostazioni di default, come spesso accade, potrebbero essere quelle più consigliate; tuttavia si può optare anche per la disabilitazione di funzionalità prettamente enterprise (Firewalld, SELinux ecc..) .
Attenzione, si tratta di scelte personali che richiedono approfondimenti e consapevolezza, e che possono avere conseguenze più o meno gravi a seconda del tipo di utilizzo a cui la macchina sarà destinata.
Su una distribuzione pensata per uso server generalmente è superfluo aggiungere utenti non amministatori, ma si può agire con l'account root, già configurato ed attivato durante l'installazione.
Ho proceduto quindi con l'aggiunta dei pochi pacchetti necessari per i task richiesti (Samba e virtualizzazione):
# transactional-update pkg in libvirt libvirt-daemon-qemu qemu-tools samba virt-install virt-manager
Se pensate che virsh non sia troppo complicato, non avete bisogno di virt-manager per la gestione delle macchine virtuali.
Dopo un riavvio possiamo aggiungere l'utente ai gruppi necessari:
# usermod -aG kvm,libvirt user
Abilitiamo i servizi:
# systemctl enable --now smb libvirtd
Attiviamo e rendiamo persistente la rete NAT per le macchine virtuali:
# virsh net-start default && virsh net-autostart default
Attenzione al file di configurazione di Samba (/etc/samba/smb.conf): potrebbe essere necessario modificarlo affinché la condivisione dei file con Windows possa funzionare correttamente.
Facendo la giusta selezione nell'installer, Podman e Distrobox invece non richiedono configurazioni aggiuntive (creazione dei container a parte, si intende).
SUSE ed openSUSE, dopotutto, si possono considerare le alternative europee a Red Hat e Fedora.