[RFC] OpenWrt within a Docker container
mail at aparcar.org
Tue May 18 09:54:19 PDT 2021
On 5/17/21 11:09 PM, Fernando Frediani wrote:
> 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
> On 17/05/2021 15:39, Paul Spooren wrote:
>> 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.
>> 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.
>> 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 , ,  or  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 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
>> 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.
>> 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.
>> : https://gitlab.com/openwrt/docker/-/merge_requests/47
>> : https://github.com/docker-library/official-images/pull/7975
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
More information about the openwrt-devel