Feature request: ability to stop/start wifi-connect from outside container

[maggie44]

This is a very clever way to massively reduce the footprint of the old Wifi-Connect package, and much appreciated.

A slight downside, the old Wifi-Connect was fairly limited in its functions. This meant manually writing scripts to clear existing wifi networks (balena-os/wifi-connect#353); setting the SSID on the launch of wifi-connect or allowing a user to rename the SSID through our apps (https://github.com/balena-io/wifi-connect/blob/master/docs/command-line-arguments.md); implementing stop start procedures into apps for performing many of these functions or just enabling or disabling the functionality in general (balena-os/wifi-connect#256); and on occasion work arounds that require executing before or after (balena-os/wifi-connect#327).

These were not a major issue in the versions contained in Balena images, but now with this extra lean image, things have got a lot more tricky. Running things inside the container with wifi-connect is now limited, and controlling the wifi-connect app though our own apps in other containers is further complicated.

Initially, the solution appeared to be supporting Alpine images for wifi-connect, which would provide a lean container and yet the ability to build custom processes around it, but it seemed to prove problematic to implement and never got off the ground (balena-os/wifi-connect#185).

Ideally of course, Alpine support and/or a wifi-connect that has a built in API would serve these roles, although that appears to be creating issues as it has been almost a year balena-os/wifi-connect#185.

Instead, I'm wondering if a simple API can be built into the image, that merely starts (with the ability to pass in the various strings such as --portal-ssid x), stops and reports the running status of wifi-connect. This would allow the container to run like an executable, that our outside apps can control, maintaining the ability to integrate it in more complex ways, while keeping this image small. It would also simultaneously reduce the need for the Alpine base requests.

I note that it is using busybox, so perhaps a simple httpd server with endpoints to stop and start the process inside, which will keep this lean? The API could then be enabled or disabled via an env variable.

We could stop and start the container through the Balena supervisor, but this seems too heavy for such a simple process, with too many moving parts, and would not allow strings such as --portal-ssid to be passed.

Would be good to hear any thoughts, issues, and about potential viability. .