Notizie

Infrastrutture che rispecchiano gli ideali della libertà del software

Organizzazioni con risorse limitate possono avere il pieno controllo digitale e fornire comunque servizi moderni? Non è banale, ma la FSFE dimostra che è possibile. Insieme a noi approfondisci la nostra infrastruttura per scoprire come vengono gestiti i diversi servizi della FSFE e affrontate le numerose sfide. Una storia non solo per tecnici.

Organizzazioni benefiche e non profit si scontrano con dei limiti ogni giorno: personale, budget, tempo e la persistente questione di come utilizzare le donazioni nel modo più efficiente possibile. Quando si arriva all'infrastruttura tecnica, molte organizzazioni purtroppo decidono di darla in gestione ad esterni e di utilizzare servizi proprietari e non liberi. Con questa decisione, rinunciano alla libertà del software e quindi al pieno controllo digitale e all'indipendenza.

Fin dalla sua fondazione, più di 20 anni fa, la FSFE ha seguito la strada opposta. Partendo già dall'inizio, ci siamo sempre affidati al Software Libero anche se talvolta ha voluto dire non essere in grado di offrire servizi alla moda. Date le risorse limitate, dobbiamo continuamente scegliere tra funzionalità utili e manutenibilità.

E comunque la nostra infrastruttura non è né perfetta né trasferibile 1:1 ad altre organizzazioni. Ma riteniamo importante che le organizzazioni scambino le loro esperienze e ciò che imparano, soprattutto quando è a riguardo di qualcosa di importante come la libertà del software.

Lasciati quindi condurre in un viaggio attraverso la nostra struttura e i suoi principi, dalle stupende interfacce utente dei nostri servizi, passando dai metodi di virtualizzazione e il monitoraggio, arrivando fino ai server fisici su cui girano. Questa non è una storia solo per gli addetti ai lavori, ma per chiunque sia interessato a rendere o mantenere una ONG indipendente dai fornitori di servizi proprietari.

Un team e i suoi principi

Tutta l'infrastruttura della FSFE è gestita dagli hacker di sistema. Soltanto pochi anni fa, in un momento di maggiore carenza tecnica e di ristrutturazione, il team era composto da sole tre persone. Fortunatamente, da allora abbiamo visto una costante crescita dei membri. Oggi, è un team ben in salute che consiste in 9 volontari attivi, integrato da due membri dello staff che dedicano parte del loro lavoro alle attività del team.

Con un team di queste dimensioni era fondamentale definire i principi fondamentali per questo team, che formano le basi degli obiettivi degli hacker di sistema: più controllo possibile dei servizi e dei server usando 100% Software Libero, trasparenza interna ed esterna e una complessità sostenibile, e allo stesso tempo fornire funzionalità utili ai vari team della FSFE e a tutta la comunità.

A parte il lavoro puramente autonomo, le email e le chat, nei tempi pre-pandemia gli hacker di sistema si incontravano fisicamente anche almeno una volta all'anno, e continuano a farlo ora in maniera virtuale. Durante questi incontri, eravamo in grado di affrontare efficacemente più decisioni complesse e cambiamenti tecnici, ma ci gustavamo anche semplicemente le conversazioni non tecniche e attività divertenti. Il team è coordinato da noi, gli autori di questo testo, Albert e Max, che mantengono anche un vasto numero di servizi e sistemi.

Servizi, servizi ovunque

L'infrastruttura della FSFE è molto orientata ai servizi. I volontari e lo staff si basano su funzionalità di base come inviare e ricevere email o scambiarsi file, ma anche su un sito web alimentato da un sistema di controllo delle versioni, su una wiki, su un sistema di videoconferenza e chat. Per fare solo un esempio delle complesse interconnessioni dei diversi componenti, il solo scrivere e pubblicare questo articolo ha coinvolto almeno 12 servizi che devono funzionare insieme perfettamente.

I servizi più importanti ed attualmente più utilizzati sono Mailman per le mailing list o Gitea come nostro sistema Git per il controllo delle versioni. Al fine di permettere la condivisione e salvaguardare la conoscenza, i nostri curatori della Wiki mantengono MoinMoin, mentre Björn si occupa di Nextcloud per condividere i file, coordinare le attività e modificare collaborativamente i documenti. Gestiamo le nostre istanze di BigBlueButton e Jitsi per le video conferenze, e XMPP/Jabber per le chat testuali. Altri servizi aggiunti recentissimamente sono Matrix come altro servizio di chat, introdotto e mantenuto da Michael, e Peertube per ospitare e condividere i nostri video tramite la nostra infrastruttura, reso possibile da Alvar.

La lista dei servizi è molto ampia ed include anche sistemi fondamentali come il sistema per la gestione degli account e il database della comunità sviluppati da Reinhard, i nostri server DNS, o Drone come nostro sistema di integrazione e distribuzione continua (CI/CD, Continue Integration Continue Delivery) che elabora i dati da Gitea, li controlla, e alla fine li installa su altri server.

È inutile dire che il team riceve periodicamente richieste per fornire servizi aggiuntivi. Qui la sfida è quella di fare una attenta selezione basata sulle risorse disponibili (di calcolo, di spazio, di tempo dei volontari) e stimare l'utilizzo per l'organizzazione, e valutare se una soluzione sia facilmente mantenibile, se non si sovrappone a servizi esistenti e se lascia in generale una buona impressione.

Questo significa anche che dobbiamo testare le soluzioni nella pratica su un periodo di tempo più lungo. La modifica in tempo reale dei documenti è un ottimo esempio, per la quale abbiamo attualmente molteplici possibilità. I documenti più corposi sono spesso modificati con file ODF tramite Collabora Online collegata a Nextcloud, ma alcuni preferiscono usare direttamente Etherpad o Git. Tutte le soluzioni hanno vantaggi e lati negativi, e non è così banale trovare un buon compromesso tra avere varie opzioni da una parte e sovraccaricare le risorse dall'altra.

Virtualizzazione e distribuzione

Se da una parte la FSFE possiede dei server dedicati posti in rack (torneremo sul punto più avanti), tutti i servizi vengono eseguiti in qualche sorta di virtualizzazione. Al momento della stesura di questo articolo, contiamo un totale di 43 macchine virtuali distribuite su diversi centri di elaborazione. Alcune hanno solo un utilizzo interno, ad esempio fare da gateway per altre macchine virtuali o assistere i servizi web creando certificati TLS.

Altre, al contrario, ospitano un certo numero di vari servizi. Dal 2017 stiamo usando Docker come motore per i container. Non è stata una scelta semplice, dal momento che la tecnologia aggiunge molta complessità e talvolta richiede stratagemmi straordinari per poter funzionare in modo sicuro. D'altro canto, specialmente per piccoli servizi o strumenti più complessi scritti da noi, è l'ideale per farli partire velocemente, testarli e distribuirli con il nostro sistema di integrazione continua, fornendo un ambiente locale di sviluppo più o meno uniforme, e mantenere una (innegabilmente limitata) riproducibilità delle configurazioni.

Periodicamente valutiamo motori alternativi che forniscano un accesso senza privilegi di root più trasparente, che siano compatibili con il nostro sistema CI/CD (Drone) e con il proxy inverso, e che preferibilmente non richiedano una sostanziosa riscrittura del codice esistente per la distribuzione. Ancora una volta, anche qui, è importante per gli hacker di sistema che almeno due membri conoscano a fondo la tecnologia ad alta priorità.

Per far partire le macchine virtuali e implementare servizi non legati a container in un modo riproducibile, ci affidiamo molto ad Ansible, uno strumento per la gestione dell'installazione e configurazione. Se anche la messa in servizio con Ansible potrebbe non essere perfetta, apprezziamo l'approccio dell'infrastruttura come se fosse codice, che può essere eseguita da qualsiasi computer e non richiede un server centrale. Nel frattempo, solo pochi servizi non sono mantenuti né da Ansible né da Docker, il che rende più semplice la comprensione dell'infrastruttura esistente, il reclutamento di nuovi volontari e la documentazione dei cambiamenti.

L'occhio che tutto osserva e uniformità

Dozzine di server e servizi: come si fa a sapere se c'è un problema con uno dei essi? Dobbiamo ammettere che solo fino a due anni fa qualche volta venivamo a sapere che un server si era bloccato da una mail di un gentile membro della comunità. Ora abbiamo un sistema di monitoraggio basato su Icinga2 che si occupa di questo. Attualmente ci sono 50 server e 690 servizi che vengono continuamente controllati, ad esempio gli aggiornamenti pendenti del sistema operativo, i servizi di systemd, backup non andati a buon fine, spazio su disco, o validità del certificato TLS.

Questo controllo è semplificato da altre parti della nostra strategia: con l'eccezione di 4 macchine virtuali, su tutti i server gira Debian GNU/Linux. Dopo la creazione iniziale, una nuova macchina viene impostata con una configurazione di riferimento con i settaggi critici per la sicurezza, il monitoraggio, il backup e gli aggiornamenti automatici. Grazie a questo, la manutenzione di un server è per lo più limitata ai servizi che vi girano sopra, e altri miglioramenti possono essere applicati automaticamente a molti server in pochi minuti.

Per rendere ancora più semplice la gestione e la manutenzione, qualche volta scriviamo degli strumenti ad-hoc. Ad esempio, ssh-key-distributor fornisce una interfaccia e un metodo di messa in produzione semplici per gestire e documentare gli accessi via SSH sui nostri server. Oppure docker-utils, che è fatto su misura per la nostra infrastruttura Docker e si occupa di analizzare e aggiornare le immagini Docker e i container. Entrambi gli strumenti sono stati creati dal nostro studente lavoratore Linus. Puoi trovare più strumenti e più in generale la maggior parte del codice di messa in produzione di Ansible/Docker nei repository Git.

Server fisici

