Hi everyone,
thank you for all your feedbak and interest in OpenWISP!
Background info
I want to give you a little bit of background info. The new generation of OpenWISP was born while I had been contributing to Ninux and hanging out with Freifunk for quite many years.
Initially I was implementing this work in a project called Nodeshot (GitHub - ninuxorg/nodeshot: Django based tools to create crowdsourcing web apps.), which was mostly a tool for the community to plan new network nodes and visualize the network map.
Since OpenWISP had traction, more contributors and I was already working full time on it, I decided to focus entirely on OpenWISP from 2016 onwards.
I was only developer working on Nodeshot and since I left the project it hasn’t been maintained by anyone.
OpenWISP Demo recorded at Battlemesh v14
I also want to take this change to let you all know that I presented the latest version for OpenWISP at an event called “Battlemesh” in Rome last week, anyone interested can find the recording here: https://www.youtube.com/watch?v=1BqrX0-ICBQ&t=4947s.
It would be great if you could watch this recording to find out if you want to drill down on any specific subject.
Replies to your queries and feedback
Now Let me reply to some of your doubts.
My “feeling” on the downside is that it’s always seemed like a walled garden – e.g. using NetJSON to ship […] network configuration.
NetJSON is an idea and a format that emerged from community networks.
There’s an RFC (NetJSON: data interchange format for networks) and this work was funded by the CONFINE project in which many community networks have actively participated, for more info see:
[I want to push for more of OpenWISP to use mainline OpenWrt, as its] base system now has a huge amount of common functionality that would enable high performance while also supporting the hardware we use:
OpenWISP supports mainline OpenWrt, there’s no custom firmware needed, only two packages:
- openwisp-config
- openwisp-monitoring
Both available in the OpenWrt feeds:
Wireguard / unetd rather than OpenVPN (which will seriously suffer on the AR7161 CPUs we have): New WireGuard based OpenWrt VPN implementation: unetd - For Developers - OpenWrt Forum
OpenWISP 22.05 supports Wireguard, VXLAN and VXLAN over Wireguard.
https://openwisp.io/docs/user/wireguard.html
It is possible to use the configuration advanced mode to configure also any other tunneling technology supported by OpenWrt.
The ones that are officially supported right now offer automated provisioning, that means that all the necessary keys and configuration details are automatically generated by the system.
We want to add more VPN and tunneling automations, like Softether and Zerotier, for ZeroTier we were meant to work on it during the Google Summer of Code this year, but the contributor working on it was hired by a big tech company. Without proper funding it’s very hard to retain talent.
Reimplementing the NetJSON configuration parsers (e.g. netjsonconfig/netjsonconfig/backends/openwrt/converters at master · openwisp/netjsonconfig · GitHub) on the client-side using ucode (which has native uci and ubus bindings): GitHub - jow-/ucode: JavaScript-like language with optional templating
Keeping the config logic on the server has many advantages:
- possibility to write backends for other firmwares, for example, we have two experimental backends for AirOS and Raspbian which demonstrate this capability, but futher work is needed for production usage. We decided to fully focus on OpenWrt for now.
https://github.com/openwisp/netjsonconfig/pull/91 airos
https://github.com/openwisp/netjsonconfig/pull/92 raspbian
- less requirements of resources on the device
- possibility to write a unix program that can work on any unix based system (Any Linux based distro, PfSense, Vyatta, Ubiquiti’s stuff, etc.)
- we can add support for standard protocols like TR-069 and NetCONF which are widely used in the networking industry
Therefore I would rather invest in the direction of an agnostic implementation rather than increasing the coupling with OpenWrt.
We can still reuse some of those tools if needed, but first we have to talk about and define user needs, then we can talk about implementation details.
Using the well-community-supported prometheus data backend in place of the Influxdb one (though not sure if the architecture supports it, InfluxDB is push rather than pull): openwisp-monitoring/openwisp_monitoring/db/backends at master · openwisp/openwisp-monitoring · GitHub
At the moment we support only InfluxDB 1.8. We have to work out support for InfluxDB 2.0 and we have the integration for ElasticSearch almost complete.
A few years ago we had to discard Prometheus as a second option in favour of Elasticsearch because the latter is more widely used.
OpenWISP can do both push and pull, please read here: GitHub - openwisp/openwisp-monitoring at 1.0
Pull has some advantages over push. When the device sends the metrics, if anything goes wrong it can retain those metrics in memory and send them later on, while failed push operations have no way of knowing the state of the device which the system was trying to reach.
OpenWISP has a similar resiliency mechanism on the server API side too, if it fails to write to the timseries DB, it will wait and retry.
This allows the monitoring system to be very resilient to temporary failures, which are very common in VERY busy networks.
We achieved this by using a mix of push and pull. So far we are very happy with the result.
Basically, I’m noting that this project makes a lot of its own choices; some are very much in common with [what we use in OpenWrt], some are not. It’d be nice, though not necessary, to help reconcile those differences in choices.
IMHO, conforming is not always good.
Sometimes developers have to choose what they think it’s best for the problem they’re solving with the available information and resources (time and money) they have.
We’ve been open to improvements and over the last 4 years we’ve amended some bad choices (like extreme modularization which was holding us back) and fixed MANY bugs, this trend won’t stop, so if more people join with feedback and contributions to accelerate this project we can only all benefit from it.
On our side we have to focus what to work on and the decision is to focus on the features our users need to manage their networks.
Automatic bulk communication with subscribers is on my Christmas Wish List.
If you’re talking about the possibility of sending emails to the users,
I had implemented this feature in Nodeshot (I mentioned this in the beginning of the post) for Ninux, something like that could be very well extracted in a separate module and integrated in OpenWISP.
The code is here: nodeshot/nodeshot/community/mailing at master · ninuxorg/nodeshot · GitHub .
There’s also very popular django third party apps for mass mailing which could be integrated too (OpenWISP is based on Django).
I agree! It’s stupid to have to keep reinventing the wheel. But also we can contribute what we’ve learned and deployed.
I dedicated the main topic of my OpenWrt 2017 summit presentation about OpenWISP exactly to this topic:
Hi all, I am very interested but couldn’t find the details for this talk! Did it happen already, and if so is it recorded? Thanks!!
No it didn’t happen yet.
I have to prepare this based on the feedback of this post, we’ll keep you updated!
I hope these replies help.
Thanks again for your feedback!
Federic
