1. 3
  1.  

  2. 2

    Al caro Lennart vorrei erigere un monumento, perché systemd mi ha risolto un sacco di problemi. Lo dico da sistemista. L’unica osservazione che si può fare è: ma perché nessuno ci aveva pensato prima di lui?

    La velocità del boot, benché benvenuta, non è la ragione principale per apprezzarlo. È Un tale capolavoro che è secondo per importanza solo al kernel. E ha ancora da crescere parecchio, visto che tutto ciò che permette il kernel può essere abilmente sfruttato per alleggerire il lavoro di chi scrive software. È esattamente ciò di cui il kernel Linux aveva bisogno - e non sto parlando con enfasi.

    Il fatto è che certi concetti sono alquanto obsoleti. Per esempio: un’unica cartella /etc con le configurazioni è comoda, sì… se si pensa a un sistema con poche decine di processi e servizi. Ma poi, dev’essere scrivibile? Chi deve poter accedere? E se per scrivere ci vuole il permesso di root, significa che “qualcuno” può vedere (o modificare!) comodamente la configurazione di “qualcun altro”? E se poi il sistema dev’essere embedded (cioè col minor spazio possibile “scrivibile”, perché tutto ciò che è read-only si può mettere su EPROM/ROM o periferiche in cui solo la write è critica), dove vanno spostati i file di configurazione che devono restare scrivibili? E come si può fare per garantire che un tal processo non abbia accesso a tale o talaltra directory? O rendere tale alberatura solo in lettura “per gli altri” e anche scrivibile “per me”? O limitare tali e talaltre capabilities del kernel?

    L’articolo è di pura politica. Ti è antipatica la Red Hat? Ti è antipatico Poettering? Allora sei il benvenuto. Altrimenti potresti accorgerti che a “cooperare strettamente col systemd” il tuo servizio ha tutto da guadagnare. Non devi più inventarti una soluzione di un pidfile per evitare di partire due volte, e una per ripartire quando vieni chiuso per qualche motivo. Non devi più preoccuparti di controllare con che user sei partito, di blindare la tua directory temporanea, di prevedere una directory dove riversare le tue poche decine di righe di log, di prendere contromisure per impedire che altri processi scrivano nelle directory che al più concedi solo di leggere… In altre parole, systemd scarica sull’amministratore di sistema (e in poche, concise, chiare righe di un file di testo) le “cose di sistema” di cui tipicamente i servizi si affannano a compiere alla partenza. Che in due righe di configurazione può stabilire che tale alberatura è scrivibile solo da te (con un gioco di mount private previsto dal kernel), riducendoti il tempo in cui ti è necessario avere i privilegi di root o addirittura rendendoli non più necessari per le inizializzazioni.

    Che la RedHat persegua questi obiettivi, è a dir poco lodevole - tanto più che systemd è in LGPL. Ad essersi scottati sono quelli che pensavano di gestirsi systemd col solito sistema del mantenere un’unica versione e mandare per un paio d’anni (o più) solo le patch di sicurezza. Andrà a finire - con loro suprema ignominia - che lo stesso sorgente, se eseguito da un systemd è più sicuro che se eseguito in un Linux senza systemd, perché nel secondo caso le precauzioni sono solo quelle prese dal software, nel primo caso si aggiungono le limitazioni che il maintainer/packager aveva esplicitamente aggiunto.

    L’unico ragionevole timore dovrebbe essere l’eventualità (piuttosto improbabile, visto che sarebbe “politicamente” controproducente per Red Hat) che una futura versione del systemd venga rilasciata non più sotto LGPL ma con qualcosa di restrittivo o di closed-source con supporto esclusivamente commerciale (può succedere, è già successo, per esempio nel caso di osxfuse).

    1. 2

      Grazie @alf per la tua prospettiva sistemistica.

      Per quanto mi riguarda, IBM non gode della mia simpatia, ma guardo a systemd da una prospettiva diversa che è sia tecnologica (architetturale) che politica.

      Oltre alle osservazioni dell’autore (che condivido) credo che systemd persegua esigenze che lo rendono inevitabilmente troppo complesso. Attenzione, complesso, non significa necessariamente difficile da usare: Per esempio Google (il motore di ricerca) è facile da usare, ma estremamente complesso (difficile dire se “troppo”, in questo caso). Nel caso di systemd, la maggioranza della complessità è interna, nascosta dall’amministratore che lo usa (da cui credo derivi il tuo apprezzamento), ma rimane un problema architetturale e politico.

      Architetturale perché la sicurezza di un sistema è inversamente proporzionale alla sua complessità.
      Per esempio, se non erro, tutti i problemi che descrivi sono risolvibili con bind.

      Politica per diverse ragioni:

      • portabilità: qualunque software dipenda da systemd, dipende da Linux e diventa meno portabile
      • ridotta varietà: la ridotta portabilità del software aumenta i costi per la realizzazione sistemi alternativi (e migliori) di Linux (per non parlare della sciagurata scelta di Debian di farlo diventare il sistema di default)

      Purtroppo, come sottolinea l’autore, systemd si è imposto attraverso tattiche commerciali che non tengono conto di questi fattori architetturali (e che anzi li considerano un potenziale vantaggio per i competitor). Tattiche di lobbying e lock-in che peraltro funzionano in ogni settore in cui non ci sia una visione architetturale, di insieme, sufficientemente diffusa.

      Di conseguenza, considero systemd un sintomo di un problema più grave.