Automated Installation of Dedicated DCS Server w/ SRS on Linux

[Actium]

TL;DR: Currently experimental git repo of configs and scripts intended to automatically install and manage multiple DCS and SRS server instances on a single headless Linux server using systemd.

I've been using the code to run a dedicated DCS server along with an SRS server for a couple of months. It's been smooth sailing from DCS 2.9.9 all the way thru 2.9.14, so I'm releasing this into the public to get some feedback. Please do not hesitate to ask any questions in this thread and also feel encouraged to create issues or pull requests on Github.

Features

• Fully automatic installation and upgrades of DCS and SRS
• Plug & Play: DCS and SRS are usable immediately after installation
  • Pre-configured with reasonable defaults
  • Auto-starts a default mission (Caucasus with dynamic spawns)
  • Ships with useful helper scripts
• Minimal overhead: ~200M RAM on Debian 12.9 (kernel + user-space)
  • Built for headless (non-GUI) Linux servers: Does not require a desktop environment (e.g., Gnome, KDE, XFCE, ...)
  • DCS and SRS windows accessible via VNC (serves minimal GUI)
  • Runs Caucasus, Marianas, and Syria on servers with 16G RAM (other terrains unverified)
• Convenient management of all server processes through systemd user services (systemctl --user start|stop|status dcs-server|srs-server) and automatic restart of failed services (to the extent DCS enables it ...)
• Supports multiple DCS server instances (DCS_server.exe -w DCS.*) through systemd unit instances

Installation Instructions

Check the README.md.

Screenshot

Edited March 20 by Actium

[astiles]

Hi, nice work. Have you considered adding retribution?

[Actium]

Thank you! No, not yet. I'm still in the process of stabilizing the foundation. There's still a few issues I'd like to have ironed out before adding on features (e.g., automatic DCS updates, adding/configuring more server instances, installing/removing terrains, extended README.md). The ecosystem of DCS mods, bots, various tools (e.g., Olympus) and mission frameworks (e.g., Retribution, Liberation) is also so comprehensive that it's beyond the scope of this project to support them all. I will have to prioritize everything that enjoys widespread and universal use, e.g., Tacview.

In terms of a roadmap, server performance is my next big objective. I'm in the process of experimenting with a recent improvement in both the Linux kernel and Wine (called ntsync) that will hopefully bring a significant performance improvement.

[Actium]

NOTE: This does not apply to you if you first installed after the 20th of March 2025.

The login failure bug has been fixed by 2.9.14.8222 (absent from the changelog). The previous workaround (adding 185.195.197.4 api.digitalcombatsimulator.com to etc/hosts) is now a liability that will break the login if the master server ever changes its IP address. I've modified install_dcs.sh to remove the workaround. Either re-run the updated install_dcs.sh or execute the following code from a terminal to undo the workaround:

WINE_ETC_HOSTS=${WINEPREFIX:-$HOME/.wine}/drive_c/windows/system32/drivers/etc/hosts
if grep -q "^185.195.197.4 api.digitalcombatsimulator.com" $WINE_ETC_HOSTS ; then
        sed -i "/^185\.195\.197\.4 api\.digitalcombatsimulator\.com/d" $WINE_ETC_HOSTS
fi

Edited March 20 by Actium

[Noisy]

Nice work. I can see a lot of skill and effort has gone into this.

FWIW the value I see in automating the install is that it reduces the effort to deploy to the cloud (e.g. AWS EC2) such that it doesn't matter when you burn the instance (including disks) when you're done. To that end if you could get it fully turn key that would be pretty nice. It also means that if this is the primary use case, then supporting updates and the like becomes moot and you can focus your effort on improving the basic service. 

 

Re automating the entry of the server account credentials, xdotool might be the go e.g.:

xdotool search --sync --name "DCS Login" windowactivate

xdotool type "$username"

xdotool key Tab

xdotool type "$password"

xdotool key Return

 

I've just finished a powershell implementation for the automated install of DCS Server intended for the user data parameter of AWS EC2 instances https://github.com/jimvella/ready-room-selfhosted. Your Linux approach would shave off some cost though by avoiding the windows license, assuming that you don't need a more performant instance to offset the performance overhead of linux and wine - I'm looking forwards to what you find out re performance.

[Actium]

@Noisy Thanks.

On 4/16/2025 at 7:28 AM, Noisy said:

Re automating the entry of the server account credentials, xdotool might be the go

Love the xdotool idea. I'm fully committed to Wayland though. Particularly, because Wine 10 has enabled Wayland be default. It should certainly be possible to implement that with the Wayland tools and subsequently get rid of XWayland. Could be possible via ext-foreign-toplevel-list-v1 to immediately punch in the credentials once the Login window pops up. Unfortunately, the extension lacks the ability to explicitly bring windows to the front. I'll look into that down the road.

On 4/16/2025 at 7:28 AM, Noisy said:

I've just finished a powershell implementation for the automated install of DCS Server intended for the user data parameter of AWS EC2 instances https://github.com/jimvella/ready-room-selfhosted.

Thanks for sharing. I've had a look. I'm surprised by what PowerShell is capable of (i.e., press buttons chosen by name). Alternatively, you could install directly via DCS_updater.exe invocation as I do it in install_dcs.sh.

On 4/16/2025 at 7:28 AM, Noisy said:

Your Linux approach would shave off some cost though by avoiding the windows license, assuming that you don't need a more performant instance to offset the performance overhead of linux and wine - I'm looking forwards to what you find out re performance.

In terms of performance I have already packaged ntsync for straightforward deployment on Debian. The Wine ntsync patch is still being worked on upstream and has not yet been merged. Dunno if I'll wait for it to be merged before toying around with it. However, I just ran a bunch of dedicated server benchmarks on different platforms. It appears to suffer severely when running the server on a Windows 10 VM with QEMU+KVM as the hypervisor (frame time degrades by 3 orders of magnitude).

Using my Benchmark.lua and Benchmark_150_v2024.11.23.miz, I found that Wine 10.0 performs almost on par with running natively in Windows 10 on my Ryzen 9 5900X, whereas the Windows VM has a performance excursion that renders it entirely unusable (server simulation frame times in the order of a minute). See the plotted results for 10 rounds of 5 minutes each (or more).

Windows goes nuts in terms of system CPU time consumption. WIth Wine it's also significantly elevated compared to Windows, but I'd expect that to improve with ntsync.

System	System CPU Time (s)	User CPU Time (s)
Windows 10 (native)	63.9375	1135.78125
Wine 10.0 (no VM)	460.45	1654.63
Windows 10 (Linux QEMU+KVM)	2674.03125	1995.234375

I haven't made any benchmarks of Wine running in a VM. That'll probably have a noticeable impact, too, but currently I have no clue where it'll end up relative to the Windows VM performance. As of right now, I'd recommend to use Wine (possibly in containers, but not VMs) instead of Windows VMs, as far as performance is concerned. Of course, running the dedicated server on a physical Windows box still has a performance edge over Wine, particularly when missions get more demanding (see older results with the Benchmark_200.miz).

I've attached the raw benchmark log files for anyone to have a closer look.

Benchmark-2.9.15.9408-W10-20250419-085425Z.log.gz Benchmark-2.9.15.9408-W10_KVM+hugepage+isol-20250419-200019Z.log.gz Benchmark-2.9.15.9408-Wine10-20250420-123953Z.log.gz