Backup/restart might overwrite credentials for the game server

[LiveOverflow]

Using the current version with a database backup feature that writes the database to data.sql could lead to a mismatch between the game server and master server credentials.

Symptoms:

• Player is stuck in a queue
• inside the game container ps will show the server running, but netstat shows no listening server.
• game server log output will show "Error logging in to master server: Invalid username or password"

During setup the master server creates a server account in the database and dumps the credentials into /opt/pwn3/server/creds. The game server setup then uses these credentials to connect to the master server. So when the account in the postgres database doesn't match the credentials used by the game server, then the player is stuck in the Queue. The game server will show these errors:

[2018.05.23-17.09.59:124][358]LogGameLogic:Display: [Master server connect] Unable to connect to master server.
[2018.05.23-17.09.59:124][358]LogGameLogic:Display: Error connecting to master server: Unable to connect to master server.
[2018.05.23-17.09.59:259][362]LogGameLogic:Display: Error logging in to master server: Invalid username or password
[2018.05.23-17.09.59:286][363]LogGameLogic:Display: Error logging in to master server: Invalid username or password

Workaround:

# on the host system, get a shell for the master server
docker exec -i -t pwnadventure3_master_1 /bin/bash

# in the master container create a new server account. this will write new credentials in the database
cd /opt/pwn3/server/MasterServer/
su pwn3
./MasterServer --create-server-account

# output should show something like this:
Username: server_10520dxxxxxxx
Password: 80bc3de5abbxxxxxxxx

# leave the container now. back on the host:

# edit the creds file to contain these credentials. actually the server.ini is the important one, but let's make sure everything is synced.

cat ./server/creds

Username: server_10520dxxxxxxx
Password: 80bc3de5abbxxxxxxxx

# make sure the server.ini also contains these creds
cat ./client/PwnAdventure3_Data/PwnAdventure3/PwnAdventure3/Content/Server/server.ini

[MasterServer]
Hostname=master.pwn3
Port=3333

[GameServer]
Hostname=game.pwn3
Port=3000
Username=server_10520dxxxxxxx
Password=80bc3de5abbxxxxxxxx
Instances=3

# tear down the game server
docker-compose down game

# restart the game server
docker-compose up -d game 

TODO:
somehow make sure the creds are also backuped and not overwritten or whatever.

[bennieboj]

This only happens if the user manually edits data.sql right?
The creds, server.ini and data.sql are already backed up on the host, since they are inside the 3 volumes?
Or am I missing something, if so please correct me.

Although I do agree that we should prevent this from happening, never underestimate users etc...

1. We could compare creds, server.ini and data.sql and if there is a difference just regenerate new creds using the existing script.

2. Also I noticed that the server stores the game servers inside the public.teams and the public.users tables. While this isn't a big issue, it isn't entirely clean either as the db will grow bigger. We probably should remove all the ones that are not in the current creds/server.ini.

One could argue to just do complete removal of all creds in data.sql and recreation of new creds at every boot of the server? That way we don't have to make annoying parsing and compare code which is bound to fail anyhow if users interact with the files. By doing so we hit two birds with one stone so to speak.

I got this solution ready if you think this is the way to go. I'm not entirely sure of the implications as I still need to test it this weekend, but I think it should be fine. I'll make a pull request once it's tested :)