I’m looking for direction on creating a container whose purpose is to configure the OS on the host. For example, if I’d like to create a web UI to let a user set the device as STATIC IP or DHCP. I know I can use nmcli from the terminal. I could install nodejs in the host and launch an app there. But, it seems the more correct approach is to create a container for this logic. How then would I allow that container to connect back to the main TorizonCore host to run those commands, and share output between the two. Has this already been solved?
Greetings @kdubious,
First of all this is a somewhat unusual use for a container since it breaks the container-host isolation by allowing the container to affect/change the host. However as long as you’re aware of this and the possible issues don’t affect your project than this is definitely doable.
So I have a couple idea of how you might achieve this. First of all any container can be run with the --network=host flag. This will start the container with the same network stack as the host system. So in theory if you run a container like this and then install network tools in the container any change in the container’s network would change the host since they share the network stack in this case.
Another approach would be a little more hacky but I’ve done something similar before. We’d start with the same process of running a container with --network=host. So one interesting use case with a container running --network=host is that you can easily SSH from the container to the host system via localhost. So you could then execute commands on the host from the container over such an SSH connection.
These are just a couple of ideas so feel free deviate/search for other solutions that may fit your use-case better.
Best Regards,
Jeremias
Thanks for the suggestions. I suppose the first question I need to answer is if the benefits of doing this in a container are eliminated by the complexity of doing this.
An alternative would be to include NODEJS in the host, and configure my app to run there? If I do that, does it break the OTA update process of Torizon?
I guess to better answer that we’d have to look at what exactly benefits we are getting. While yes trying to interface with the host system through a container does have it’s share of complexities. The alternative if we want to run this on the host would instead require a rebuild of the host system to have the utilities and tools needed for your UI and application stack. So I guess we trade complication in one area here for another. Ultimately I’d say it depends which complication you’d rather have.
As for the 2nd part of your question, no I wouldn’t think adding something like NodeJS to the host would break OTA updates. As long as OSTree (the update client on the device) and Aktualizr (the service that communicates to the OTA server) are both functional then OTA updates should be okay. The only thing you’d have to keep in mind is now you have a slightly layered Torizon host system. Meaning in terms of updates you’ll probably have to manage merge conflicts if you’d want to continue updating your flavor of Torizon with our continued updates of vanilla Torizon.
Best Regards,
Jeremias