ciao gente!
(There is a copy in english of this email below)
Volevo condividere questo articolo dal blog di freifunk
che ho scritto in occasione del google summer of code di quest'anno.
https://blog.freifunk.net/2023/07/08/gsoc23-automation-tools-for-libremesh-firmware-build-and-monitoring-part-2/
Volevo approfittare per raccontare due cose su cosa sto facendo, e anche
su come stiamo messi nella nostra piccola wireless community network
quaggiù in italia, nell'appennino a sud di Bologna
nella speranza di ricevere feedback e per lasciare una traccia di come
siamo organizzati che possa essere di ispirazione.
## Come stiamo usando libremesh
Intanto scusate la lungaggine, cerco di dare un po' il quadro per
arrivare meglio al punto dopo
noi siamo questi qua che vedete in foto, (da questa altezza risulta meno
problematico condividere la posizione perché approssimativa)
[0]
https://pic.infini.fr/VKhJx4q1/5rElxbGT.png
Al momento abbiamo soprattutto questi dispositivi per i ponti wireless 5ghz:
- ubnt-lbe-m5 (openwrt-19.07.10 libremesh-2020.1)
- ubnt-nanostation-m-xw (openwrt-19.07.10 libremesh-2020.1)
- ubnt-nanostation-loco-m-xw (openwrt-19.07.10 libremesh-2020.1)
- Powerbeam m5 (openwrt-19.07.10 libremesh-2020.1)
- tp-link-cpe510-v3 (openwrt-22.03.5-libremesh-master)
### Configurazioni di libremesh
Al momento, sulla falsariga degli ultimi cambiamenti di
librerouteros-v1.5 stiamo facendo queste scelte, condensate perlopiù nel
network profile della nostra community:
link_al_network_profile
- usiamo anche noi il setup di default di libremesh ovvero babel/batman-adv
- pirania, non lo stiamo usando, stiamo andando avanti soprattutto per
passaparola e ci aiutiamo con ethercalc/cryptpad
- prometheus/victoria-metrics
stiamo usando prometheus e non victoria-metrics per tenerla più semplice.
come wcn ci piacerebbe fare delle prove, imho credo in effetti avere
le metriche che vengono pushate sul server sembra molto più comodo.
Abbiamo iniziato impostando Prometheus e per ora stiamo continuando
così, e in ogni caso se decidessimo di cambiare sistema vorremmo
mantenere un setup pronto per entrambe le strade.
- tmate: non lo stiamo usando ma ci stiamo arrangiando per fare delle
vpn con wireguard per avere accesso da remoto ad alcuni nodi.
## Come siamo organizzati
Le cose che cerchiamo di mantenere come accordi di community, a parte il
Picopeering Agreement
https://picopeer.net/ sono:
1- Garantire la possibilità al maggior numero di livelli/modalità di
partecipazione, ovvero sapere che ci sono diversi livelli di
consapevolezza del progetto e anche di competenze tecniche.
2- Promuovere l'indipendenza delle persone partecipanti dal singolo
gruppo tecnico di riferimento, e lo sviluppo di diversi livelli di
autonomia.
Questo si traduce per me anche nella scrittura di 'sti ruoli ansible che
cerchiamo di mantenere con una logica del "mi fanno in automatico certe
cose" ma vorremmo non aggiungessero alcun livello di astrazione tale che
un singolo non possa ripeterselo per conto suo senza.
3- Per noi sarebbe molto utile una guida del tipo come posso configurare
openwrt per aggiungersi ad una mesh di dispositivi libremesh.
Gli altri punti riferibili, a ci siamo evoluti nella gestione delle
molteplici build, e del setup del sistema di monitoring li avevo già
sommariamente espressi come casi d'uso e li trovate a questo riferimento
[1]
https://gitlab.com/a-gave/libremesh-ansible-playbooks/-/blob/master/docs/use-cases.md
## Strumenti digitali
Questa una mini lista di scelte che abbiamo fatto, sul cercare di
aiutarci con alcuni strumenti digitali:
- il BuildRoot di Openwrt. La community di cui faccio parte ha iniziato
a usare libremesh v16 a marzo 2017 e dalla versione successiva la v17 è
stato necessario imparare a compilare per evitare i reset e i km di
automobile per rimediare, ed avere delle immagini con le radio impostate
a 10'000m invece che 1000m, il nuovo default.
- uMap, hostato in locale (avere una mappa comune, non pubblica, e
online per sincronizzarla più facilmente è stata una delle primissime
necessità) di recente per rapide prove esiste anche una versione
ufficiale dockerizzata.
- Etherpad, Ethercalc, Cryptpad per conti e magazzino
- Prometheus (node-exporter, blackbox-exporter, alertmanager) + Grafana,
per monitorare peggioramenti nella qualità dei link, o down di
dispositivi (alcune antenne hanno dei montaggi un po' precari)
## Da docker-compose + nginx, a ansible + git
Per coordinarci abbiamo inizialmente installato a mano i componenti che
ci servivano, usando soprattutto docker-compose e avendo poi un setup
semplice con nginx più una certification authority locale.
Ma risultava difficile metterci le mani in più persone, dunque abbiamo
iniziato a usare ansible con git per tenere traccia delle modifiche,
avere una più chiara disposizione delle confgurazioni. E per evitare di
doverci segnare della documentazione per ciascun cambiamento, ma usare
invece git per versionare un sistema in cui inserire sia la
documentazione, sia le operazioni necessarie a riprodurre lo stesso sistema.
Su questo volevo condividere anche questa presentazione fatta
all'HackOrDie 2022 a Bologna, Italy, con considerazioni simili:
https://git.lattuga.net/antennine/hod2022_10m-talk/src/master/slides/index.md
Grazie al google summer of code di quest'anno ho avuto l'occasione di
scrivere i ruoli e i playbook corrispondenti a questo setup che vi ho
illustrato finora.
Spero possa di esere di ispirazione per qualche altra persona.
Sarebbe interessante per me continuare questi discorsi
in particolare su come varie community stanno usando vpn interne, e
sull'opprtunità di scambiarsi dei files yaml di direttive per le build
di openwrt.
Un saluto!
[english]
Hi all!
I'd like to share this post from the blog of freifunk
that I've written for the google summer of code of this year.
https://blog.freifunk.net/2023/07/08/gsoc23-automation-tools-for-libremesh-firmware-build-and-monitoring-part-2/
I'd like to tell two things on what I'm doing, and also on how we are
organized in out community network in Italy, in the countryside/montain
in the south of bologna.
With the hope of receiving feedback and to leave a trace of how we are
organized that can be an inspiration.
## How are we using libremesh
First, sorry for the long email. I try to give the frame to better
understand the point.
We are these that you can see in this pics:
[0]
https://pic.infini.fr/VKhJx4q1/5rElxbGT.png
At the moment we are using mainly these devices to make the 5ghz
wireless links:
- ubnt-lbe-m5 (openwrt-19.07.10 libremesh-2020.1)
- ubnt-nanostation-m-xw (openwrt-19.07.10 libremesh-2020.1)
- ubnt-nanostation-loco-m-xw (openwrt-19.07.10 libremesh-2020.1)
- Powerbeam m5 (openwrt-19.07.10 libremesh-2020.1)
- tp-link-cpe510-v3 (openwrt-22.03.5-libremesh-master)
### Configurations of libremesh
At the moment, along the lines of changements in librerouteros-v1.5 we
are doing these choices, condensed in the network profile of the
community valsamoggia.ninux.org at
https://github.com/libremesh/network-profiles/tree/master/valsamoggia.ninux.org
- we also use the default setup with babeld/batman-adv
- pirania, we are not using it, we are going on mostly by word-of-mouth
and we are helping us with ethercalc/cryptpad.
- prometheus/victoria-metrics.
we are using prometheus and not victoria-metrics to keep it simpler.
as a wcn we would like to do some testing, imho I think actually
having the metrics being pushed to the server seems much more convenient.
We started by setting up Prometheus and are continuing that for now,
and in any case if we decide to change systems we would like to keep a
setup ready for both ways.
- tmate: we are not using it but we are arranging to make vpn's with
wireguard to have remote access to some nodes.
## How we are organized
The things we try to maintain as community agreements, apart from the
Picopeering Agreement
https://picopeer.net/ are:
1- Ensuring that the greatest number of levels/modes of participation
are possible, i.e., knowing that there are different levels of project
awareness and also technical skills.
2- Promoting the independence of participating people from the
individual technical reference group, and the development of different
levels of autonomy.
This also translates for me into writing 'these ansible roles that we
try to keep with a logic of "they automatically do certain things to me"
but we would like them not to add any level of abstraction such that an
individual cannot repeat it on their own without it.
3- A guide like how can I configure openwrt to add itself to a mesh of
libremesh devices would be very useful for us.
The other referable points, to we have evolved in the management of the
multiple builds, and the setup of the monitoring system I had already
summarized as use cases and you can find them at this reference:
[1]
https://gitlab.com/a-gave/libremesh-ansible-playbooks/-/blob/master/docs/use-cases.md
## Digital tools
This a mini list of choices we made, about trying to help us with some
digital tools:
- Openwrt's BuildRoot. The community I am a part of started using
libremesh v16 in March 2017 and by the next version v17 it was necessary
to learn how to compile to avoid resets and car miles to fix it, and
have images with radios set to 10'000m instead of 1000m, the new default.
- uMap, hosted locally (having a common, non-public map and online to
synchronize it more easily was one of the very first needs) recently for
quick tests there is also an official dockerized version.
- Etherpad, Ethercalc, Cryptpad for accounts and storage.
- Prometheus (node-exporter, blackbox-exporter, alertmanager) + Grafana,
to monitor deteriorations in link quality, or down of devices (some
antennas have somewhat precarious mounts)
## From docker-compose + nginx, to ansible + git
To coordinate we initially installed the components we needed by hand,
mostly using docker-compose and then having a simple setup with nginx
plus a local certification authority.
But it was difficult to get our hands on it in multiple people, so we
started using ansible with git to keep track of changes, have a clearer
arrangement of confgurations. And to avoid having to mark up
documentation for each change, but instead use git to version a system
in which to put both the documentation and the operations needed to
reproduce the same system.
About this, I'd like to link also this presentation (in italian) I made
at the HackOrDie 2022, in Bologna, Italy with similar considerations:
https://git.lattuga.net/antennine/hod2022_10m-talk/src/master/slides/index.md
Thanks to this year's google summer of code, I had the opportunity to
write the roles and playbooks corresponding to this setup illustrated so
far.
I hope it could be an inspiration for others people.
It would be interesting to me to continue these speechs, in particular
on how various communities are using internal vpns, and on the
opportunity of exchange yaml files to control the builds of openwrt.
A greeting!
--
gothos
PGP Key ID: 0x6406B32F2CEC0008
PGP Key server:
https://keys.openpgp.org/
