Upgrade einer Minecraft-Welt erzwingen

Meine mittlerweile über fünfzehnjährige Minecraft-Welt Akaria, belegt speichertechnisch bereits etliche Gigabyte auf der Festplatte. Allerdings ist dies bei solchen gewachsenen Welten nicht unbedingt das Problem. Bedingt durch viele Upgrades der Minecraft-Server-Versionen und damit einhergehenden Änderungen, wie z.B. am Chunk-Format, befindet sich irgendwann ein buntes Sammelsurium an Daten in den Weltordnern. An sich ist dies kein Problem, da Chunks beim Laden im Spiel automatisch konvertiert werden.

Ein Teil der Minecraft-Welt Akaria

Allerdings kann dies bei vielen Chunks mit Performanceeinbußen verbunden sein und die Chunks könnten teilweise noch Daten enthalten, die nur aufgrund vorheriger Versionen in diesen schlummern, aber in dieser Form nicht mehr benötigt werden. In einem solchen Fall bietet es sich an ein Upgrade aller Chunks und Regionen zu erzwingen:

screen java -Xms16G -Xmx16G -jar server.jar --forceUpgrade --recreateRegionFiles --eraseCache

Durch den Screen-Befehl kann die Session im Hintergrund weiterlaufen, nachdem sie detached wurde (Strg + A, anschließend Strg + D; Wiederaufruf mittels screen -r).

Damit beginnt der Minecraft-Server die Entities, POIs und Chunks zu upgraden. Während dieses Vorgangs, der je nach Welt, etliche Stunden dauern kann, ist der Minecraft-Server nicht erreichbar. In der Log-Datei latest.log kann der Fortschritt verfolgt werden:

[20:21:17] [Server thread/INFO]: 3% completed (10558 / 343881 chunks)...
[20:21:18] [Server thread/INFO]: 3% completed (10613 / 343881 chunks)...
[20:21:19] [Server thread/INFO]: 3% completed (10661 / 343881 chunks)...
[20:21:20] [Server thread/INFO]: 3% completed (10736 / 343881 chunks)...
[20:21:21] [Server thread/INFO]: 3% completed (10818 / 343881 chunks)...
[20:21:22] [Server thread/INFO]: 3% completed (10869 / 343881 chunks)...
[20:21:23] [Server thread/INFO]: 3% completed (10906 / 343881 chunks)...

Während die Option forceUpgrade dafür sorgt, dass der Upgradeprozess überhaupt angestartet wird, sorgt recreateRegionFiles dafür das neue und saubere Region-Dateien erzeugt werden, anstatt die alten Dateien nur zu bearbeiten. Die Option eraseCache löscht cacheähnliche Daten aus den NBT-Daten, darunter unter anderem Heightmaps, BlockLight und SkyLight. Diese Daten werden beim Neuladen der Chunks im Server ebenfalls wieder neu erzeugt.

Ist der Vorgang am Ende abgeschlossen, kann der temporär gestartete Server beendet werden und der Minecraft-Server wieder im Produktivbetrieb gestartet werden. Durch das Upgrade, das Löschen der Caches und der Neuanlage der Regionen, sollten viele Altlasten und potenzielle Probleme aus den Daten entfernt werden. Dies schlägt sich im Endeffekt auch positiv auf die Performance des Spieles im Serverbetrieb nieder.

Größe der Packdateien unter Git beschränken

Im Versionsverwaltungssystem Git existieren im Repository sogenannte Packfiles. Diese werden genutzt um mehrere Objekte, wie z.B. Commits, Trees, Blobs oder Tags, als einzelne Dateien abzulegen. Damit fasst Git viele Objekte zu einer einzelnen komprimierten Datei zusammen. Ergänzt wird das ganze durch einen Index, um einen schnellen Zugriff zu ermöglichen. Dabei nutzt Git Delta-Kompression, indem es ähnliche Objekte, z. B. verschiedene Versionen derselben Datei, nicht vollständig speichert, sondern nur die Unterschiede.

Eine Git-Pack-Datei im Schema

Dies reduziert die Repository-Größe erheblich, kann aber bei ungünstigen Repositorys mit vielen Binärdaten zu Repositorys führen, welche mehrere dutzend Gigabyte große Pack-Dateien besitzen. Eine Steuerung ist über den Konfigurationsparameter pack.packsizelimit möglich:

git config pack.packsizelimit 5g

Damit würde diese Einstellung für das aktuelle Repository gesetzt werden. Wer das Ganze global benötigt, kann dies ebenfalls einstellen:

git config --global pack.packsizelimit 5g

Allerdings gilt diese Einstellung nicht sofort, stattdessen muss für ein Repack gesorgt werden:

git repack -Ad --max-pack-size=5g

Anschließend kann die Größe der Packs kontrolliert werden:

ls -lh .git/objects/pack

Allerdings sollte beachtet werden, das die Option grundsätzlich nur in Ausnahmefällen sinnvoll ist:

Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs) and worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs).

Maus-Probleme in Minecraft unter Ubuntu

In einer Minecraft-Installation unter Ubuntu kann es zu Problemen kommen, das die Mausevents innerhalb des Spieles nicht korrekt verarbeitet werden. Dies kann unter anderem zu dem Effekt führen, dass Mausklicks, wie z.B. der Klick mit der rechten Maustaste nicht richtig erkannt werden und die Maustaste dann als dauerhaft gedrückt angenommen wird. Bei dieser Art von Problemen wird dann oft von Problemen mit Wayland ausgegangen oder mit der Einstellung Raw Input in den Mouse Settings von Minecraft versucht das Problem zu lösen.

Mit fehlerhaften Mausevents vergeht in Minecraft schnell der Spielspaß

