Reposting from the TrueCommand 1.2 announcement thread:
We're having the same issue (enter default login, then scroll bar with no further actions) when trying to run latest TrueCommand container (1.2.2) on a Docker Swarm hosted on base Centos 7 VMs. The issue appears to be a Qt shared library requiring a later Kernel version than Centos 7 currently offers, according to
this and
this. So much for portability of a container.. I verified this by upgrading the kernel only on a Development Centos 7 VM in our Docker Swarm and the TrueCommand 1.2.2 container ran successfully after that upgrade. However, upgrading the Kernel version across our fleet to run TureCommand is not a real fix unfortunately. Devs, is this something you can address in a new release?
Pre kernel upgrade
Code:
# uname -a
Linux mn2-dev 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
# docker service logs
...
XXXXX | 2020-04-20 23:35:30,766 INFO exited: middleware (exit status 127; not expected)
XXXXX | 2020-04-20 23:35:30,766 INFO gave up: middleware entered FATAL state, too many start retries too quickly
docker exec -it -u 0 660e27db3497 /bin/bash
root@660e27db3497:~# cat /var/log/ix_middleware.log
/usr/bin/ix_middleware: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
/usr/bin/ix_middleware: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
/usr/bin/ix_middleware: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
/usr/bin/ix_middleware: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
root@660e27db3497:~# ls -lha /usr/lib/x86_64-linux-gnu/|grep libQt5Core
lrwxrwxrwx. 1 root root 20 Jan 30 13:42 libQt5Core.so.5 -> libQt5Core.so.5.11.3
lrwxrwxrwx. 1 root root 20 Jan 30 13:42 libQt5Core.so.5.11 -> libQt5Core.so.5.11.3
-rw-r--r--. 1 root root 5.0M Jan 30 13:42 libQt5Core.so.5.11.3
root@660e27db3497:~#
Post kernel upgrade
Code:
uname -a
Linux mn2-dev 4.4.219-1.el7.elrepo.x86_64 #1 SMP Sun Apr 12 16:13:06 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
docker service logs XXXXX
XXXXX | 2020-04-21 02:20:16,550 INFO success: middleware entered RUNNING state, process has stayed up for > than 2 seconds (startsecs)
Further, with the container running on the Docker Swarm (after the kernel upgrade hack), it is reporting `Connection Timeout` when connecting to a FreeNAS system. I've removed the system, re-added it, modified it, disabled strict SSL, verified the password in TrueCommand - however it's still reported as offline. I've got a shell in the TrucCommand container and ensured TCP connectivity works, so this appears to be application issue. Can anyone else confirm this? Btw, I'm also running TrueCommand locally on a Mac Laptop and setup the FreeNAS system exactly the same as the Swarm instance - and that works.
Code:
root@3b335d00c301:~# nc -zv host 443
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to host:443.
Ncat: 0 bytes sent, 0 bytes received in 0.20 seconds.