Complete rework

[jusito]

Heyho, I looked into improving linuxgsm docker side a bit and added some of my ideas.
Currently my work is not completed but there are already quite some changes which might be discussable, therefore I would like to request feedback and suggestions. Also available through discord with the same name on linuxgsm server if you prefer pair programming review.

Features:

• Root access in entrypoint with gosu for linuxgsm to fix permissions. Feat: user permissions #33
• commands to provide standard functionality to existing third party images. They are used in the default entrypoint/scripts but existing images doing their own stuff, if they are only invoked in the entrypoint its easier for third party devs to adapt to it.
• variable uid / guid of the user for better compatibility Feat: user permissions #33
• Only the dependencies for the specific version/gameserver combination are installed and they are taken from linuxgsm output, therefore no additional maintenance
• every lgsm command is available in PATH in its long version and with prefix lgsm-CMD which allows for docker exec -it CONTAINER monitor or in scripting lgsm-monitor
• Supercronic for cron jobs Several questions #22
• health check added with lgsm-monitor as default
• docker logs will also show console output Request for new gameserver log command for docker logs #21 Work that I started but never finished #35
• LGSM_DEBUG="true" enabling on all scripts xtrace
• containers can be easily configured with environment variables: (result: one docker-compose.yml contains the complete config)
  • CRON_name="..." creating cronjobs e.g. CRON_MyJob="*/5 * * * * lgsm-monitor"
  • CONFIG_name="..." e.g. CONFIG_steamuser="MyUser" will check _default.cfg if "steamuser=" is present, if not fail, else add it to common.cfg
  • CONFIGFORCED_name="..." like CONFIG_ added to common.cfg but without any check, e.g. to add steam credentials even if they are not required
  • GAME_name="..." e.g. GAME_sv_voiceenable="0" added to/replaced in gameserver config without any check (will probably need some time to adapt to every config)
• fully automated testing
  • ./tests/quick.sh --version v21.4.1 gmodserver # test gameserver
  • ./tests/features.sh v21.4.1 # to check every listed feature
  • ./tests/full.sh --version v21.4.1 # checks every server, fully automated, parralel running, creates log per gameserver which also includes console
  • ./tests/push.sh # only push images successfully tested

Checklist

Pull request

PR will not be merged until all steps are complete.

• This pull request links to an issue.
• This pull request uses the develop branch as its base.
• This pull request Subject follows the Conventional Commits standard.
• This code follows the style guidelines of this project.
• I have performed a self-review of my code.
• I have checked that this code is commented where required.
• I have provided a detailed with enough description of this PR.
• I have checked If documentation needs updating.

Additional needed from my pov

• gameserver with steam account requirement tested
• some servers are failing for various reasons, see below
• readme update
• Default method to switch lgsm version is untested, may not work correctly.

Optional, probably follow up

• password should be handled as secrets, e.g. like docker-compose is using them
• hooks for docker devs so they don't need to overwrite the entrypoint always
• backups / restore with docker documentation
• lancache test integration for full.sh speedup
• dynamic config generation for non .cfg configuration files like maybe json will fail
• Version pinning for game server files?

State updated 05.04.2022

Ubuntu 22.04:

• only 2 failing mumble / zpsserver, pull request for the other stuff on the way

Feature Config injection with GAME_:

• only gmodserver currently tested

suggested versioning

Suggesting to use the common docker versioning without linuxgsm auto-update:

• lgsm:latest, lgsm:v21.4.1, lgsm:v21.4, lgsm:v21
• lgsm:gmodserver (= latest), lgsm:v21.4.1-gmodserver, lgsm:v21.4-gmodserver, lgsm:v21-gmodserver
• lgsm:develop, lgsm:v21.4.1-develop, lgsm:v21.4-develop, lgsm:v21-develop
• lgsm:gmodserver-develop, lgsm:v21.4.1-gmodserver-develop, lgsm:v21.4-gmodserver-develop, lgsm:v21-gmodserver-develop

Script for this:

1. (optional) bash init_dev_environment.sh to fix permissions (wsl2 fix), show missing dependencies for scripts
2. build/push stable:
   1. ./tests/full.sh --version v21.4.1
   2. ./tests/push.sh
3. build/push unstable:
   1. ./tests/full.sh --version v21.4.1 --suffix develop
   2. ./tests/push.sh --all

[jusito]

So regarding the first test there was some documentation needed. Iam a fan of less additional documentation, the code and the folder structure itself should be the documentation.

1. Changed the structure to build/runtime/deploy/... and also renamed some scripts to make an appropriate expectation just from the filepath - at least I hope.
2. Created some minimal documentation which maybe are common use case e.g. "How can I test my Lgsm fork with docker?" or "How can I just manually build this?"
3. updated '--help' on scripts
4. Created a script which generates example docker-compose files, including ports aso. It depends on how correct your port information per game are.
5. Additionally here is the state and whats needed e.g. on your side:

• bfv doesn't work because the default config is removed by accident, there is an open pull request which fixes it. GameServerConfigs pr 102
• I updated the LinuxGSM pr 3836 for v22.1.0, but there are open questions I need some answers from your side or at least a statement like "I dont want to discuss it please remove this or that".
  I really need these pr because I want to fix the other game configs but until they are merged it makes it very tedious at some point. For v21.4.1 every code worked but mumble/zpsserver for v22.1.0 some more are failing for different reasons, but all on lgsm side not on docker side. I will not fix them until we solve the other pr because its just duplicate work for me to fix them for different lgsm versions. The last month I only added features or debugged on lgsm side but the current docker side state doesn't need a lot of maintaining, I prepared everything that you only need to maintain lgsm and docker will work, so I still think it will be very easy for you to do so. Just for openssl I needed to add something special to fix it.

6. regarding openssl and ubuntu 22.04 I didnt add a dep package but compiled it from conan, conan provides always the most recent and we only need to update one string + create/push a new dockerimage + semver (which should be done by a ci so you only need to push a commit) -> every user will get the update.

[Claiyc]

Thanks for putting so much effort into this, looks quite promising. About GameServerManagers/LinuxGSM#3836 , I don't think that this requires much more work. However the only one who can effectively approve it is @dgibbs64 himself and he's quite busy at the moment afaik.

Will try to make some time to have a look at all this again.

[Claiyc]

So, I actually did take some time just now to take another look at this... And after trying to understand your code for a while I actually got to run a mcserver using your example-yml.

A few things I encountered that weren't so intuitive for me (reminder, I am a docker noob with only very very limited knowledge).

1. Understanding that I need to create my own image specifically for the mcserver first, before being able to start it with your proposed docker-compose command. After successfully doing so it seems trivial - I mean we don't have them yet on dockerhub, logically - however the image creation-process was a pain itself.

2. Understanding how to create a gameserver image myself. Well, this was something I was struggeling with for a while and I actually had to change some things in build/Dockerfile and in your entire structure for it to work.
   The issue was, that the COPY command for the local scripts in build/ and runtime/ didn't work (docker was trying to find the files in the docker-build-working-dir -context). I had to copy all scripts from runtime/ into build/, alter the paths and run the docker build from in there in order for it to work. Did not manage to get it to work any other way.

3. One more (I guess actual issue) I encountered: When issuing a stop command on a gameserver (docker exec -ti lgsm-server-1 stop, mcserver in my example but happens also with other servers), lgsm often waits for the server to actually shut down ("stopping mcserver: Graceful: sending "stop": 1, 2, 3, 4, 5, ..."). However the docker exec command does not and returns without the stop command being completed. The gameserver does stop anyway after a while, but it should be communicated to the user if the stop command was successful or not (especially necessary for automatic systems executing these commands and attempting to fetch the result).

One more thing (less an issue with your code than with me not understanding docker): On my first attempt to run docker-compose on one of the example ymls, it was exiting on me with the message "service 'name' must be a mapping not a string" - do you know what that was about? After re-installing docker (using docker desktop, I was working in a wsl2 container), it suddenly worked fine.

All in all it looks very nice, good work!

[jusito]

2. How to build is only mentioned in test documentation: How to build is only mentioned in test ./single.sh --build-only servercode But there was an false argument. Because of the assumption that it will be for normal enduser already pushed. Doing it without the scripts is really not simple.

3. Actually good to point it out, maybe there should be some basic docker info. I never thought someone would go into the container to close the application, you can just use docker stop CONTAINER or docker-compose down. So you invoke docker, the scripts will redirect it to lgsm-stop and waiting and docker itself will tell you if successful or not. For docker exec you can check the return code of docker exec so: docker exec -it lgsm-mcserver-1 stop followed by echo $? is an exit code of 137 for stop correct? This will btw collide with the compose file because in the compose file its configured to be restarted unless stopped, but docker only knows that its stopped if you invoke docker stop or docker-compose down. Therefore the server will be stopped but docker is configured to restart the container and therefore the server in no time.

[jusito]

ah and "service 'name' must be a mapping not a string" seems like one of the auto generated names is illegal for docker service
Edit: Tested every commited compose yml, no error on linux.

[Claiyc]

Thanks for the explanations, sounds logically to me :)

ah and "service 'name' must be a mapping not a string" seems like one of the auto generated names is illegal for docker service Edit: Tested every commited compose yml, no error on linux.

No idea about that tho. Perhaps I just did a mistake on my previous docker installation.