[RFC] OpenWrt within a Docker container

[Paul Spooren]

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