I think the answer is yes but wanted to check for any better methods or potential pitfalls.
I am deploying a fleet of devices for a local community project, they are all identical devices but will have different purposes. Some will act as dumb APs, some will act as PTP bridges, some will act as routers/firewalls.
So each device will have its own custom configuration (hostname, IP), then a common configuration applied to all devices (passwords, scripts, cron jobs etc), then one or more task specific configurations (AP settings, bridge settings etc).
To manage the deployment and maintenance of these, my thought is to create some backup files that only contain the files specific to that config. So the unique config would only contain /etc/config/network and /etc/config/system, the common config would only contain /etc/passwd /etc/shadow etc. AP config would only contain /etc/wireless
Will this work as expected? If a backup file contains only a subset of the /etc files will only those ones be applied so I can stack the backups by applying them in sequence?
Is there a better (simpler) way of doing this? I realise the limitation of this is that files have to be replaced in their entirety so you can’t ‘alter’ any network settings for example.
I looked into OpenWISP but it seems really heavyweight for this need. Quite hard to setup (tried several times with Docker and always got 500 errors on deployment) for some reason it demands an FQDN and won’t work on a local network. Are there others like it?
Configuration backups are simply tar archives which replace whole files in /etc/config (and sometimes other places in the filesystem). The configuration is not merged. All settings previously in the same file will be lost.
As noted you can write a script of uci commands which will merge into the existing configuration. OpenWISP in the raw JSON mode also works this way to merge any setting into any file, although it is a bit tricky writing raw JSON.
And you chant this after using a month old ansible template?
Since you are good with stacking tarballs go for it. Just that there are less time consuming options.
Sorry if I offended you, there just seems to be no 'valid' route forward, I can deploy the MASTER version of OpenWISP from git but it would seem unwise to use this in a production environment? Or is that just the way of it with OpenWISP?
As much as OpenWRT is concerned it uses imagebuilder to emit Openwrt device images with ready field configurations.
one can do same manually up to dozen devices, for more there are no alternatives.
The development version of OpenWISP is widely deployed. The main problem is that there's not many maintainers and the core team is busy with real world deployments, the rest is done on a best effort basis, which sometimes takes long to translate in a new release.
Instead of complaining and expecting everything to be given to them fully done, some people nowadays should learn to do their research and contribute more.
I have removed the offending comment. Now I have the development version of OpenWISP installed I am getting much better traction, it is a very powerful tool
Maybe one day we'll manage to make OpenWISP easier to set up so this kind of result that @supersebbo achieved can be achieved a lot more quickly and with less frustration.
Count on the fact that I'll share more info on this and look for collaborators when the time is ripe.
You have to roll your own base OpenWRT image for best results, ensure the correct VPN package and the OpenWISP controller package are installed. Beyond that, use uci-defaults to put the devices into a state where they are secure and can contact the OpenWISP server. This way you can easily deploy new devices and if anyone presses the factory reset button on the device in the future, it will reconfigure itself automatically.
The VPN Server on the OpenWISP side does not configure itself, even though it feels like it should based on the way the UI works. This caught me out for a while! You have to manually configure the VPN Server and then match the settings exactly to the ones in the OpenWISP UI as this then generates the client configs. In particular watch out for settings that are left blank in the OpenWISP config as these imply defaults which might not match the actual server config.
Ultimately you will get better traction hosting your VPN server outside of the OpenWISP server itself, so long as the remote tunnel IP of the device is routable from OpenWISP, it will all work as expected.
If you're putting OpenWISP controller sever behind a reverse proxy sever for security, don't forget to ensure the WebSockets (/ws/notification/ and /ws/controller/) are forwarded properly. There may be others I haven't encountered yet too, if something isn't working, check the browser debug log.
The way the templates generate OpenWRT configs might differ to the exact syntax you are used to using on OpenWRT, this takes a bit of getting used to but if you trust in the templates, it mostly works as expected.
it's all in there, somewhere.