Docker Image rootfs under Docker Desktop 2.2 on top of WSL 2.0
PavelSosin-320 opened this issue · comments
OpenWRT container is running but not available. - see attached log
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2591ec860c65 openwrtorg/rootfs "/sbin/init" 32 minutes ago Up 32 minutes 22/tcp, 80/tcp, 443/tcp relaxed_cartwright
ping 127.17.02
Pinging 127.17.0.2 with 32 bytes of data:
Reply from 127.17.0.2: bytes=32 time<1ms TTL=128
But
PS C:\WINDOWS\system32> docker inspect 2591ec860c65 > OpnwrtInspect.txt
PS C:\WINDOWS\system32> ssh 127.17.02
ssh: connect to host 127.17.02 port 22: Connection refused
USB and WiFi path trough is supported by WSL 2.0, so
Expected:
It's possible to ssh into OpenWRT container
I have exactly the same issue when I'm trying to ssh into my Router from my Windows, both cmd and WSL 2.0 console.
USB OpenWRT networking can be tested using OpenWRT container
It can be useful both for local testing and regular cloud-based development pipeline
Works on my Linux system, I'm guessing it is not Docker related if you have the same issue for a real device.
I think Docker IPs are usually start with 172 and not 127, can you check that? Also be sure to prepend the correct username running on the OpenWrt instance, mostly root
@aparcar I suppose that you are right partially. This is not only Docker issue. There are many contributors:
- Norton blocks outbound TCP port 22 by default but ssh.exe but using Norton settings I was able to let ssh go using any protocol
- Windows doesn't enable TCP port 22 communication inside Docker Host computer or private network when OpenSSH client/server feature is enabled ???
- But now your container sais me PS C:\WINDOWS\system32> ssh 172.17.0.2
ssh: connect to host 172.17.0.2 port 22: Connection timed out although the container is running.
Could you look at the attached docker inspect output and verify ports bindings?
Are you sure that the container start also starts all services?
OpenWRTDockerInspect.json.txt
P.S. Container restarts without any "ready" log message and runs without making ssh available
_CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2591ec860c65 openwrtorg/rootfs "/sbin/init" 23 hours ago Up About a minute 22/tcp, 80/tcp, 443/tcp relaxed_cartwright_
and it is a bug! How to know if it is ready?
I suppose that it is a critical OprnWRT containers issue! Every Unix image docker containers have the service started automatically and available. Otherwise, such a container is not manageable and i.e. not usable. Unfortunately, I didn't find that all OpenWRT distros have an SSH server package. Docker desktop supports today multiple architectures DockerMultiArch support . OpenWRT has to follow the trend and incorporate SSHD support into all runtime distros and all containers.
After proper firewall configuration, I succeeded to reach every standard Linux container as expected
and can't blame Windows or Docker desktop - this is the OpenWRT packaging issue. SSH is also the pre-requisite for IT Automation of Unix nodes (devices) using Ansible.
I'm trying to process what you wrote, I might misunderstand some bits.
But now your container sais me PS C:\WINDOWS\system32> ssh 172.17.0.2
ssh: connect to host 172.17.0.2 port 22: Connection timed out although the container is running.
Could you look at the attached docker inspect output and verify ports bindings?
Are you sure that the container start also starts all services?
OpenWRTDockerInspect.json.txt
Yes I'm sure the container is supposed to start all services, if it does so in your case, I don't know. Please post the output of ps, it ideally looks similar to this.
root@91b33fb3aeb4:/# ps
PID USER VSZ STAT COMMAND
1 root 1132 S /sbin/procd
74 root 868 S /sbin/ubusd
75 root 1080 S /bin/ash --login
91 root 772 S /sbin/urngd
257 root 956 S /sbin/logd -S 64
321 dnsmasq 1124 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
365 root 888 S /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
434 root 1204 S /sbin/netifd
471 root 1056 S /usr/sbin/odhcpd
575 root 1068 S udhcpc -p /var/run/udhcpc-eth0.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth0 -x hostname:91b33fb3aeb4 -C -R -O 1
739 root 1068 R ps
Container restarts without any "ready" log message and runs without making ssh available
What ready message are you looking for? When starting the container there should be the following lines of log, when the last one is printed the containers SSH should be read.
[a@tb ~]$ docker run --rm -it openwrtorg/rootfs:latest
Failed to resize receive buffer: Operation not permitted
/etc/preinit: line 6: 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.
Unfortunately, I didn't find that all OpenWRT distros have an SSH server package.
To save some storage OpenWrt uses dropbear instead of OpenSSH. The running SSH service therefore is usr/sbin/dropbear instead of anything including ssh.
Docker desktop supports today multiple architectures DockerMultiArch support . OpenWRT has to follow the trend and incorporate SSHD support into all runtime distros and all containers.
I frankly don't understand how Dockers multi arch support is related to Secure SHell. However, yes, we're offering SSH (aka dropbear) for nearly 40 architectures.
I walked inside openWrt rootfs container and found 2 issues:
- There is no conventional shell but only ash which can't be used too because of dev/console presence. The message "/bin/ash: can't access tty; job control turned off" is the indicator.
There is no generated ssh key. Indeed it can't be stored inside the container because it should be unique for every instance. The recommendation is to share the folder containing the keys with the Host machine (single-node Kubernetes) or Kubernetes node using volume sharing. Unfortunately, it can be not easy for Docker desktop.
There is no conventional shell but only ash which can't be used too because of dev/console presence. The message "/bin/ash: can't access tty; job control turned off" is the indicator.
Yes that's a problem but I don't really know how this is fixed, I remember creating this file solved some issue, however don't fully remember. Overall the container still works and it actually runs ash. Not sure what needs to be fixed here.
There is no generated ssh key. Indeed it can't be stored inside the container because it should be unique for every instance. The recommendation is to share the folder containing the keys with the Host machine (single-node Kubernetes) or Kubernetes node using volume sharing. Unfortunately, it can be not easy for Docker desktop.
How is this issue related to OpenWrt?
After upgrading all my staff I tried again to run OpenWRT container and got error message ash: can't load library 'libcrypt.so.0'. It definitely points to the known issue [](ash: can't load library
sshd startup issue. In other words, there is an attempt to start sshd, maybe redundantly, The initialization process is stopped and I see OpenWRT container as exited.
Also PS C:\WINDOWS\system32> docker run openwrt-x86-generic-rootfs ps gives Mr the same error.
ps: can't load library 'libcrypt.so.0'
It looks like the initialization process is incomplete and the container exits before something be executed inside the container. Are you sure that 64bit libcript.so0 is used for 64 bit image? Unfortunately, I can't check which library exists in the /lib folder because ls /lib/* also fails.
OMG ! Recently Docker Desktop released the new feature "Rootless" containers starting from Docker engine 19.03 for WSL 2.0 and it is exactly my version! It applies some restrictions, causes "Insufficient privileges" error and prevents containers to start.
I'm closing the issue until the Docker issue will be solved