On 5/17/21 11:09 PM, Fernando Frediani wrote:
Hello
Certainly run /sbin/init or 'procd' to have *OpenWrt-like experience*
is a better approach in my view.
So do you prefer to disable some services and make some init-scripts
"container aware"?
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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
