Hello
Certainly run /sbin/init or 'procd' to have *OpenWrt-like experience* is
a better approach in my view.
Regards
Fernando
On 17/05/2021 15:39, Paul Spooren wrote:
Hello,
after some back and forth I'd like to request some more opinions on
what kind of Docker containers to offer containing the OpenWrt rootfs.
This is not about the SDK or ImageBuilder Docker containers.
tl;dr:
Should we ship `slim` containers only, running a OpenWrt shell (ash)
and nothing more? Whoever wants services to run (e.g. ubus) should run
additional containers and glue them together via mounts? Or should we
run /sbin/init or `procd` to have a *OpenWrt-like experience*, with
LuCI, ubusd and friends.
/tl;dr
Currently the `openwrt/rootfs` container is shipped with minimal
modifications and starts `/sbin/init` as default action.
Running the container for e.g. LuCI development within a local shell
results in the following output:
```
user@reactor:~$ docker run -it openwrt/rootfs
Failed to resize receive buffer: Operation not permitted
/etc/preinit: line 5: can't create
/sys/devices/system/cpu/microcode/reload: Read-only file system
ip: RTNETLINK answers: Operation not permitted
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug
level
ip: can't send flush request: Operation not permitted
ip: SIOCSIFFLAGS: Operation not permitted
Please press Enter to activate this console.
--- %< ---
root@da3dfbdc5ae4:/#
```
Some init scripts fail due to missing privileges. The console input is
only possible by using a patched /etc/inittab file and multiple
services keep failing, most problematic the `network` service since it
tries and fails in a fast loop to flush some interfaces.
A possible patch is available[1] which disables services obsolete
within a Docker environment, however this would "flaw" the
*OpenWrt-like experience*.
Another, probably better approach could be to have *slim-containers*
which only run `ash` and let the user start whatever is needed, e.g.
`ubusd && uhttpd` and thereby have access to a LuCI interface to play
with.
This would follow the experience from other popular containers like
`alpine` or `debian`. This would also allow us to become an "official"
container, which would allow to be used as `docker run -it openwrt`
rather than `docker run -it openwrt/rootfs`. Some efforts were made
here[2].
I'd prefer the latter option; only offer SDK and ImageBuilder and let
the rootfs become a "official" Docker container without any running
services. Whoever needs services can use `FROM openwrt` within a
Dockerfile and run whatever is needed.
Best,
Paul
[1]: https://gitlab.com/openwrt/docker/-/merge_requests/47
[2]: https://github.com/docker-library/official-images/pull/7975
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel