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

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…

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!

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.

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

  1. Avatar sabayonino
    sabayonino

    E’ un abominio !

  2. Avatar michele
    michele

    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

    1. Avatar GCvl
      GCvl

      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!

    2. Avatar JustATiredMan
      JustATiredMan

      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.

      1. Avatar michele
        michele

        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)

    3. Avatar Giorgio Brambilla
      Giorgio Brambilla

      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.

      1. Avatar michele
        michele

        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

        1. Avatar Giorgio Brambilla
          Giorgio Brambilla

          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.

        2. Avatar Giorgio Brambilla
          Giorgio Brambilla

          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.

          1. Avatar michele
            michele

            Grazie!

          2. Avatar JaK
            JaK

            Apparendo in dissolveza

            In ritardo. Prova void-linux.
            Sparendo in dissolvenza

  3. Avatar Gianni
    Gianni

    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.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *