Host access to critical internal mount points for backups, mods, configuration

[Romaq]

I'm using commands like the following:

sudo rm -Rf /var/lib/docker/volumes/asa-server_server-files-1/_data/ShooterGame/Saved/SavedArks/TheIsland_WP (reset the map) I would have to "sudo" my way around for making backups, edit Game.ini, GameSettings.ini, edit settings for mods, look at log files, and so on.

What would be helpful is a script that would mount "critical directories" that's smart enough to notice "The server is running, I'm going to mount these points as read only" or "the server is offline, I'll allow write" to something like this...

~/asa-server/mnt/SavedArks ~/asa-server/mnt/Logs ~/asa-server/mnt/Config (/Saved/Config/WindowsServer) ~/asa-server/mnt/Mods (/Binaries/Win64/Shootergame, access to Mods & ModsUserData) ... and other such locations to make access to these safer (won't write while running) and easier (sudo to locations I can't tab-complete to). Bonus if it mounted with user:group permissions of the running host user indicated by ~/asa-server.

I originally thought through this issue as part of coping with mods having to edit "GameUserSettings.ini", but trying to find where in hell to put PlayersExclusiveJoinList.txt hasn't been much fun either. IF we can know the "correct" location for PlayersExclusiveJoinList.txt, "Allow Admin" list, "Allow Join When Too Full List" and so on... I recall 4 of that nature, and maybe have them "symlink" mounted so I could ONLY see those files and NOT the entire contents of "/Binaries/Win64", if that's where it's supposed to go? I can refer to the specific file names from my old ASE work if needed.

I get grumpy thinking of how the server was implemented, and I'm very grateful for the efforts of people like you who "clean up" the steaming pile of garbage organization we were handed.

This may also tie into "future proofing" when travel between maps becomes an option. I plan to open that issue when "ASA: Scorched Earth" comes online.

[mschnitzer]

If you don't want to be root, you don't have to be. All these operations can be performed from within the container or you spin up a separate one that acts as the user of the gameserver.

Just edit your docker-compose.yml and add a new container definition:

  asa-file-access-1:
    container_name: asa-file-access-1
    hostname: asa-file-access-1
    entrypoint: '/bin/bash -c "sleep 50000000"'
    user: gameserver
    image: 'mschnitzer/asa-linux-server:latest'
    volumes:
      - steam-1:/home/gameserver/Steam:ro
      - steamcmd-1:/home/gameserver/steamcmd:ro
      - server-files-1:/home/gameserver/server-files:ro

Once you run docker-compose up -d, you can access it like this:

docker exec -ti asa-server-1 bash

The file directories will then be read only and you can interact with these files. All actions will be performed as the gameserver user (25000:250000). However it needs to be mentioned that it is always readonly for that container, so it doesn't detect whether the actual server is running or not.

As for PlayersExclusiveJoinList.txt: In this section it is explained where server files are located. Where to place this file relative to the server files location, needs to be figured out by the system admin, as the container is not doing any changes to how the server structure is organized, nor can't it.

If you want to do these sorts of changes not as root user, you can do so from within the container, vim is available there. You can also copy files from the host system in the container, if you prefer that over editing them with vim in the container.

I do not prefer setting up links for that, as I'm a fan of showing everything what is actually there. The container is not supposed to hide config files or any other files from the system admin, this could potentially confuse people that search for specific config files which have been generated by a mod. They would search then at a place where the other links have been generated, because they would assume these other config files would be there as well.

[Romaq]

Thank you. As I know what I wish to do and what I'm looking for, it is a robust plan that does not have you chasing solutions to problems easily enough deal with on our side.

"vim is available there" that is the golden key I was missing. I found /usr/bin, but at that point my eyes were glazed over and I couldn't see "vim" while looking for "vi." This in particular is a better solution working within the environment.

Yes, given the early build nature of ASA, anything you do with the script can easily become irrelevant beyond the most basic functions. This is my first work with Docker, and so my opportunity to learn more about the tool in general. Thank you.