Im vorliegenden Fall lag es aber an der Minecraft-Installation selbst, welche als Snap-Paket installiert war. Durch das Sandboxing kam es zu den Problemen bei der Erkennung der Mausklicks. Hier half es am Ende die Snap-Version zu deinstallieren und das Debian-Paket des Minecraft-Launchers zu installieren. Anschließend funktionierten die Mausklicks wie gewohnt.

Spamhaus DQS unter Postfix konfigurieren

Spamhaus betreibt seit vielen Jahren einige der effektivsten Echtzeit-Blocklisten (DNSBLs) gegen Spam, Botnets und missbrauchte Mailserver. Viele Administratoren nutzen diese Listen über die klassischen öffentlichen DNS-Mirrors, etwa zen.spamhaus.org. Doch seit einiger Zeit schränkt Spamhaus die Nutzung genau dieser Public Mirrors deutlich ein.

Insbesondere gilt dies für Nutzer großer Hosting- und Cloud-Provider wie Hetzner oder OVH. Wer Spamhaus nun z.B. beim eigenen Mailserver mit diesen Providern einsetzt, wird im Log solche Meldungen entdecken:

Service unavailable; Client host [203.0.113.127] blocked using zen.spamhaus.org; Error: open resolver;

Die Legacy-Mirrors sind eigentlich nur für kleine Installationen gedacht, also für einzelne Mailserver, die klar identifizierbar über ihre eigene IP-Adresse sind. Doch genau diese eindeutige Identifikation funktioniert nicht mehr zuverlässig, wenn Anfragen über große Cloud-Infrastrukturen kommen. Damit kann die Fair-Use-Policy nicht mehr sinnvoll durchgesetzt werden.

Als Alternative bietet sich der Spamhaus-Dienst Data Query Service (DQS) an. Damit werden die Abfragen weiterhin per DNS ausgeführt, jedoch über einen individuellen Zugangsschlüssel, der als Subdomain eingebettet wird und so eine eindeutige Identifikation ermöglicht. Im ersten Schritt muss hierfür ein Account angelegt werden. Nachdem der Account erstellt wurde, kann sich über das Portal eingeloggt werden. Dort kann unter dem Punkt Products → Data Query Service ein DQS-Schlüssel erzeugt werden.

Das Portal von Spamhaus

Anschließend kann mit der Konfiguration von Postfix begonnen werden:

nano /etc/postfix/dnsbl-reply-map

In diese Datei wird Folgendes eingetragen:

dqskey.zen.dq.spamhaus.net=127.0.0.[2..11]	554 $rbl_class $rbl_what blocked using ZEN - see https://www.spamhaus.org/query/ip/$client_address for details
dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]	554 $rbl_class $rbl_what blocked using DBL - see $rbl_txt for details
dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]	554 $rbl_class $rbl_what blocked using ZRD - domain too young
dqskey.zen.dq.spamhaus.net			554 $rbl_class $rbl_what blocked using ZEN - see https://www.spamhaus.org/query/ip/$client_address for details
dqskey.dbl.dq.spamhaus.net			554 $rbl_class $rbl_what blocked using DBL - see $rbl_txt for details
dqskey.zrd.dq.spamhaus.net			554 $rbl_class $rbl_what blocked using ZRD - domain too young

Der Platzhalter dqskey wird hierbei durch den realen DQS-Schlüssel ersetzt. Nach einer Ausführung von Postmap:

postmap /etc/postfix/dnsbl-reply-map

geht es an die eigentliche Konfiguration:

nano /etc/postfix/main.cf

Dort muss im ersten Schritt die alte Spamhaus-Konfiguration (wenn vorhanden) entfernt werden. Nun kann die neue Konfiguration hinzugefügt werden:

smtpd_recipient_restrictions =
    ...
    reject_rbl_client dqskey.zen.dq.spamhaus.net=127.0.0.[2..11]
    reject_rhsbl_sender dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]
    reject_rhsbl_helo dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]
    reject_rhsbl_reverse_client dqskey.dbl.dq.spamhaus.net=127.0.1.[2..99]
    reject_rhsbl_sender dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]
    reject_rhsbl_helo dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]
    reject_rhsbl_reverse_client dqskey.zrd.dq.spamhaus.net=127.0.2.[2..24]
    ...

Damit die DQS-Schlüssel nicht per Reject-Nachricht nach außen geleakt werden, wird noch die Reply Map eingebunden:

rbl_reply_maps = hash:$config_directory/dnsbl-reply-map

Anschließend kann Postfix neu gestartet werden:

systemctl restart postfix

Getestet werden kann das Ganze dann z.B. mit dem Blocklist Tester von Spamhaus.

Umstellung des master-Branch auf main-Branches in Forgejo

Der Standard-Branch in Git ist seit einiger Zeit main, anstatt des veralteteten master. Wer Projekte, die Forgejo nutzen, vom Branch master auf main umstellen möchte, muss den Standard-Branch entsprechend anpassen. Im ersten Schritt sollte lokal der main-Branch aus dem master-Branch erzeugt und auf den Server gepusht werden: 

git checkout master
git branch -m main
git push -u origin main

Anschließend kann in Forgejo der Standardbranch von master zu main geändert werden. Dies geschieht in den Einstellungen des Repositories unter Branches:

Die Einstellungen des Repository

Nun kann der Branch auf dem Git-Server gelöscht werden:

git push origin --delete master

Ist dies geschehen, kann der lokale Branch ebenfalls gelöscht werden:

git branch -D master

Auf verbleibenden lokalen Repositories kann die Aktualisierung nun wie folgt vorgenommen werden:

git pull
git checkout main
git branch -D master