Systemd ripensa i chroot introducendo i Portable Services

2

Quando si parla di systemd, il sistema di init ideato da Lennart Poettering e diventato oramai il default per le principali distribuzioni Linux, ci si avventura sempre in un campo minato.

Tra i sostenitori ed i detrattori, il rumore è molto alto, ed ognuno mette sul piatto i vantaggi e gli svantaggi di usare un sistema piuttosto che un altro.

Obiettivamente, però, è risaputo che systemd tende a voler fare da padrone il più possibile: nato per la gestione del mero avvio/stop dei servizi, si è avventurato nella gestione dei componenti network, di mount dei filesystem, e di cose che, in effetti, potrebbero non essere necessarie all’interno di un sistema di init, ma che vengono incluse al grido di “semplificazione della gestione”.

Con la prossima versione del sistema, la 239, sarà inclusa una feature sulla quale lo stesso Poettering sta lavorando da mesi: i Portable Services.

Ma di cosa si tratta? Guardando la documentazione presente sul repository Git del progetto, pare sia una feature atta a semplificare l’uso sul proprio sistema di servizi imprigionati all’interno di chroot, ovvero servizi che vedono una porzione del filesystem convinti di vederlo tutto (ok, stiamo semplificando).

Fondamentalmente quello che si vuole raggiungere è:

      Il raggruppamento delle applicazioni in oggetti riutilizzabili, ovvero la possibilità di raggruppare più di un servizio, i relativi binari, e tutte le dipendenze in “immagini”, ed eseguire questi servizi direttamente da li
      Il rafforzamento della sicurezza tramite il sand-boxing, ovvero la chiusura di questi servizi in aree ben specifiche, senza possibilità di uscire e “vedere” il resto del sistema

Ma dove abbiamo già sentito questi concetti, seppur in maniera leggermente differente? Ah, già, i tanto chiaccherati container!

E questo lo sa bene chi ha aggiunto questa feature, al punto da fare una chiara distinzione:

The “portable service” concept ultimately will not provide a fully isolated environment to the payload, like containers mostly intend to. Instead they are from the beginning more alike regular system services, can be controlled with the same tools, are exposed the same way in all infrastructure and so on. Their main difference is that the use a different root directory than the rest of the system.

Il concetto di “portable service” alla fine non fornisce un ambiente totalmente isolato, come intendono fare i container. Invece sono fin dall’inizio più simili ai servizi di sistema, che possono esse controllati con gli stessi tool, e che sono esposti alla stessa infrastruttura, e via dicendo. La loro differenza principale è che usano una root directory differente dal resto del sistema.

E da qui, ecco il paragone con le prigioni chroot. Di base, quindi, un “Portable Service” è un’alberatura di directory di un OS all’interno di una particolare directory, o inserita in un’immagine disco (se preferite questa solizione), e che può essere agganciata o sganciata dal sistema.

Quando viene agganciata, le units systemd (i servizi, etc.) presenti all’interno di quell’alberatura vengono rese disponibili nel sistema principale, e possono essere gestite esattamente come units locali, nonostante siano eseguite all’interno della sola alberatura di riferimento; ovviamente, nel momento in cui viene sganciata questa alberatura, tutte queste nuove units spariscono dal sistema.

Insomma, a quanto pare sembrerebbe niente di più che un sistema estremamente comodo (se siete legati all’uso di systemd) per gestire ambienti chroot in maniera trasparente, come fossero normali servizi del sistema, il che sembra interessante.

Uno dei punti di forza sottolineati è che non è presente una procedura unica per la generazione di queste alberature, ma è possibile utilizzare il tool che si preferisce, da dnf a debootstrap, da pacstrap a zypper.

E nell’ottica di fornire un sistema centralizzato per tutto, cosa che entusiasma Poettering, vengono forniti anche due nuovi tool:

  • mkosi: un wrapper intorno ai tool citati sopra per la generazione di alberature di OS
  • portablectl: che affiancherà systemctl nella gestione di questi specifici servizi

Voi come la vedete questa introduzione? Sarà una buona cosa che in questo periodo di spinta sui container si usi ancora del tempo per (ri)affermare alternative come gli ambienti chroot o è inutile allo stato attuale?

Utente Linux/Unix da più di 20 anni, cerco sempre di condividere il mio know-how; occasionalmente, litigo con lo sviluppatore di Postfix e risolvo piccoli bug in GNOME. Adoro tutto ciò che può essere automatizzato e reso dinamico, l’HA e l’universo container. Autore dal 2011, provo a condividere quei piccoli tips&tricks che migliorano il lavoro e la giornata.