Hi everyone! I’m samlo. I’m a fullstack webdev that live in a rural area in Italy and dedicates part of his time to build an maintain a self-managed community network based on LibreMesh https://antennine.noblogs.org/.
For GSoC’23, I’ll be working on setup a set of ansible playbooks and roles to do common network administration tasks useful for a tech team of a community network based on LibreMesh.
This first blog post intends to cover details on the necessary background to understand the project and its implementation.
As state the site https://libremesh.org/, LibreMesh is a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes.
It’s a list of packages (lime-packages) with support for various mesh protocols, to installing and configuring them properly, and offer to the end user a dedicated web interface (lime-app).
It has support for potentially every OpenWrt supported devices, following the documentation you find all the information to build the firmware and configure the main files and start using it.
It also has a list of network configurations used by different communities (network-profiles) that provide the information about how to configure your firmware (installing packages) and your network (e.g. editing main configuration files), or both, to join the community mesh.
Libremesh is a set of packages you can include as feeds – via sources or precompiled packages – in a OpenWrt build system and then select those of your choice, but it’s possible to overwrite openwrt default configs only manually, and make backup of produced configurations files per build.
In this scenario is necessary to save configurations and ways to reproduce the same firmware image.
Instead of start writing a list of bash scripts to handle just our community needs I’m interested in exploring the possibility of using a configuration management and automation tool as Ansible https://docs.ansible.com.
This would lead to simplify common needs, in particular:
– automate the build of firmwares for groups of devices with specific configurations, packages, libremesh and openwrt versions.
– build test firmwares by versioning experiments
– build on localhost or on a remote machine
– manage configurations (monitoring, vpn, ssl certificates) in the same system that also build firmwares
– automate the insertion of information that may be synced between networking devices and servers
– share configurations in a set meaningful and reproducible for other people inside and outside the local community network.
Libremesh doesn’t handle a system to build consistently for every supported devices or to patch openwrt to meet the needs of particular targets or devices.
So every community should understand how to build for devices they are using.
One inspiration for this came from the project Gluon https://gluon.readthedocs.io/ that include a system to keep traces of specific packages related to openwrt targets, subtargets and device.
Deliverables of the project
– Have an ansible set of playbooks and roles to build openwrt firmwares
– Have an ansible set of playbooks and roles to build libremesh firmwares
– Have an ansible role to build libremesh firmwares depending on libremesh version, openwrt version, libremesh default packages, libremesh target’s or device’s specific packages, libremesh community packages, libremesh community set of packages linked to specific list of devices.
– Have an ansible set of playbooks and roles to setup a monitoring/probing/alerting/metric-visualizer system
In this period of design and blueprint of the project, before starting coding I thinked a lot at use cases, who could want to use it, and to simplify contributions to keep updated the code in the future.
I look forward to publish on https://galaxy.ansible.com/ two collection of roles (openwrt and libremesh) and make available via git repository the set of playbooks to use the roles above.
I’ll update you in July.