Add support for whitelist configuration

[iglrob]

Overview

Public accessible Minecraft servers are usually configured with a whitelist to control which players get access to ones server.

Involved parts

The first step is to configure the corresponding option in the server.properties file:
white-list=true

Furthermore a file called whitelist.json needs to be placed in the same folder like the server.properties file.
The structure of the whitelist looks as follows:

[
  {
    "uuid": "f430dbb6-5d9a-444e-b542-e47329b2c5a0",
    "name": "username"
  },
  {
    "uuid": "e5aa0f99-2727-4a11-981f-dded8b1cd032",
    "name": "username"
  }
]

Consideration

1. UUIDs only need to be configured manually when the server is started in offline mode. From the CLI there are 3 options:
   a. require the user to provide both name and uuid
   b. require only the name and expect the server to be in online mode
   c. require only the name and lookup the uuid before applying the configuration to the server from within the cli
2. The content of the whitelist can be changed by a mod from within the Minecraft server. This could result in a configuration drift between the resources maintained from the CLI and the expectations from a user. Scenarios are:
   a. Enforce the whitelist configured through the CLI with each update executed against the server
   b. Merge the whitelist between the existing one on the server and the one configured through the CLI.
   Important! This would make it impossible to delete a user from the whitelist through the CLI!
   c. Add support for explicit commands to the CLI like adding a user or deleting a user or even merging and enforcing the configured whitelist. While this would allow for a lot of options for the user it makes it somewhat brakes with the current style to configure everything in yaml.

[iglrob]

@dirien Input is highly welcome.

For the first point I'd prefer option c) with the possibility for optoin a):

• if the user provides both uuid and name the CLI takes the provided information
• if the user only provides the name the CLI looks up the corresponding uuids

The second point however has a lot of potential for conflict or confusion.

[dirien]

I like this feature, you can extend this also tho op list. Atm, i need to RCON to the server to add a user to the ops list.

Regarding the the three options have a look into my prometheus exporter -> https://github.com/dirien/minecraft-prometheus-exporter#api. There i use tha API from https://github.com/Electroid/mojang-api. Its much better then the vanilla mojang api.

As in the nature of minectl you need to have online conection, we could use the Electroid API to get the UUID/ID from there and treat the target server as potential offline. eg. server in a BungeCord mesh has to set the propery online-mode to false.

2. I see minctl as a ignition tool, bootstrapping a minecraft server and having some convinience fn by hand. Later we want to build a Crossplane / K8s Operator. and with the k8s conciliation pattern, we can use minectl-operator also to prevent configuration drift on managed resources. For now, i would calc the hash and warn the user (or a flag --force) that the server file will be overwritten. What you think?

[iglrob]

My summary:

1. Minectl creates the actual JSON-files, no use of RCON (so the user is not required to configure RCON to use this)
2. Minectl allows to put in the uuid in the configuration, but looks up the uuid throughhttps://github.com/Electroid/mojang-api if it's not given
3. If there is an unkown username, Minectl posts a warning, but doesn't cancel scaffolding
4. by default, minectl overwrites the existing whitelist. An additional option (--merge-configs) allows for just adding user not already in the whitelist
5. the whitelist will be applied to minecraft servers, not to any proxy (did a little research and it appeared that this is how it's done)
6. the same principles will be applied to the op list (would however create a second issue to keep them seperate as they provide 2 different capabilities just based on the same principles)

If that's fine by you I'd start working on the feature.

[dirien]

@iglrob, LGTM! Looking forward for your PR.