[RFC] OpenWrt within a Docker container

[Fernando Frediani]

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 at 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 at 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 at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel