Closed zeathe closed 1 week ago
I made a copy of the ./docker/Dockerfile
-> ./docker/Dockerfile.EnvOnly
with the following diff:
d7 1
a7 1
LABEL maintainer="Zeathe"
d19 2
a20 2
#COPY ./src/s6-services/s6-init-migrate-dcs-oneshot /etc/s6-overlay/s6-rc.d/init-migrate-dcs-oneshot
#RUN touch etc/s6-overlay/s6-rc.d/user/contents.d/init-migrate-dcs-oneshot
d22 2
a23 2
#COPY ./src/s6-services/s6-init-winepreqs-oneshot /etc/s6-overlay/s6-rc.d/init-winepreqs-oneshot
#RUN touch etc/s6-overlay/s6-rc.d/user/contents.d/init-winepreqs-oneshot
d25 2
a26 2
#COPY ./src/s6-services/s6-init-getlatest-dcs-installer-oneshot /etc/s6-overlay/s6-rc.d/init-getlatest-dcs-installer-oneshot
#RUN touch etc/s6-overlay/s6-rc.d/user/contents.d/init-getlatest-dcs-installer-oneshot
d28 2
a29 2
#COPY ./src/s6-services/s6-init-desktop-setup-oneshot /etc/s6-overlay/s6-rc.d/init-desktop-setup-oneshot
#RUN touch etc/s6-overlay/s6-rc.d/user/contents.d/init-desktop-setup-oneshot
d31 2
a32 2
#COPY ./src/wine-dedicated-dcs-automated-installer /app/dcs_server/wine-dedicated-dcs-automated-installer
#RUN chmod +x -R /app/dcs_server/wine-dedicated-dcs-automated-installer
d34 2
a35 2
#COPY ./src/s6-services/s6-init-dcs-auto-installer-updater-oneshot /etc/s6-overlay/s6-rc.d/init-dcs-auto-installer-updater-oneshot
#RUN touch etc/s6-overlay/s6-rc.d/user/contents.d/init-dcs-auto-installer-updater-oneshot
d37 2
a38 2
#COPY ./src/s6-services/s6-init-dcs-server-autostart-longrun /etc/s6-overlay/s6-rc.d/init-dcs-server-autostart-longrun
#RUN touch etc/s6-overlay/s6-rc.d/user/contents.d/init-dcs-server-autostart-longrun
after starting the container, I was able to exec into the container interactively, run xterm and install and then run DCS_updater.exe.
Suggested work-around: Building a server container with a custom Dockerfile removing all s6 scripts to auto-install, and interactively using xterm, the server can be installed with wine DCS_World_Server_modular.exe
You can at least already bypass this issue by toggling auto install off. If I have time I will look into resolving the new inno format issue and continue with the current extraction method.
Removing the s6 scripts is not happening and is plainly a bad solution. If you want to do that please maintain your own separate fork.
Suggested fix: If wine can be used to call the exe directly with CLI flags to auto-extract and auto-install without user intervention, the innoextract/innounp call could be bypassed.
This was how it originally was set to install and it proved horrible, brittle and a pain in the ass to maintain. So I'm not going to re-implement or maintain that. That said I am happy for people to fork / PR it.
Edit: for clarity, I am no longer particularly invested in DCS so the pace of my fixing anything is unlikely to be rapid.
You can at least already bypass this issue by toggling auto install off. If I have time I will look into resolving the new inno format issue and continue with the current extraction method.
Removing the s6 scripts is not happening and is plainly a bad solution. If you want to do that please maintain your own separate fork.
I'll look into this a bit more... it dorked up pretty good trying to run the container with those toggled. I'll dig a bit more on that.
This was how it originally was set to install and it proved horrible, brittle and a pain in the ass to maintain. So I'm not going to re-implment or maintain that. That said I am happy for people to fork / PR it.
I figure using a tool like that would be more stable. :-)
I did some digging around.... another issue with inno-setup fails as described in this bug post and a list of alternatives is here. JRathlev has an update to their Win GUI. I might open up a bug against innoextract directly.
At that point, it'll be waiting until Alpine pulls in the update and it trickles through the upstream images.
Edit: for clarity, I am no longer particularly invested in DCS so the pace of my fixing anything is unlikely to be rapid.
Understood. I'll see if I can shake anything loose and possibly throw a PR your way. It'll depend on how much spare time I have away from work myself. Great work on putting this whole thing together in the first place.
Certainly appreciate your invested time.
... and thanks for the really quick response to the bug!
FYI - the original xdotool sequences are kicking about here:
https://github.com/Aterfax/DCS-World-Dedicated-Server-Docker/tree/main/docker/src/xdotool-sequences
Looks like https://github.com/Aterfax/DCS-World-Dedicated-Server-Docker/pull/84 fixes the issue when I have done local testing.
Please go ahead and give it a whirl. Let me know if you want me to build, tag and add to DockerHub.
Looks like #84 fixes the issue when I have done local testing.
Please go ahead and give it a whirl. Let me know if you want me to build, tag and add to DockerHub.
.... stand by. Building locally now and testing.
Looks like it downloaded and extracted.
Some sort of race condition maybe on my side. I'm running the docker container on a VM with somewhat modest hardware that may be taking somewhat longer than the scripts expect. Got the following error message within the X interface from KasmVNC:
00000.692 --- Log file: C:\Program Files\Eagle Dynamics\DCS World Server\autoupdate_log.txt
00000.000 === Log opened UTC 2024-10-19 01:37:30
00000.142 INFO : DCS_Updater/2.17.2.8 (Windows NT 10.0.19043; Win64; en-US)
00000.142 INFO : src-id: 1bc8e7517304bc62fa4e911299a74b67759f8a4a, lib-id: b88ea51ae2210987a3865f77cc1802548216d7a8
00000.146 INFO : cmdline: "C:\users\abc\Temp\DCS.dcs_server\DCS_updater.exe" --quiet apply 7ae07add-ecdd-40b6-a7e6-75ed1af6f399 276
00000.450 STATUS: Initializing...
00000.686 INFO : basedir:
00000.687 INFO : variant: dcs_server
00000.690 INFO : Command: selfupdate C:\Program Files\Eagle Dynamics\DCS World Server\bin\DCS_updater.exe
00000.690 INFO : basedir: C:\Program Files\Eagle Dynamics\DCS World Server\
00000.691 INFO : variant: dcs_server
00000.695 INFO : DCS/ (x86_64; EN; WORLD,WWII-ARMOUR,SUPERCARRIER)
00000.695 INFO : branch: dcs_server.release
00000.695 INFO : Copying C:\users\abc\Temp\DCS.dcs_server\DCS_updater.exe to C:\Program Files\Eagle Dynamics\DCS World Server\bin\DCS_updater.exe
00000.696 ERROR: Can't copy C:\users\abc\Temp\DCS.dcs_server\DCS_updater.exe to C:\Program Files\Eagle Dynamics\DCS World Server\bin\DCS_updater.exe: (32) Sharing violation.
00000.696 INFO : Sleeping for 0.100000 seconds...
00000.799 ERROR: Can't copy C:\users\abc\Temp\DCS.dcs_server\DCS_updater.exe to C:\Program Files\Eagle Dynamics\DCS World Server\bin\DCS_updater.exe: (32) Sharing violation.
00000.799 STATUS: Got CANCEL when asked to retry: Can't copy C:\users\abc\Temp\DCS.dcs_server\DCS_updater.exe to C:\Program Files\Eagle Dynamics\DCS World Server\bin\DCS_updater.exe: (32) Sharing violation.
00000.800 STATUS: Can't copy C:\users\abc\Temp\DCS.dcs_server\DCS_updater.exe to C:\Program Files\Eagle Dynamics\DCS World Server\bin\DCS_updater.exe: (32) Sharing violation.
00000.838 === Log closed.
I think the file might be corrupted on extract... or self-mutilated:
abc@85d43c5c4ae7:/config/.wine/drive_c/Program Files/Eagle Dynamics/DCS World Server/bin$ wine DCS_updater.exe
0154:err:kerberos:kerberos_LsaApInitializePackage no Kerberos support, expect problems
0154:err:winediag:ntlm_check_version ntlm_auth was not found. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
0154:err:ntlm:ntlm_LsaApInitializePackage no NTLM support, expect problems
0158:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 00007FFFFF52FF50
0154:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
0154:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
0154:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.12
0154:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.12
0154:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 00007FFFFE1FFE80
abc@85d43c5c4ae7:/config/.wine/drive_c/Program Files/Eagle Dynamics/DCS World Server/bin$
I ran the container a second time on another separate fresh directory target for /config
and it looks like it did the same thing for me. BUT -- it did download, extract, and run the DCS_updater.exe... and performed a self-update. Post self-update, DCS_updater.exe is throwing this error. I think this is more of a DCS problem itself than a problem with your code. It probably is showing up on my system because my underlying disk speeds are not optimum.
(32) Sharing violation. 00000.696 INFO : Sleeping for 0.100000 seconds...
Sounds like a file locking issue or order of operations issue originating within the updater executable self update logic. Possible it is only evident when the file system is being sufficiently slow/fast. There has been similar things happening from what I remember, where poor performance host machines have caused issues. It working fine on a second attempt suggests this even more so if there's aspects of caching now speeding things up.
As far as I remember, everywhere possible within the scripting for this project I have avoided introducing any shabby sleep/waits and enforced strict operations ordering with checks. But that is certainly not to say there may not still be some kicking about where the ability to check something isn't possible or what is valid is undocumented / not clear which can cause "fun".
That aside, I don't remember any of the scripting I've written being a probable cause here. After innoextract does it's thing, it then falls entirely to the Eagle Dynamics binaries to do their thing via WINE.
0154:err
The vast majority of WINE warnings and errors look scary but are rarely relevant. Horrible signal to noise ratio imho. Various kerberos / NTLM / windows auth bits have proved to be spurious historically at least for the DCS server running in this setup.
It is possible more WINE gubbins can be turned on/installed to resolve the reported issues, but as they have clearly been non-fatal historically I have never bothered trying to unpick things as it will almost certainly be an enormous time sink.
Agreed on all accounts. I think we can call my innoextract issue fixed for sure. Thanks!
innoextract with custom updated build in Dockerfile results in working ED execution.
Problem: Line 54 of dcs-dedicated-server-automatic-installer.sh leverages innoextract binary which does not support the new inno format of the DCS Modular server exe.
The script does not perform proper error trapping.
The binary installer extraction fails and blocks all other processing of the docker container.
innoextract reports:
Repro:
58de7b0b2aa4
):sudo docker pull aterfax/dcs-world-dedicated-server:latest
sudo docker run -e VNCPASSWORD=123456 -e PUID=1000 -e GUID=1000 -e TZ=Etc/UTC -e DCSAUTOINSTALL=1 -e FORCEREINSTALL=1 -e DCSMODULES=CAUCASUS_terrain -e AUTOSTART=1 -e TIMEOUT=60 -e ENABLE_DCS_RETRIBUTION=0 -p 3000:3000/tcp -p 3001:3001/tcp -p 10308:10308/udp -p 10308:10308/tcp -v /tmp/test:/config/ --name dcsserver-001 --restart always aterfax/dcs-world-dedicated-server:latest
Suggested work-around: Building a server container with a custom Dockerfile removing all s6 scripts to auto-install, and interactively using xterm, the server can be installed with
wine DCS_World_Server_modular.exe
Suggested fix: If wine can be used to call the exe directly with CLI flags to auto-extract and auto-install without user intervention, the innoextract/innounp call could be bypassed.