Systemd-homed, la gestione delle home directory in salsa Systemd

Raoul Scarazzini

25 Settembre 2019

Lo diceva Bob Parr nel film “Gli Incredibili“:

Per quante volte uno salvi il mondo, quello riesce sempre a mettersi nei guai!

Noi ci si prova anche a valorizzare systemd e lo diciamo da sempre con estrema serietà: alcune delle innovazioni introdotte dal sistema di init ideato e manutenuto dal team di Lennart Poettering fanno la differenza. Basti pensare alla gestione delle dipendenze dei servizi o all’elevatissima personalizzazione applicabile agli stessi. Insomma, è certamente un bel pezzo di codice.

Poi però…

Accade che ci si imbatte in notizie, come questa di Phoronix, che annunciano systemd-homed, una nuova componente di systemd focalizzata a migliorare la gestione delle home directory.

E allora un paio di domande ce le si fa.

Le home directory. Cosa può portare a pensare che ci sia bisogno di intervenire, anzi di gestire inglobando, uno dei capisaldi di GNU/Linux (e prima ancora Unix), che da sempre ha fatto la differenza tra i sistemi multi-utenza proprio per il principio della segregazione mediante permessi?

La lista delle migliorie che systemd-homed vorrebbe apportare è la seguente:

Home directory più trasportabili;
L’assicurazione che tutti i dati degli utenti sono contenuti all’interno delle home directory;
Assegnamenti degli UID gestiti dal sistema locale;
Password utente unificate;
Miglior supporto alla criptazione dei dati;
Altri fantomatiche migliorie modernizzanti;

È davvero la trasportabilità delle home directory un problema? Lo è mai stato l’assegnazione dei permessi? Esistono esigenze rilevanti riguardo alla criptazione dei dati che potrebbero portare ad aver bisogno di un componente terzo (systemd, appunto) che le gestisca?

Posto che il problema possa essere una reale separazione dei dati utente dal sistema con la possibilità, ad esempio, di rendere le home non influenzabili dagli upgrade di sistema, mi arrendo: non sono riuscito a trovare uno use case che giustifichi l’entrata in scena di systemd.

Voi sì? Scrivetelo nei commenti, così possiamo predisporci per parlare di systemd-boot, per gli amici sd-boot, il boot manager UEFI di systemd!

Raoul Scarazzini

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

Notizie

directory, home, homed, systemd

16 risposte a “Systemd-homed, la gestione delle home directory in salsa Systemd”

sabayonino

25 Settembre 2019

E’ un abominio !
michele

25 Settembre 2019

E’ arrivato il momento di cercare un’altra distro che non sia Debian/Fedora e derivate. Se slackware fosse più aggiornata! Mi sa che provo Devuan
GCvl

25 Settembre 2019

Considera anche antiX! Rispetto a Devuan beowulf ha meno problemi di dipendenze (ad esempio conflitto GParted – gvfs) e il loro strumento per creare snapshot iso personalizzate, avviabili, installabili e redistribuibili è semplicissimo e fenomenale!
Gianni

25 Settembre 2019

Un vantaggio potrebbe essere quello di avere una sola home per diversi account-dispositivi tenendola su una chiavetta o in cloud.
Una funzionalità che sarebbe molto apprezzata da sviluppatori e chi personalizza molto.
JustATiredMan

28 Settembre 2019

E’ inutile. Un po alla volta è lo stesso systemd che sostituirà linux nelle distribuzioni.
Se non vi piace sysyemd, bisogna proprio cambiare s.o. ed andare verso *Bsd. Perché bene o male systemd, ve lo troverete sempre in mezzo ai piedi, se vorrete continuare ad usare una qualsisi distribuzione linux mediante diffusa.
michele

29 Settembre 2019

io e gentoo ci odiamo (scherzo è gentoo che odia me). Provai ad installarla una decina d’anni fa. Ma nulla non sono mai riuscito a completare l’installazione
michele

29 Settembre 2019

BSD come uso desktop su un portatile non è proprio il top. Provai FreeBSD ma non mi entusiasmo (a parte l’installazione e la gestione dei pkg e la novità, per me, in se)
Giorgio Brambilla

29 Settembre 2019

Prova anche MX Linux. Più semplice di Devuan. Usa Debian Stable come base ma ha propri repository per il backport dei programmi dalla testing in maniera che il software sia sufficientemente recente. XFCE abbastanza rivisto come window manager, e una serie di utility che facilitano la gestione del sistema. Comodissima, stabilissima, leggera e non usa systemd.
michele

30 Settembre 2019

sicuro non usi systemd?Sul sito distrowatch è segnata la versione 232 per il ramo stabile e 241 per quello in sviluppo, ne parlano anche nel loro forum, in una discussione accessa su problemi relativi a systemd e le sue dipendenze, gli viene consigliato di pasare a antix https://forum.mxlinux.org/viewtopic.php?f=108&t=52823#p528575
Raoul Scarazzini

30 Settembre 2019

Posso garantire che tutto c’è tranne pregiudizio nei confronti di systemd, non è la buzzword a far dire “è inutile”, ma la riflessione generale su cos’è destinato a fare. Tutte le riflessioni che proponi sono legittime e sensate, ma non hai considerato i “danni collaterali” quali l’innalzamento della complessità di gestione, la centralizzazione di funzioni specifiche ad un unico componente, la difficoltà nel fruire delle risorse una volta che queste sono gestite da systemd.

Scrivi:

tutta questa roba non è nativamente gestita da nessun OS Linux

ma è un’informazione inesatta. La gestione centralizzata delle cartelle c’è da sempre in Linux e prima ancora su Unix, e si ottiene con una riga di configurazione di autofs. Era una domanda parte dell’esame RHCE già nel 2003 e… CIFS era compreso nel prezzo 🙂 Poi sul fatto che tu definisca JSON facilmente parsabile posso solo dire… I gusti son gusti 🙂

In sostanza Linux sta finalmente diventando un degno erede di Solaris e, sì, Windows, lato enterprise. La strada è comunque ancora lunga, però questi step sono più che positivi.

Degno erede di Solaris? “Finalmente”? La diffusione attuale di Linux nell’enterprise ha ormai da tempo surclassato Solaris, non è minimamente argomento di discussione. Ad ogni modo su Reddit, così come su Phoronix, così come ovunque l’opinione principale è una ed una soltanto: systemd è il parco giochi di Poettering, costantemente alla ricerca di qualcosa di nuovo da far gestire all’init del sistema (capito? INIT, non il sistema operativo).
Raoul Scarazzini

30 Settembre 2019

Wow la tua risposta è veramente, veramente lunga. Provo a rispondere in sintesi:

Esempio specifico: per fare operazioni comuni si dovrà passare da un comando che si chiamerà (presumibilmente) homectl il quale, distaccandosi dallo standard è implicitamente qualcosa di nuovo da imparare e che si discosta per continuità dal passato.

Non mi pare che reimplementare una libreria per un protocollo di comunicazione pubblicato su Freedesktop e che parsi un JSON sia un problema tecnico.

Direi che abbiamo due concezioni diverse della definizione di “problema tecnico”.

Nota storica: nel 2003 l’RHCSA non esisteva. Esame unico, >=70% eri RHCT, >= 80% eri RHCE. Altri tempi 🙂

E da quando la diffusione di un OS è un metro per evidenziare quanto tecnologicamente evoluto esso sia?

Tecnologicamente avanzato, nessuna, funzionale al suo scopo: assoluta.

Quindi ci stai dicendo che systemd-homed gira nel PID1? Davvero?

Uhm… Direi che non sono riuscito ad esser chiaro. L’unico punto che mi preme sottolineare, che poi è la critica fatta da sempre a systemd, è che, in teoria, un sistema di init dovrebbe occuparsi unicamente di quanto concerne… l’init: quindi portare il sistema da pid 0 a pid 1 e fungere da interfaccia, da lì in avanti, per l’iterazione dei servizi. Tutto il collaterale aggiunto da systemd – quindi la rete, la gestione del login, la gestione dei log, ora anche il boot – non dovrebbe, quantomeno sulla carta, essere affar suo.

Ma non vorrei apparire ottuso nel mio ragionamento. Come dici giustamente tu, la tendenza è quella di orientarsi verso una nuova modalità in cui systemd di fatto sarà interfaccia *di tutto* per elevare finalmente Linux al rango di sistema operativo Enterprise. Ciò su cui ci interroghiamo è proprio questo: c’è davvero necessità di tutto questo?
Raoul Scarazzini

30 Settembre 2019

Però dimentichi il fatto che non avere
una interfaccia comune che funga da collante per le componenti rende
difficile ottenere funzionalità avanzate, che è il limite della
filosofia UNIX.

Ecco, su questo siamo totalmente in sintonia e trovo tu abbia scritto una verità sacrosanta che in fondo è alla base di tutti i perché delle scelte fatte con systemd. Per quanto impopolare quello che il progetto di Poettering esprime è ciò di cui le aziende, Red Hat in primis, hanno bisogno per essere di classe enterprise. Tant’è che l’oggetto della discussione, almeno a livello meramente personale, è sempre come si stia arrivando a quel punto, non se ci si debba arrivare.
Grazie delle argomentazioni che hai fornito e della civiltà con cui siamo riusciti a discutere.
Giorgio Brambilla

26 Maggio 2020

