Is there an install guide that is NOT a KISS thing???

[tmittelstaedt]

I want to try out openwisp but I am in an enterprise that doesn't allow automated scripted installs that have no logging or any way to duplicate the actual commands. For the first install of anything we need to do it "manually" that is, login to an Ubuntu server, and run the apt-get install commands, and add in whatever local accounts are needed. A bash script that lists out everything is also acceptable since every line can be examined before executing the script. The reason is to prevent bad actors burying back doors or apps from doing "call home to motherships behind our back" and so on. pre-canned docker images and vm images are not acceptable either. The preferred method is to obtain source and compile apps but installing from the major distro repositories is OK also. Of course once we do it and know what's going on we can write automated install scripts but using someone else's is a nono.

Is there an install guide for openwisp that is NOT the "download ansible and click a button and cross your fingers" but is actually written out for a real sysadmin?

Thanks!

[nemesifier]

Sure, the deployment process is documented with YAML code in the ansible-openwisp2 role, which many people including myself use to deploy and update openwisp.

Duplicating that in prose documentation would be overkill and nobody is going to maintain such redundant bloat for free.

You should start reading it from the tasks/main.yaml, which lists the commands that are executed on the server one by one.
Another important section to read is the role variables.

There's some prose documentation as well available at https://openwisp.io/docs/dev/ansible/index.html, which is built from the docs/ folder in the git repository.

If you're not fond of ansible, any modern LLM tool like chatgpt can help you understand the syntax and if you really desire, convert it to a bash script.

I hope this helps.

[tmittelstaedt]

"Duplicating that in prose documentation would be overkill and nobody is going to maintain such redundant bloat for free."

Uh, I would, if I got into this - as "prose" documentation is tremendously valuable to understanding how the package works. (this exchange of ours is "prose" so don't knock it)

I did take a look at the YAML code, thank you! Here's some of the things that I learned by doing that, which are NOT in the KISS documentation here:

1. It uses freeradius which means something is going to upload something to the AP that makes the AP authenticate into it via RADIUS
2. It wants a Debian flavor, preferably Debian 13
3. It's got a LOT of dependencies which is probably why you are all advising to keep it on a separate VM
4. A lot of those dependencies are execv() stuff not library calls - meaning it's really NOT portable to any other distro unless you want to go on a treasure hunt for where other distros might move executables

None of this is in the dealbreaker category - but it definitely puts it in the "golden can" category. While virtualization/golden can is all good, it's also much higher resources than just sticking the app on a server along with many other apps - which means that now I have to justify the resource expenditure on spinning up a VM for it. And, since it's NOT going to work with APs that aren't a) running the latest openwrt b) have lots and lots of free ram and space for additional apps that get loaded onto the AP, that means I can't just "fire it up" for a test drive - I'm going to have to spend a lot of time with this on a lab network with a couple test APs to make sure it does not blow my network of ~50 approaching ~75 APs over the mountain.

APs - at least the ones in MY network - tend to just keep chugging along for months and years without causing trouble, there's APs in my network I've not logged into for over a year to do updates to or, really, any basic troubleshooting - because they haven't caused trouble. At the same time, the network of APs is growing and I'm getting a bit concerned that I can't really just turn my back on it and assume every AP on it is just going to keep chugging along doing it's job. So now you get into a situation where it's a balancing act between time sunk into dealing with the management platform thrashing around and having fits if something goes wrong with it - vs time saved by being able to, say, push out a firmware update to a pile of APs with a click of a button. If openwisp was much simpler and more basic - it would have been valuable before now. But it's not - so I may just wait until we get the wifi network expanded out by another 25-50 APs and do that old-school before getting into the pain of figuring this very complex management tool out.

[okraits]

You are making a lot of false assumptions. Some comments on the things you wrote:

1. OpenWISP only uses RADIUS if you enable the corresponding module.
2. In general, OpenWISP will work on all distros which provide the needed dependencies. For the core of OpenWISP you don't need much more than a python environment, Postgres, Redis and a reverse proxy.
3. You can deploy OpenWISP in containers as well.
4. The OpenWISP clients don't require a recent version of OpenWrt or a lot of RAM and space.

We have OpenWISP server instances managing several thousands of routers each. It works very well.

[nemesifier]

You made some random baseless statements that it's not worth for me to reply to. I do not need to convince you to use OpenWISP. There's other systems out there, you're welcome to use them.