Recently I have been putting some thought into OpenWRT as a base OS for devices that are not necessarily network related. For instance, OpenWRT could run things like Pi hole or it could run a display. I remember seeing a community post taking about how OpenWRT is going to start packaging display packages and I thought I would share my ideas.
I personal think that OpenWRT is poorly suited for a server OS as the system is built to be pretty small and not bloated. Running LXC or docker containers is not useful in my opinion. Also packaging big display software like Chromium is probably not feasible. I think it would be fine to package some basic software like a video player but chances are there will always be something that someone is missing.
Here is what I suggest instead. Under Linux is completely possible to do nested containers. I think it would be cool to use something like bubblewrap to create a chroot like environment where something like a Debian install can live and run. You could setup a base image on removable storage and then have a service that just starts systemd in a bubblewrap container. If more functionality is needed the container could be granted NET_ADMIN which would allow it to manage things like VPN connections. For digital signage you could passthough the GPU and input devices so that that software in the container would be able to run something like a desktop.
The advantage of this is that the guest system would be separated from the base OpenWRT system. This would be good from both a security and manageability perspective.You could run Docker in the guest system and then setup extra software like VPN clients. I think this is a much better design than trying to run individual containers on the host. OpenWRT is build to be lean and if you start bloating it you might as well use something more trandional. One serious downside is that many of the common router CPU architectures are not supported by the more mainstream Linux distros. There are translation layers and emulators but they perform poorly.
I'm not a OpenWRT packager or developer so my ideas hold little wait. However, I though it might be worth sharing.
I'm no expert with it but I think starting with adding 'network namespaces' is just a super obvious next step with an obviously valuable practical use.
After that you could add 'container space' or whatever, basically the same except it has it's own processes/binaries etc ie you can ssh into it, run programs etc as well as having network features to configure.
I'm not interested in arguing about it though, I can set up multiple openwrt containers myself with Arch Linux or Armbian (with systemd-nspawn) as the host on a few devices. I do want to try to get that setup working on a Dynalink DL-WRX36 where it just boots Arch Linux off USB and then I run at least 2 Openwrt containers. Anyway, yeah I think it would make sense and be good for the project to have network namespaces but you know that's always the feeling with the internet where if you say you like something or want something, some very rational and logical person appears and it's pff ok then. I think we should fix a driver that's never getitng fixed because it's deliberately not getting fixed instead, then nothing happens either way.
If you want a stronger security boundary than containers on the host, gVisor may be worth looking into.
gVisor implements the Linux API : by intercepting all sandboxed application system calls to the kernel, it protects the host from the application. In addition, gVisor also sandboxes itself from the host using Linux's isolation capabilities. Through these layers of defense, gVisor achieves true defense-in-depth while still providing VM-like performance and container-like resource efficiency .
Containers are not a sandbox , and while we can improve their security, they will fundamentally share a common attack surface with the host. Virtual machines are a solution to that problem, but you might prefer container semantics and ecosystem. gVisor can be perceived as an attempt to get the âbest of both worldsâ: containers that are easy to manage while providing a native isolation boundary.
Linux containers are described to run a particular application or service in the mainstream or the world of bigger machines such as hyperscalers. But for âembedded systemsâ (small machines but bigger than a consumer router) which OpenWrt serves, containers in my opinion can be use to create an operating environment which is indepedent from the host OpenWrt.
In my understanding, OP essentially was promoting such an idea. Six months before OPâs post, I implemented LXC on my BPI-R4 to do something very similar. One container called âpublicâ and the other container called âintranetâ like two servers (in my case) to run services for public facing Internet and LAN facing intranet.
I can see many benefits of such an approach. For one, on every OpenWrt upgrade, you donât have to to re-create the system from scratch and to make sure itâs same as before. Iâm aware of various tools to try on automating this but thatâs not the point of interest here. Users can also choose to run different âdistributionsâ that suits their purpose though AlpineLinux seems a natural choice to pair up with OpenWrt in this way.
Whether the community is interested for a standardised and polished setup of such containers is perhaps is the question. Maybe thatâs what OP is asking. Otherwise, itâs quick and easy to do by individuals on their own ways.
We run displays with a custom Linux distro and Electron/Chromium based app on devices with as little as 64mb ram. Its not fun, we are replacung the hardware. But its out in the wild.
E.g. build some small go applications in a multiarch container, fire up rontainerd/runc and see what happens. (My part in dogfooding)
Usually compute is easy. At least compared to state keeping. You need some place to store data without wearing out the flash. Be that USB storage ore additional NVMe storage on larger devices. Cut it into volumes and throw some containers at it.
Once all that works you can look into fun stuff of building a custom openwrt distribution that mixes in full kubernetes, openflow etc so your code runs on the fabric of the network itself.multi-VRF-Kubernetes
In retrospect, LXC was first released in 2008. By the time around 2015, itâs been 7 years. I wonder why OpenWrt has not gone the âLXC wayâ but did it from scratch with ujail, sort of LXC-lite-lite if I understand it correctly.
The âLXC wayâ
A LXC container with rootfs of the host OpenWrtâs own rootfs plus an overlayfs of RAM on top. The container only runs the jailed service. Seems very quick to profit with least incompatibility issue and little extra work required from the serviceâs package. Perhaps will be more widely adopted by packages for enhanced security.