MX usa SysVinit come sistema di init predefinito ma da la possibilità, in fase di installazione, di utilizzare Systemd, associato ad un apposito kernel, che non è quello predefinito.
E’ vero però che anche nella versione di default è presente il pacchetto systemd-shim che effettua una sorta di emulazione per poter utilizzare applicazioni (cups, pulseaudio, ecc.)che lo hanno come dipendenza.
Questo è ciò che viene comunicato dalla distro:
“Systemd è incluso per impostazione predefinita ma non è abilitato.
Puoi controllare il tuo sistema MX e troverai file che contengono il nome systemd*, tuttavia essi forniscono semplicemente una base di aggancio e di compatibilità se si rendesse necessario.
MX Linux usa systemd-shim, che emula le funzioni di systemd necessarie per eseguire gli helper senza utilizzare effettivamente il servizio init. Ciò significa che SysVinit rimane il servizio di init predefinito ma nel contempo MX Linux può continuare ad usare i pacchetti Debian che hanno dipendenze con systemd come ad es. Il Gestore di Stampa CUPS e il Gestore delle Connessioni di Rete. Questo approccio consente inoltre all’utente di avere la possibilità di scegliere il proprio init preferito.
Un metodo base per abilitare systemd in MX Linux è reperibile nel Wiki di MX/antiX, sebbene non venga fornito alcun supporto ufficiale per gli utenti che scelgano di eseguire MX Linux usando systemd.”

Però nel Thread che hai linkato un utente segnala che nonostante avesse fatto la scelta predefinita con sysvinit poi installando alcuni pacchetti questi si sono portati dietro dipendenze o hanno attivato quelli presenti riuscendo ad interferire con alcune funzioni e programmi come fa di norma systemd.
Va però detto che:
Sembra che il problema sia capitato solo a lui.
Sembra che la cosa si sia verificato con un aggiornamento del kernel recente, in precedenza con lo stesso sistema, stesse applicazioni ma un kernel diverso non si era verificata nessuna interferenza.
E’ stato invitato a fare una segnalazione nel bug traker di MX
E’ stato invitato ad usare antiX anche per il tono un po’ polemico che aveva.

Quindi MX usa sysvinit come init predefinito, ma usa un emulatore di systemd e la dove questo dovesse interferire attivando funzioni tipiche di systemd, consifera ciò un bug, al momento non è chiaro se la cosa si sia verificata davvero o no.
E’ anche vero che chi non vuole correre nessun possibile rischio può usare antiX o Devuan o tanti altri che non usano neanche l’emulatore, deve però sapere che rinuncerà ad alcuni pacchetti importanti.
Giorgio Brambilla

30 Settembre 2019

MX usa SysVinit come sistema di init predefinito ma da la possibilità, in fase di installazione, di utilizzare Systemd, associato ad un apposito kernel, che non è quello predefinito.
E’ vero però che anche nella versione di default è presente il pacchetto systemd-shim che effettua una sorta di emulazione per poter utilizzare applicazioni (cups, pulseaudio, ecc.)che lo hanno come dipendenza.

Questo è ciò che viene comunicato dalla distro:
“Systemd è incluso per impostazione predefinita ma non è abilitato.
Puoi controllare il tuo sistema MX e troverai file che contengono il nome systemd*, tuttavia essi forniscono semplicemente una base di aggancio e di compatibilità se si rendesse necessario.
MX Linux usa systemd-shim, che emula le funzioni di systemd necessarie per eseguire gli helper senza utilizzare effettivamente il servizio init. Ciò significa che SysVinit rimane il servizio di init predefinito ma nel contempo MX Linux può continuare ad usare i pacchetti Debian che hanno dipendenze con systemd come ad es. Il Gestore di Stampa CUPS e il Gestore delle Connessioni di Rete. Questo approccio consente inoltre all’utente di avere la possibilità di scegliere il proprio init preferito.
Un metodo base per abilitare systemd in MX Linux è reperibile nel Wiki di MX/antiX, sebbene non venga fornito alcun supporto ufficiale per gli utenti che scelgano di eseguire MX Linux usando systemd.”

Però nel Thread che hai linkato un utente segnala che nonostante avesse fatto la scelta predefinita con sysvinit, poi installando alcuni pacchetti questi si sono portati dietro dipendenze o hanno attivato quelli presenti riuscendo ad interferire con alcune funzioni e programmi come fa di norma systemd.
Va però detto che:
Sembra che il problema sia capitato solo a lui.
Sembra che la cosa si sia verificata con un aggiornamento del kernel recente, in precedenza con lo stesso sistema, stesse applicazioni ma un kernel diverso non si era verificata nessuna interferenza.
E’ stato invitato a fare una segnalazione nel bug traker di MX
E’ stato invitato ad usare antiX anche per il tono un po’ polemico che aveva.

Quindi MX usa sysvinit come init predefinito, ma usa un emulatore di systemd e là dove questo dovesse interferire attivando funzioni tipiche di systemd, considera ciò un bug, al momento non è chiaro se la cosa si sia verificata d’avvero o no.
E’ anche vero che chi non vuole correre nessun possibile rischio può usare antiX o Devuan o tanti altri che non usano neanche l’emulatore, deve però sapere che rinuncerà ad alcuni pacchetti importanti.
michele

1 Ottobre 2019

Grazie!
JaK

5 Maggio 2020

Apparendo in dissolveza

In ritardo. Prova void-linux.
Sparendo in dissolvenza

Lascia un commento

GitHub

Vai alla sezione Articoli

Vai ai Saturday’s Talks