jammsen
commented
8 months ago Hey @masonen thanks for the pull-request and for the time you took to try to improve this repo!
Summary
This PR introduces the possiblity to controll the gameserver status (start & stop the server) via a webhook
Do you mean ability? Possibilty sounds like, it works maybe 3 out of 30 calls 🤣
Motivation
Currently the dedicated servers still face a bug where pals are loosing sanity or starve when no player is connected and they get stuck. A current workaround is to stop the server while no one is active. While this bug is of course not in scope of this project i still consider the changes valuable to the project.
They get stuck when you are online and not in render range or even in render range too, so no changes here.
What a current workaround is to stop the server? Why not turn of bEnableNonLoginPenalty? While this bug is of course not in scope of this project i still consider the changes valuable to the project. I dont get this, you say its a bug with the game, but still want me to fix it? Is that right?
Since my servers are used by a small defined group of people which dont have direct CLI access to my host machines (and should not get it) an incomming webhook is a good solution to allow them to controll the serverstatus.
So is a solution like Portainer, that way they can stop, start, resume. pause?
Its not in the scope of this project how the webhook is accessed by the "outside world".
Wait WHAT? You want me to add something that totally breaks the current server workflow AND ALSO everyone using it and dont want to offer a solution because its out of scope? What?! 😱
The hoster can decide on how to make this webhooks availiable to the users/admins of the servers. In my case im currently building a discord bot to access the webhooks securely inside my network without publicly exposing the webhooks, other usecases might include direct web access, web integrations and many more (up to the server maintainer.
This is in now way really helpful, nor new-user friendly is it? However is an adaptation, to your current problem i guess?
Just stoping the server via RCON is ofcourse working but this will also terminate (and restart) the container if its set to "unless-stopped". If restart policy is set to "on-error" the container will keep stopped, but without access to the host one can not start it.
Again isnt Portainer a solution? A non-admin friendly way, to just stop it and start it again if needed?
Other scenarios i was considering was a docker in docker setup where i will have the webhooks handle in a container thet spawn the server container. Was working fine but it might overwhelm people to set up on their own.
Docker in Docker with dedicated servers might be possible, but afaik it always comes with a heavy cost to responsetimes in ms. Would not recommend to do this.
Changes included
- rework of servermanager to handle the spawn of the webhook if envvar is set. Extract all other functionalities regarding server handling or termination handling to own script
- introduction of remotestart and remote stop script which is used by the webhook
- introduction of new webhook outputs related to the remote controll webhooks
- introduce a build layer to the dockerfile that builds the webhook binary from source (https://github.com/adnanh/webhook)
- small fixesin default.env (spaces only allowed inside quotes), fixes in envvars of docker file
Thanks for explaining the changes, but we have a very big PR that restructures the main repo, pretty sure, this would not be compatible.
I will look into the review of the files, however is still dont understand whats the reasoning for adding this would be? Because what i read is, you dont want to change something on your end? So i should do it on my end? Why? Whats in for all of the users to use this? Why start the server via api and some scripts? Why isnt supervisord here a better or lesser solution?
Update after Review: I did look at the code you would like to introduce but i still dont get the point and your use-case, need a better explaination of the idea, context, solution you came up with and why not another way is better. As much as i can see, this breaks a lot of compability, for introducing a very nested edge case with limited usability.
Could you please explain more around this? I would also offer a call around this, if you want @masonen maybe that way its easier to explain.
masonen
Summary
This PR introduces the possiblity to controll the gameserver status (start & stop the server) via a webhook
Motivation
Currently the dedicated servers still face a bug where pals are loosing sanity or starve when no player is connected and they get stuck. A current workaround is to stop the server while no one is active. While this bug is of course not in scope of this project i still consider the changes valuable to the project.
Since my servers are used by a small defined group of people which dont have direct CLI access to my host machines (and should not get it) an incomming webhook is a good solution to allow them to controll the serverstatus. Its not in the scope of this project how the webhook is accessed by the "outside world". The hoster can decide on how to make this webhooks availiable to the users/admins of the servers. In my case im currently building a discord bot to access the webhooks securely inside my network without publicly exposing the webhooks, other usecases might include direct web access, web integrations and many more (up to the server maintainer.
Just stoping the server via RCON is ofcourse working but this will also terminate (and restart) the container if its set to "unless-stopped". If restart policy is set to "on-error" the container will keep stopped, but without access to the host one can not start it.
Other scenarios i was considering was a docker in docker setup where i will have the webhooks handle in a container thet spawn the server container. Was working fine but it might overwhelm people to set up on their own.
Changes included