Al contrario dell'attuale attuale nell'industria informatica, siamo fieri di far girare la stragrande maggioranza dei servizi sui nostri server fisici. Questo ci garantisce il massimo controllo, la sicurezza dei dati con dischi completamente criptati e l'indipendenza tecnologica. Per incrementare la flessibilità, mettiamo assieme 3 server in un cluster Proxmox con Ceph per lo storage, in modo che se un server fisico dovesse crashare, una macchina virtuale può essere semplicemente spostata su uno degli altri due server del cluster.

Come sicurezza addizionale, i tre cluster e una macchina singola sono spalmati su quattro diversi data center che ci hanno gentilmente donato lo spazio.

Questo è però possibile solo grazie ad una fortunata combinazione di condizioni. Prima di tutto, siamo fortunati di avere Albert con noi che ha moltissima esperienza, tra le varie altre cose, con Proxmox, Ceph e una conoscenza approfondita di come funziona la rete. Poi, abbiamo il gentile supporto dei data center che ci forniscono la possibilità di mettere i nostri server così come anche i donatori dell'hardware, e i sostenitori della FSFE che contribuiscono finanziariamente. E possiamo anche beneficiare di una configurazione all'incirca identica su tutti e quattro i siti che rende la manutenzione un po' più semplice. Ma stiamo comunque considerando di dismettere i cluster formati dai server più vecchi così come la macchina fisica singola per ridurre lavoro e complessità.

Le sfide attuali e future

Nel corso degli anni, siamo riusciti a superare molte sfide: carenza tecnica, software obsoleto che ha bloccato gli aggiornamenti del sistema operativo, mancanza di risorse hardware, crash fatale di componenti singoli, e difficili decisione tecniche di come sviluppare ulteriormente l'infrastruttura. In uno di questi momenti difficili, il nostro prima stagista e da allora hacker di sistema Vincent ha svolto un ruolo importante e ha aiutato a porre le fondamenta per l'ottimo stato in cui siamo oggi. Malgrado tutta la preparazione e tutte le valutazioni, abbiamo sempre fatto molti errori, ma – molto più importante – da essi abbiamo imparato molto.

Ci sono nuovi ostacoli che stiamo affrontando ora. Ad esempio, con un grossa mole di server, non possiamo più dare ad ogni macchina virtuale un indirizzo IPv4 dedicato. Sfortunatamente, molte tecnologie e servizi Internet, e anche grandi aziende proprietarie e presumibilmente professionali, non supportano ancora il più moderno, orientato al futuro e già vecchio di 20 anni protocollo IPv6. Questo richiede di trafficare con qualche stratagemma come il proxy inverso, i servizi di ricerca dei container, NAT e VPN.

Un'altra decisione interessante da prendere è quella che riguarda i canali di comunicazione. Se le email solo testo e, dal 2004, XMPP/Jabber hanno costituito lo standard di fatto per la FSFE, molte persone nel tempo hanno preferito Matrix, Discourse o ancora il tradizionale IRC. Se da una parte vediamo vantaggi e svantaggi in ognuno di questi canali, dall'altra vorremmo anche evitare la frammentazione della nostra comunità. Non è una questione puramente tecnica, ma un ottimo esempio delle necessità per un buona comunicazione all'interno del team e per prendere delle decisioni.

Non da ultimo, abbiamo qualche tecnologia che è per noi un grattacapo. Prendiamo Mailman 2 come esempio con cui sono state gestite le nostre 116 mailing list per anni. Purtroppo il progetto non è più sviluppato attivamente, e il suo successore e le alternative hanno tutti delle serie inconvenienze. Qui abbiamo bisogno di fare una accurata valutazione e molti test, e alla fine trovare la migliorare soluzione tra la mole di opzioni imperfette.

Detto questo, vorremmo esprimere la nostra gratitudine ai molti progetti di Software Libero di tutto il mondo e ai loro sviluppatori. Ci garantiscono la possibilità di scegliere tra diverse soluzioni, formano le fondamenta della nostra infrastruttura e forniscono favolose soluzioni che rendono la nostra vita più semplice ogni giorno. È un piacere essere parte di questa grande comunità.

Perché tutto questo?

Come hai potuto vedere, l'infrastruttura tecnica della nostra organizzazione è tutto fuorché noiosa o semplice. Questo non è dovuto solo alle dimensioni della FSFE e della sua comunità, ma anche ai nostri standard elevati: vivere la libertà del software nella pratica e mantenere quanta più possibile indipendenza tecnica e quanto più possibile pieno controllo. Allo stesso tempo, ci curiamo dell'accessibilità tecnica per permettere anche ai non tecnici di interagire con i nostri servizi. Questo talvolta richiede un lavoro e degli strumenti aggiuntivi, ma siamo convinti che ne valga la pena.

Tutto questo dipende dalla dedizione e dall'impegno a lungo termine di molte persone, ed è alimentato da suo uso produttivo e dai riscontri dell'intera comunità della FSFE. Ed è possibile solo grazie ai sostenitori della FSFE che ci permettono di investire risorse in una infrastruttura completamente formata da Software Libero. Se condividi questo ideale, se puoi fai una donazione.

Commenta l'articolo