Feature requests for easier management of dedicated servers

[thasmo]

Hey there!

While developing a Dockerfile for running a DST server via Docker, we stumbled upon a few things which make great feature requests, because when solved, dedicated servers could potentionally be managed more easily for the particular topics I'll mention below.

Make path of mods-directory configurable to be able to share read-only core game-files.
In Docker there is a concept called *volumes* which let's you share specific directories between Docker containers. It's kind of comparable to sym-links, where you could link one directory into another. We wanted to share the core game-files of a single Docker container with several other containers to save disk space and also to have a central place for updating all servers when an update gets released. The only problem we faced so far is the mods-directory, which is located within the game directory, because basically it prevents us from sharing the core game-files between several containers/servers. (Obviously because every server could have different mods or different mod-versions, etc.)

So we think, if the path to where mods are saved/stored, could be configured, this problem would be gone and the core game-files could be shared across several dedicated servers more easily, not only when using Docker.

Hope that makes sense.

Move adminlist.txt, whitelist.txt and blocklist.txt out of the save directory.
Currently all the player-lists are stored within the `save` directory. although it would (maybe) make more sense to store them outside, in the same directory where the `settings.ini` etc. is stored. At the moment we encounter problems when creating those lists before the server gets booted initially, because the nullrenderer executable deletes those files on initial boot. This means we can't pre-configure those lists for new servers easily. In general it would be nice to have those files treated as *global* configuration files outside the `save` directory, which feels like a better location for those settings anyway. Those lists should outlive world resets or deletion of the `save` directory.

nullrenderer should handle signals.
I've already mentioned it here; the game-server executable (on Linux) does not respect signals which results in lost game data when the host gets shut down or rebooted. It would be nice if the game-server would react to the common shutdown/kill signals of Linux and properly shuts down the server by saving the current state (world data and sessions, etc.). At the moment it seems that the host forcefully shuts down the game-server after several seconds, because the nullrenderer simply ignores the signals.

I hope those things make sense for some of you and I really appreciate your feedback; from all of you, including Klei.

Also, please correct me on any of my words if they're wrong or don't make sense at all.

Thanks!

[nome]

1 hour ago, thasmo said:

The only problem we faced so far is the mods-directory, which is located within the game directory, because basically it prevents us from sharing the core game-files between several containers/servers. (Obviously because every server could have different mods or different mod-versions, etc.)

So we think, if the path to where mods are saved/stored, could be configured, this problem would be gone and the core game-files could be shared across several dedicated servers more easily, not only when using Docker.
 

Can't you make the DST game proper part of the docker image and overlay a mount on the mods mountpoint?

1 hour ago, thasmo said:

Move adminlist.txt, whitelist.txt and blocklist.txt out of the save directory

Expect some changes here soonish (caves related change, not specific to your request). Feel free to let us know your thoughts once these changes go live.

1 hour ago, thasmo said:

nullrenderer should handle signals.

Personally I wrote a go wrapper that launches the caves and overworld servers as subprocesses and translates a sigterm into a clean shutdown request to those servers on stdin (having launched them with -console). Maybe not ideal docker form though, having three processes in a single image....

[Maco02]

All the config files that you need to modify are inside the config dir except the mods. For the mods you need to modify 2 different files and one of them is inside the game folder. Can't be this be improved? Is it really necessary? Am I missing anything?

[Maco02]

This is clearly a pain for the users, not only for us writting the docker image. Improving this part this tool would not be necessary:

The tool is great, and very handy. But it's great because the server don't do that by default. Is dedicated_server_mods_setup.lua really necessary?

 

EDIT:

I must say that the tool in the link have sense even if we have only one file. It's really cool.

[PeterA]

4 hours ago, Maco02 said:

Is it really necessary? Am I missing anything?

Hey Maco, the reason for dedicated_server_mods_setup.lua for existing inside the shared install folder is because it would be modifying the install directory (the mods fold contents). The intention was that you'd run a dedicated server instance with the flag "-only_update_server_mods", and then that would download the latest versions of all the mods in that shared installation. Then when it exits, you'd run each of your server instances with different configuration folders and the flag "-skip_update_server_mods". This was mainly a result of multiple dedicated servers running on one machine sharing an install and mods directory.

That said, having dedicated_server_mods_setup.lua in the mods folder was definitely problematic for various users, so we're looking at moving it out to the config dir, and potentially making the mods directory configurable.

[thasmo]

21 hours ago, nome said:

Can't you make the DST game proper part of the docker image and overlay a mount on the mods mountpoint?

That's what we do. The DST dedicated server will be installed via steamcmd when building the image using our Dockerfile. So when running a container from that image, the dedicated server will be started as the main process of that container. So, long story short - PeterA mentioned that you're planning to move configuration files and make - quote - "the mods directory configurable". If that means we can configure the path where mods are stored, then it will solve the mentioned problem, I think.

21 hours ago, nome said:

Expect some changes here soonish (caves related change, not specific to your request). Feel free to let us know your thoughts once these changes go live.

That sounds interesting. I'll definitely have a look at it as soon as it's released.

21 hours ago, nome said:

Personally I wrote a go wrapper that launches the caves and overworld servers as subprocesses and translates a sigterm into a clean shutdown request to those servers on stdin (having launched them with -console). Maybe not ideal docker form though, having three processes in a single image....

We're still in the process of properly integrating the DST game-server in Docker containers/images, and we're writing a similar wrapper-script in bash, like you did in Go. As we're still tinkering around with this, finding the best way to do this, I believe we have to dig a bit deeper and will expand the discussion with you here, should new things arise. I general I still think it would be the best solution if the nullrenderer handled signals properly, but we'll try a bit harder to find a good solution and will show you in detail what we've found out, soonish I hope.

Thanks so far for your input!