docs: re-home mkdocs sources within this repo (#2149)

docs/misc/autopause/autostop.md

@@ -0,0 +1,25 @@
+# AutoStop
+
+An option to stop the server after a specified time has been added for niche applications (e.g. billing saving on AWS Fargate). The function is incompatible with the Autopause functionality, as they basically cancel out each other.
+
+!!! note 
+
+    the docker container variables have to be set accordingly (restart policy set to "no") and that the container has to be manually restarted.
+
+A starting, example compose file has been provided in [examples/docker-compose-autostop.yml](https://github.com/itzg/docker-minecraft-server/blob/master/examples/docker-compose-autostop.yml).
+
+Enable the Autostop functionality by setting:
+
+```
+-e ENABLE_AUTOSTOP=TRUE
+```
+
+The following environment variables define the behavior of auto-stopping:
+* `AUTOSTOP_TIMEOUT_EST`, default `3600` (seconds)
+  describes the time between the last client disconnect and the stopping of the server (read as timeout established)
+* `AUTOSTOP_TIMEOUT_INIT`, default `1800` (seconds)
+  describes the time between server start and the stopping of the server, when no client connects in-between (read as timeout initialized)
+* `AUTOSTOP_PERIOD`, default `10` (seconds)
+  describes period of the daemonized state machine, that handles the stopping of the server
+
+> To troubleshoot, add `DEBUG_AUTOSTOP=true` to see additional output

docs/misc/autopause/index.md

@@ -0,0 +1,71 @@
+# AutoPause
+
+### Description
+
+There are various bug reports on [Mojang](https://bugs.mojang.com) about high CPU usage of servers with newer versions, even with few or no clients connected (e.g. [this one](https://bugs.mojang.com/browse/MC-149018), in fact the functionality is based on [this comment in the thread](https://bugs.mojang.com/browse/MC-149018?focusedCommentId=593606&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-593606)).
+
+An autopause functionality has been added to this image to monitor whether clients are connected to the server. If for a specified time no client is connected, the Java process is stopped. When knocking on the server port (e.g. by the ingame Multiplayer server overview), the process is resumed. The experience for the client does not change.
+
+Of course, even loaded chunks are not ticked when the process is stopped.
+
+**You must greatly increase or disable max-tick-time watchdog functionality.** From the server's point of view, the pausing causes a single tick to take as long as the process is stopped, so the server watchdog might intervene after the process is continued, possibly forcing a container restart. To prevent this, ensure that the `max-tick-time` in the `server.properties` file is set to a very large value or -1 to disable it entirely, which is highly recommended. That can be set with `MAX_TICK_TIME` as described in [the section below](../../configuration/server-properties.md#max-tick-time).
+
+!!! note 
+
+    Non-vanilla versions might have their own configuration file, you might have to disable their watchdogs separately. For PaperMC servers, you need to send the JVM flag `-Ddisable.watchdog=true`, this can be done with the docker env variable `-e JVM_DD_OPTS=disable.watchdog:true`
+
+On startup the `server.properties` file is checked and, if applicable, a warning is printed to the terminal. When the server is created (no data available in the persistent directory), the properties file is created with the Watchdog disabled.
+
+The utility used to wake the server (`knock(d)`) works at network interface level. So the correct interface has to be set using the `AUTOPAUSE_KNOCK_INTERFACE` variable when using non-default networking environments (e.g. host-networking, Portainer oder NAS solutions). See the description of the variable below.
+
+A file called `.paused` is created in `/data` directory when the server is paused and removed when the server is resumed. Other services may check for this file's existence before waking the server.
+
+A starting, example compose file has been provided in [examples/docker-compose-autopause.yml](https://github.com/itzg/docker-minecraft-server/blob/master/examples/docker-compose-autopause.yml).
+
+### Enabling Autopause
+
+Enable the Autopause functionality by setting:
+
+```
+-e ENABLE_AUTOPAUSE=TRUE
+```
+
+Autopause is not compatible with `EXEC_DIRECTLY=true` and the two cannot be set together.
+
+!!! note 
+
+    When configuring kubernetes readiness/liveness health checks with auto-pause enabled, be sure to reference the `mc-health` wrapper script rather than `mc-status` directly.
+
+The following environment variables define the behaviour of auto-pausing:
+
+- `AUTOPAUSE_TIMEOUT_EST`, default `3600` (seconds)
+  describes the time between the last client disconnect and the pausing of the process (read as timeout established)
+- `AUTOPAUSE_TIMEOUT_INIT`, default `600` (seconds)
+  describes the time between server start and the pausing of the process, when no client connects inbetween (read as timeout initialized)
+- `AUTOPAUSE_TIMEOUT_KN`, default `120` (seconds)
+  describes the time between knocking of the port (e.g. by the main menu ping) and the pausing of the process, when no client connects inbetween (read as timeout knocked)
+- `AUTOPAUSE_PERIOD`, default `10` (seconds)
+  describes period of the daemonized state machine, that handles the pausing of the process (resuming is done independently)
+- `AUTOPAUSE_KNOCK_INTERFACE`, default `eth0`
+  <br>Describes the interface passed to the `knockd` daemon. If the default interface does not work, run the `ifconfig` command inside the container and derive the interface receiving the incoming connection from its output. The passed interface must exist inside the container. Using the loopback interface (`lo`) does likely not yield the desired results.
+
+!!! tip
+
+    To troubleshoot, add `DEBUG_AUTOPAUSE=true` to see additional output
+
+### Rootless Autopause
+
+If you're running the container as rootless, you might need to set change the default port forwarder from RootlessKit to slirp4netns.
+
+For Docker, see the following for setup:
+
+- https://docs.docker.com/engine/security/rootless/#networking-errors
+- https://rootlesscontaine.rs/getting-started/docker/#changing-the-port-forwarder
+
+For Podman, see the following for setup:
+- https://rootlesscontaine.rs/getting-started/podman/#changing-the-port-forwarder
+- Run with
+
+  ```
+  -e AUTOPAUSE_KNOCK_INTERFACE=tap0 --cap-add=CAP_NET_RAW --network slirp4netns:port_handler=slirp4netns
+  ```

docs/misc/healthcheck.md

@@ -0,0 +1,27 @@
+## Healthcheck
+
+This image contains [mc-monitor](https://github.com/itzg/mc-monitor) and uses its `status` command to continually check on the container's. That can be observed from the `STATUS` column of `docker ps`
+
+```
+CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                    PORTS                                 NAMES
+b418af073764        mc                  "/start"            43 seconds ago      Up 41 seconds (healthy)   0.0.0.0:25565->25565/tcp, 25575/tcp   mc
+```
+
+You can also query the container's health in a script friendly way:
+
+``` shell
+> docker container inspect -f "{{.State.Health.Status}}" mc
+healthy
+```
+
+There's actually a wrapper script called `mc-health` that takes care of calling `mc-monitor status` with the correct arguments. If needing to customize the health checks parameters, such as in a compose file, then use something like the following in the service declaration:
+
+``` yaml
+healthcheck:
+  test: mc-health
+  start_period: 1m
+  interval: 5s
+  retries: 20
+```
+
+Some orchestration systems, such as Portainer, don't allow for disabling the default `HEALTHCHECK` declared by this image. In those cases you can approximate the disabling of healthchecks by setting the environment variable `DISABLE_HEALTHCHECK` to `true`.

docs/misc/log4j.md

@@ -0,0 +1 @@
+**Please ensure you have pulled the latest image** since [all official mitigations](https://www.minecraft.net/en-us/article/important-message--security-vulnerability-java-edition) are automatically applied by the container startup process.

docs/misc/raspberrypi.md

@@ -0,0 +1,9 @@
+To run this image on a RaspberryPi 3 B+, 4, or newer, use any of the image tags [list in the Java version section](../versions/java.md) that specify `armv7` for the architecture, which includes `itzg/minecraft-server:latest`.
+
+!!! note
+   
+   You may need to lower the memory allocation, such as `-e MEMORY=750m`
+
+!!! note
+
+    If experiencing issues such as "sleep: cannot read realtime clock: Operation not permitted", ensure `libseccomp` is up to date on your host. In some cases adding `:Z` flag to the `/data` mount may be needed, [but use cautiously](https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label).

docs/misc/rcon.md

@@ -0,0 +1,41 @@
+[RCON](http://wiki.vg/RCON) is enabled by default, so you can `exec` into the container to
+access the Minecraft server console:
+
+```
+docker exec -i mc rcon-cli
+```
+
+Note: The `-i` is required for interactive use of rcon-cli.
+
+To run a simple, one-shot command, such as stopping a Minecraft server, pass the command as arguments to `rcon-cli`, such as:
+
+```
+docker exec mc rcon-cli stop
+```
+
+_The `-i` is not needed in this case._
+
+If rcon is disabled you can send commands by passing them as arguments to the packaged `mc-send-to-console` script. For example, a player can be op'ed in the container `mc` with: 
+
+```shell
+docker exec mc mc-send-to-console op player
+            |                     |
+            +- container name     +- Minecraft commands start here
+```
+
+In order to attach and interact with the Minecraft server, add `-it` when starting the container, such as
+
+    docker run -d -it -p 25565:25565 --name mc itzg/minecraft-server
+
+With that you can attach and interact at any time using
+
+    docker attach mc
+
+and then Control-p Control-q to **detach**.
+
+For remote access, configure your Docker daemon to use a `tcp` socket (such as `-H tcp://0.0.0.0:2375`)
+and attach from another machine:
+
+    docker -H $HOST:2375 attach mc
+
+Unless you're on a home/private LAN, you should [enable TLS access](https://docs.docker.com/articles/https/).

docs/misc/troubleshooting.md

@@ -0,0 +1,5 @@
+To troubleshoot the container initialization, such as when server files are pre-downloaded, set the environment variable `DEBUG` to `true`. The container logs will include **much more** output, and it is highly recommended including that output when reporting any [issues](https://github.com/itzg/docker-minecraft-server/issues).
+
+To troubleshoot just the command-line used to start the Minecraft server, set the environment variable `DEBUG_EXEC` to `true`.
+
+To troubleshoot any issues with memory allocation reported by the JVM, set the environment variable `DEBUG_MEMORY` to `true`.

docs/misc/world-data.md

@@ -0,0 +1,126 @@
+
+## Downloadable world
+
+Instead of mounting the `/data` volume, you can instead specify the URL of a ZIP or compressed TAR file containing an archived world. It will be searched for a file `level.dat` and the containing subdirectory moved to the directory named by `$LEVEL`. This means that most of the archived Minecraft worlds downloadable from the Internet will already be in the correct format.
+
+    docker run -d -e WORLD=http://www.example.com/worlds/MySave.zip ...
+
+!!! note
+
+    This URL must be accessible from inside the container. Therefore, you should use an IP address or a globally resolvable FQDN, or else the name of a linked container.
+
+!!! note
+
+    If the archive contains more than one `level.dat`, then the one to select can be picked with `WORLD_INDEX`, which defaults to 1.
+
+## Cloning world from a container path
+
+The `WORLD` option can also be used to reference a directory, zip file, or compressed tar file that will be used as a source to clone or extract the world directory.
+
+For example, the following would initially clone the world's content from `/worlds/basic`. Also notice in the example that you should use a read-only volume attachment to ensure the clone source remains pristine.
+
+```
+docker run ... -v $HOME/worlds:/worlds:ro -e WORLD=/worlds/basic
+```
+
+The following diagram shows how this option can be used in a compose deployment with a relative directory:
+
+![](../img/world-copy-compose-project.drawio.png)
+
+## Overwrite world on start
+The world will only be downloaded or copied if it doesn't exist already. Set `FORCE_WORLD_COPY=TRUE` to force overwrite the world on every server start.
+
+## Custom worlds directory path
+To set a custom worlds directory for the Multiverse plugin on a baremetal server, you'd pass the `--world-dir` argument after the jar file.
+In order to accomplish the same in a containerized server, set the `EXTRA_ARGS` environment variable in your command line or docker compose yaml to the same argument string. For example:
+
+```
+docker run -d -e EXTRA_ARGS='--world-dir ./worlds/'
+```
+`--world-container`, `-W`, and `--universe` are aliases to `--world-dir` and can also be used.
+
+## Datapacks
+
+Datapacks can be installed in a similar manner to mods/plugins. There are many environment variables which function in the same way they do for [mods](../mods-and-plugins/index.md):
+
+* `DATAPACKS`: comma-separated list of zip file URL, zip file in container, or directory in container
+* `DATAPACKS_FILE`: a text file within the container where each line is a zip file URL, zip file in container, or directory in container
+* `REMOVE_OLD_DATAPACKS`: if "true" the datapacks directory is removed of everything matching `REMOVE_OLD_DATAPACKS_INCLUDE`, but excluding `REMOVE_OLD_DATAPACKS_EXCLUDE` no deeper than `REMOVE_OLD_DATAPACKS_DEPTH`
+* `REMOVE_OLD_DATAPACKS_DEPTH`: default is 16
+* `REMOVE_OLD_DATAPACKS_INCLUDE`: default is `*.zip`
+* `REMOVE_OLD_DATAPACKS_EXCLUDE`: default is empty
+
+Datapacks will be placed in `/data/$LEVEL/datapacks`
+
+## VanillaTweaks
+
+[VanillaTweaks](https://vanillatweaks.net/) datapacks, crafting tweaks, and resource packs can be installed with a share code from the website **OR** a json file to specify packs to download and install. Datapacks and crafting tweaks will be installed into the current world directory specified by `$LEVEL`. As new versions of the packs are retrieved the previous versions will automatically be cleaned up.
+
+The share code is the part following the hash sign, as shown here:
+
+```
+https://vanillatweaks.net/share/#MGr52E
+                                 ------
+                                  |
+                                  +- share code MGr52E
+```
+
+Accepted Parameters:
+
+- `VANILLATWEAKS_FILE`: comma separated list of JSON VanillaTweak pack files accessible within the container
+- `VANILLATWEAKS_SHARECODE`: comma separated list of share codes
+
+Example of expected VanillaTweaks share codes:
+
+!!! note
+
+    ResourcePacks, DataPacks, and CraftingTweaks all have separate sharecodes
+
+``` yaml
+VANILLATWEAKS_SHARECODE: MGr52E,tF1zL2,LnEDwT
+```
+
+Example of expected VanillaTweaks files:
+
+``` yaml
+VANILLATWEAKS_FILE: /config/vt-datapacks.json,/config/vt-craftingtweaks.json,/config/vt-resourcepacks.json
+```
+
+``` json title="DataPacks json"
+{
+  "type": "datapacks",
+  "version": "1.18",
+  "packs": {
+    "survival": [
+      "graves",
+      "multiplayer sleep"
+    ],
+    "items": ["armored elytra"]
+  }
+}
+```
+
+``` json title="ResourcePacks json"
+{
+    "type": "resourcepacks",
+    "version": "1.18",
+    "packs": {
+        "aesthetic": ["CherryPicking", "BlackNetherBricks", "AlternateBlockDestruction"]
+    }
+}
+```
+
+
+``` json title="CraftingTweaks Json"
+{
+    "type": "craftingtweaks",
+    "version": "1.18",
+    "packs": {
+        "quality of life": [
+            "dropper to dispenser",
+            "double slabs",
+            "back to blocks"
+        ]
+    }
+}
+```