OSTree: un nuovo modo di distribuire il software e gli OS

ostree

È da un po’ di tempo che se ne parla dietro alle quinte ma i più non sono ancora a conoscenza del progetto che, a mio modesto parere, cambierà il modo di concepire gli aggiornamenti e non solo all’interno di una distribuzione Linux. Mi sto riferendo ad OSTree, prodotto dallo sviluppatore Red HatColin Walters.

Sono due le funzioni chiave di questo software, la prima a cui mi voglio rifare è senz’altro quella di Continuous Integration System. Come ben sapete molte distribuzioni o Desktop Environment vengono “costruiti” a partire da un molteplice numero di repository Git (o qualsivoglia altro VCS) che contengono rispettivamente i codici sorgenti delle varie applicazioni o software in questione che, poi, successivamente, verranno compilati (ed eventualmente pacchettizati) ed in seguito eseguiti sui computer degli utenti.

Uno dei problemi che gli sviluppatori si pongono da sempre è avere la possibilità di testare il prodotto completo del proprio lavoro direttamente dopo l’esecuzione di un commit sul repository del software su cui stanno lavorando. È qui che il progetto OSTree entra in gioco creando e ricreando direttamente dalle master branch dei rispettivi repository una distribuzione (come nel caso di Fedora-OSTree) od un DE (come nel caso di GNOME-OSTree / GNOME OS) direttamente eseguibili da un file ISO bootabile attraverso un manager di macchine virtuali.

OSTree, quindi, non permette solo di testare le modifiche ad un singolo software ma bensì all’intero set di applicazioni che andranno a comporre la distro od il DE di riferimento (utile, ad esempio, nel caso di regression tests). Questo comporta che gli stessi utenti potranno testare le ultimissime novità della loro distribuzione o DE preferiti scaricando una delle ISO che vengono costantemente generate da OSTree. (Ad esempio, l’ultimissima ISO del progetto GNOME può essere scaricata al seguente indirizzo)

La seconda funzione a cui voglio rifarmi deriva, invece, dal concetto dei cosiddetti Atomic Upgrades. Al momento la pletora delle distribuzioni esistenti sta facendo uso degli aggiornamenti di tipo live, aggiornamenti, che, quindi, vengono applicati direttamente al filesystem root del computer dell’utente. È possibile che a causa di un errore nell’applicazione degli aggiornamenti, di un reboot forzato o di un calo di corrente (che possa portare la macchina al shutdown improvviso), il computer stesso possa ritrovarsi in uno stato di inconsistenza.

Il progetto OSTree mira a risolvere e prevenire questo tipo di problemi tramite la creazione, durante l’aggiornamento del sistema, di un secondo albero di file e directory copia esatta del filesystem di root mediante l’utilizzo di hardlinks. Questo secondo albero di file e directory vedrà l’applicazione effettiva degli aggiornamenti in sospeso. Ma cosa accadrà qualora ci sia un errore nella applicazione degli stessi oppure un semplice reboot / shutdown della macchina? OSTree farà in modo che la copia del filesystem divenuta inconsistente sarà rimossa completamente in modo tale che al successivo reboot il computer farà uso del filesystem root “originale”. La macchina, quindi, non risulterà compromessa da un erronea applicazione degli aggiornamenti ma rimarrà esattamente nello stato in cui si trovava prima dell’applicazione degli stessi.

Il progetto di Walters non andrà a sostituire gli attuali package managers ma si porrà ad un livello più basso e probabilmente andrà ad influire sulla stessa esecuzione di Yum e Apt tramite l’apposita creazione di un backend che permetterà allo stesso OSTree di interfacciarsi direttamente con i gestori dei pacchetti delle distribuzioni.

Tag: , , ,

Commenti

  1. [1]

    In pratica uno snapshot a mo’ di BTRFS, ma automatizzato?

  2. [2]

    @SilverHawk:
    credo di no, considerando che da quel che ho capito linka il sistema corrente in puntamenti tipo /cartella.old…
    Da quello che ho capito è uno strato successivo al filesystem stesso che viene richiamato solo dal teorico gestore dei pacchetti (yum e apt appena disponibile backend), quindi tecnicamente è qualcosa di diverso rispetto a btrfs dove il file sistem viene fondamentalmente visto come file raw espandibile e al momento di effettuare uno snapshot semplicemente viene creato un nuovo file raw per tutto ciò che accade dopo, almeno questa è l’impressione molto semplificata…

  3. [3]

    Tanta roba! Complimenti.

Inserisci il tuo commento