Questo report [0] era pronto qualche settimana fa, poi c'e' stato
l'anonimo babbo natale che ci ha regalato i 400gb di ht e tutto il
resto e' passato in secondo piano. La mia produttivita' e' crollata e
anche se lo avessi inviato nessuno l'avrebbe letto (ammesso che
succeda ora). neanche ferragosto e' il momento migliore, ma di questo
passo me lo sarei semplicemente dimenticato :P
E' stato scritto gia' un paio di settimane dopo hackmeeting, quindi
potrei tranquillamente essermi scordato cose, ma sarebbe
interessante continuare a parlarne. E' su pad perche' speravo in
memorie migliori delle mia e soprattutto perche' parla di comunita',
collaborazione, contributi e scambio...
In questi giorni ci sono molte cose in corso, spero di trovare
informazioni, contatti e link utili.
Per comodita' sotto c'e' l'attuale testo sul pad
j.
[0]
https://pad.riseup.net/p/hm0x12_diyserver
Della tavola rotonda "DIYour Server"
Presupposti
- - in prehack ci si era riproposti di affrontare alcuni argomenti in
maniera piu' condivisa, proponendo dei momenti di confronto tra le
realta'/persone presenti;
- - alcuni partecipanti/collettivi hanno a piu' riprese espresso un
interesse mirato riguardo le conoscenze necessarie per la realizzazione
di server indipendenti e servizi autogestiti;
- - quando i compagni/attivisti/amici intorno a noi ci domandano quali
server e servizi possono utilizzare per rompere il meccanismo di
controllo e mercificazione che abitualmente denunciamo, le risposte che
diamo spesso si appiatiscono su pochissime alternative, (es. fai una
casella su riseup/autistici, fai un blog su noblogs, chiedi una mailing
list su autistici/indivia, etc);
Discussione
Documentazione:
Molte delle scelte architetturali e tecniche, sono il risultato di
sperimentazioni e esperienze, anche traumatiche, vissute in prima
persona da amministratori e collettivi. Anche quando le scelte sono
evidenti e documentate, spesso il background e le motivazioni rimangono
invisibili dall'esterno. Se un tecnico vuole avvicinarsi alla
realizzazione di un server autogestito, o si tratta di qualcuno dotato
di abbondante esperienza personale, oppure molto probabilmente sara'
condannato a reinventare molte volte la stessa ruota gia' sperimentata,
con l'ovvio spreco di potenzialita' che ne consegue. D'altro canto, per
chi quella conoscenza l'ha gia' acquisita, risulta oneroso e
apparentemente inutile la scrittura di una documentazione coerente per
descrivere scelte e procedure. Spesso manca la consapevolezza di cosa e'
interessante oppure no e, in un contesto dalle risorse limitate,
documentare tutto a prescindere spesso non e' realistico.
Risorse umane:
Di tutte le risorse necessarie alla riuscita di un progetto, il
tempo-uomo e' quella piu' preziosa e stringente. E' evidente come
l'evoluzione di hardware e storage, l'abbattimento dei costi di
hosting, la maggior disponibilita' di connessioni in fibra rendano
tecnicamente ed economicamente molto piu' affrontabile l'installazione
di un server autogestito. Sia che si tratti di servizi pubblici, o
sensibili, o critici, le soluzioni per la loro realizzazione si sono
moltiplicate e la barriera economica d'ingresso abbattuta: le VPS (per
frontend e indirizzi ip) sono molto economiche, la banda larga su fibra
(per sel-hosting e server casalinghi) e' sempre piu' disponibile nelle
principali citta', l'hardware consumer (in particolar modo dischi e ram)
e' sempre piu' economico/disponibile.
C'e' dell'ovvio quando ci rendiamo conto che e' la conoscenza (il
know-how) l'unica risorsa che non scala secondo le leggi dell'economia.
Si potrebbe addirittura sostenere che dalla moltiplicazione dei servizi,
dell'aumentare delle interazioni tra sistemi, dall'innalzamento degli
stack su cui poggiamo le nostre architetture, scaturisce un bisogno piu'
sentito di collaborazione tra persone con capacita' e conoscenze diverse
.
Rete distribuita:
Seppur politicamente e tecnicamente valide, l'accentramento su queste
alternative non costituisce una risposta valida alla necessita' di
distribuzione e autogestione che cerchiamo di diffondere con le nostre
pratiche. All'interno dei nostri server, cluster e reti abbiamo ben
chiaro il concetto di single point of failure, ma nella pratica non
spingiamo abbastanza scalare questo ragionamento a un livello di
astrazione piu' alto, evitando che una rete diventi il single point of
failure del cosidetto movimento
Mantenimento:
La fase iniziale di design e setup di un server e' stimolante e guidata
dal piacere della conoscenza e della (auto)costruzioe, spinte
fondamentali per i "tecnici" che con gli strumenti vogliono innazitutto
sperimentare e giocare. Quando un servizio entra in produzione,
l'approccio cambia radicalmente si pongono tutte le questioni relative
alla stabilita' e al mantenimento. Le attivita' di routine rappresentano
la maggior parte dell'impegno richiesto, poco interessanti e percepite
come un accollo poco piacevole [Per esempio, la gestione di un server di
posta e' uno dei compiti meno interessanti e piu' gravosi, dove il
lavoro richiesto e' quello di monitoraggio e gestione delle policy
antispam, proprie e altrui. Un'attivita' che di interessante ha ben
poco, ma che costituisce uno degli elementi di base per la costruzione
di molti altri servizi]. Gli aggiornamenti software (siano essi di
sicurezza o meno) possono richiere modifiche alle configurazioni, spesso
studiate attentamente in fase di costruzione ma poi abbandonate e
scordate in fretta. Per questi motivi capita spesso che sia richiesta di
volta in volta una nuova fase di studio (e quindi tempo) che
potenzialmente puo' portare a errori e quindi dissuadere
dall'aggiornamento.
Helpdesk:
Nel fornire servizi e mantenere server una parte importante dello
sforzo e del tempo e' dedicato all'assistenza agli utenti. Questo e' un
compito particolarmente poco interessante, ma fondamentale sia per
facilitare l'utilizzo dei servizi, sia per alzare il livello di
consapevolezza e spingere ad uso corretto degli strumenti.
Stato delle cose
Molti dei ragionamenti portati non sono nuovi e vari collettivi stanno
gia' (o hanno provato) a dare risposte a queste esigenze. Ci sono vari
tentativi di documentazione e tool condivisi all'interno della scena
hacktivista: il piano R* di Autistici [1], il progetto
puppet-shared-modules [3], Padrão Saravá di Sarava.org [2], leap.se [4],
opuppet [5] di indivia/ortiche.
Si tratta di progetti diversi, ma che mirano tutti alla condivisione di
documentazione e know-how.
Il piano R* (probabilmente non piu' aggiornato) punta a spiegare le
scelte strutturali effettuate per rendere piu' resiliente
l'infrastruttura di Autistici.
puppet-shared-modules si propone come una base di codice comune, in
forma di moduli puppet, creati/mantenuti/utilizzati dalle diverse
comunita' e dai diversi server (riseup, immerda, sarava, leap, ...).
Padrão Saravá e' il sistema di configurazione utilizzato all'interno di
sarava, una rete di server ispirata dal piano R* e (forse) basata sui
puppet-shared-modules.
leap.se mira alla realizzazione di piattaforme per telecomunicazioni
sicure, fornendo sia il lato client sia gli strumenti per installare un
server indipendente.
opuppet e' un tool, quasi piu' un ragionamento, su questi temi e un
tentativo di unire strumenti standard per il deploy e mantenimento di
server autogestiti a partire da puppet-shared-modules
Non esiste invece alcuna documentazione che affronti molti altri aspetti
della gestione dei server, in primis le questioni legali che
rappresentano non solo il punto piu' critico, ma pure quello piu'
delicato da documentare online. Anche sulle considerazioni alla base di
molte scelte tecniche non c'e' nulla, se non brandelli nelle mailing
list o poco piu'.
Evoluzione
L'idea e' di quella di creare un sito/repository/pagina/antani dove
raccogliere il materiale riguardante queste questioni, collaborare sugli
strumenti e trovare momenti in cui confrontarsi sulla tematica delle
infrastrutture in maniera particolare.
Per aiutare la costruzione di questi contenuti avrebbe senso partire da
domande precise, che punzecchino e aiutino le diverse comunita' a
documentare e a parlare di se stesee e delle problematiche ritenute
interessanti.
[1]
http://www.autistici.org/it/who/rplan/
[2]
https://padrao.sarava.org/
[3]
https://gitlab.com/groups/shared-puppet-modules-group
[4]
https://leap.se/
[5]
https://git.lattuga.net/opuppet/puppet-deploy (sorry:
markdown-viewer e gogs non vanno d'accordo :| )
- --
MeTA~LaBS >> building information subways
