I've always wondered why this project needs to be so complex... I need to administer 10-20aps... why is it necessary to run 9 services to achieve this? A mail server? An OpenVPN server? Docker is still not advised for prod use.

WISP stands for Wireless ISP, so the target is not SoHo. It can be used with 10-20 aps, but I agree that in that case can be overkill.

This software has been used to run public wireless services in many Italian towns, in collaboration with local government institutions.

Docker not recommended for prod? I believe that the industry is going in a different direction :)

The docs seem to suggest that docker is fully supported. I wonder if that note on the github repo about prod use of the docker image is out of date.

https://openwisp.io/docs/stable/docker/index.html

Many people might use a different 10-20% of it and it's quite valid.

Anything similar for opnsense (besides their own service) or pfsense?

With some effort it should be possible to integrate PfSense/Opnsense in OpenWISP. I hope in the future we'll be able to do it.

Maybe just go with ansible or similar: https://github.com/ansibleguy/collection_opnsense

Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.

Maybe I am missing somehing, but I would assume that base network infrastructure like routers, firewalls and switches have a higher uptime, availability and reliability than ordinary servers.

The problem with push is that the service sitting at the center needs to figure out which devices will need to be re-pushed later on. You can end up with a lot of state that needs action just to get things back to normal.

So if you can convince devices to pull at boot time and then regularly thereafter, you know that the three states they can be in are down, good, or soon to be good. Now you only need to take action when things are down.

Never analyze distribution of software and config based on the perfect state; minimize the amount of work you need to do for the exceptions.

Unattended upgrades fail and sit there requiring manual intervention (due to lack of transactional updates and/or multiple flash slots (root partitions and bootloader configuration)).

Pull style configuration requires the device to hold credentials in order to authorize access to download the new policy set.

It's possible to add an /etc/init.d that runs sysupgrade on boot, install Python and Ansible, configure and confirm remote logging, and then run `ansible-pull`.

ansible-openwrt eliminates the need to have Python on a device: https://github.com/gekmihesg/ansible-openwrt

But then log collection; unless all of the nodes have correctly configured log forwarding at each stage of firmware upgrade, pull-style configuration management will lose logs that push-style configuration management can easily centrally log.

Pull based updates would work on OpenWRT devices if they had enough storage, transactional updates and/or multiple flash slots, and scheduled maintenance windows.

OpenWRT wiki > Sysupgrade: https://openwrt.org/docs/techref/sysupgrade

Ansible does pull? https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...

Or build the router image declaratively with Nix.

https://nixos.wiki/wiki/OpenWRT

neat, will play with it.