Drei Anläufe, einen Server auf 26.2 zu heben

Das Serverpaket, für das ich mich entschieden hatte, war für eine ältere Minecraft-Version gebaut. Mein restliches Netz läuft auf der aktuellen. Die Frage war: Lässt sich das Paket heben, und was kostet es?

Ich habe das an einem Tag in drei Durchläufen gemessen, statt es zu schätzen.

Die Falle vor dem ersten Versuch

Der Server startete überhaupt nicht, mit einer Meldung über die benötigte Java-Fassung. Die neueren Minecraft-Versionen verlangen eine neuere Java-Fassung, und mein Container-Abbild brachte die alte mit.

Das ist eine harmlose Sache mit einer unangenehmen Nebenwirkung: Solange der Server gar nicht hochkommt, sieht man keinen einzigen Plugin-Fehler. Ich hätte an dieser Stelle fast geschlossen, dass es aussichtslos ist — dabei hatte noch kein einziger Test stattgefunden.

Die drei Durchläufe

Der Sprung von vierzehn auf vier war reine Fleißarbeit: Für jedes Plugin die aktuelle Fassung besorgen und tauschen. Die meisten Projekte hatten längst eine Fassung für die neue Version.

Der Sprung von vier auf zwei brauchte zwei Erkenntnisse.

Erstens: eine aktuellere Protokollbibliothek. Ein zentrales Hilfsplugin, auf das mehrere andere aufbauen, lag in einer Fassung vor, die zu alt war. Die aktuelle Entwicklerfassung löst das — und sie ist nicht als normale Veröffentlichung verfügbar, sondern nur über die Bauumgebung des Projekts. Deren Seite lässt sich von einem Server aus nicht abrufen, weil ein Schutzmechanismus davor Skripten den Zugriff verweigert. Es brauchte also einen Menschen mit einem Browser.

Zweitens: ein eigener Fork. Für ein Plugin, das seit Jahren nicht mehr gepflegt wird, gab es keine neue Fassung. Dazu gibt es einen eigenen Eintrag — die Ursache waren zwei Zeilen in der Versionserkennung.

Was auf der Strecke bleibt

Zwei Plugins laufen nicht:

Ein Glücksspiel-Plugin, das mit einem Initialisierungsfehler abbricht. Keine öffentliche Quelle, kein Nachfolger.

Ein Bewegungs-Plugin, das direkt auf interne Serverklassen zugreift. Deren Namen haben sich geändert. Die Projektbeschreibung nennt ohnehin nur weit ältere Versionen.

Dazu kamen drei Plugins, die ich bewusst herausgenommen habe. Bei einem davon lohnt eine Warnung: ein Plugin, das beim Tod eine Kiste mit dem Inventar hinterlässt. Auf diesem Server ist die Spielregel für den Inventarerhalt ausgeschaltet — ohne dieses Plugin fällt beim Sterben alles zu Boden und kann verloren gehen. Wer so ein Plugin entfernt, muss die Spielregel mitändern. Solche Kopplungen sieht man in keiner Pluginliste.

Wozu der Aufwand

Die Frage ist berechtigt: Warum nicht einfach auf der älteren Version bleiben?

Weil das Netz zusammengehören soll. Sobald Gegenstände zwischen Servern wandern, müssen die Versionen zusammenpassen — ein Gegenstand aus einer neueren Version lässt sich in einer älteren nicht darstellen. Und Minecraft kann eine Welt nicht zurückstufen. Wer einmal auf der neueren Version ist, kommt nicht zurück.

Die Alternative wäre gewesen, das ganze Netz auf der älteren Version zu belassen. Das hätte bedeutet, dass jedes neue Plugin, jede neue Funktion und jeder neue Client-Sprung an dieser Entscheidung hängt.

Wie ich die Ausfälle gezählt habe

Damit die Zahlen belastbar sind, brauchte es eine feste Methode. „Es läuft nicht" ist keine Messung.

Nach jedem Start habe ich das Protokoll nach den Zeilen durchsucht, die das Fehlschlagen des Ladens eines Plugins melden. Jede davon nennt den Namen und die Ursache — meistens eine fehlende Klasse oder eine unpassende Versionsangabe.

Daraus entsteht pro Durchlauf eine Liste mit Namen und Fehlertyp. Und der Fehlertyp entscheidet über die nächste Handlung:

Fehlende Methode oder Klasse aus dem Server: Das Plugin ist zu alt. Neue Fassung suchen.

Fehlende Klasse aus einem anderen Plugin: Eine Abhängigkeit fehlt oder ist zu alt. Erst die Abhängigkeit prüfen.

Fehler beim Initialisieren: Etwas geht tiefer schief. Der aufwendigste Fall.

Unpassende Versionsangabe: Nur eine Beschränkung des Plugins, kein technisches Problem. Oft der einfachste Fall.

Diese Unterscheidung hat den Unterschied zwischen „vierzehn Probleme" und „drei Sorten Problem" gemacht — und die zweite Formulierung ist die, mit der man arbeiten kann.

Was ich über Versionssprünge gelernt habe

Ein Sprung ist billiger als zwei. Wer eine Version überspringt, bekommt überlagerte Änderungen und weiß bei einem Fehler nicht mehr, welche Umstellung ihn verursacht hat.

Die Reihenfolge ist: Umgebung, Abhängigkeiten, Rest. Erst die Laufzeitumgebung passend machen — sonst startet gar nichts und man sieht keine Plugin-Fehler. Dann die Bibliotheken, auf die andere aufbauen. Dann die einzelnen Plugins.

Ein Plugin ohne neue Fassung ist eine Entscheidung, keine Sackgasse. Ersetzen, forken, weglassen oder patchen — vier Möglichkeiten, und alle sind schon mal die richtige gewesen.

Der Rückweg braucht die vollständige Sicherung. Nicht nur die Programmdateien, sondern das gesamte Datenverzeichnis. Welten werden beim ersten Start unwiderruflich umgewandelt.

Der letzte Punkt ist der, bei dem Leute Daten verlieren — und der Grund, warum ich vor jedem Durchlauf ein vollständiges Archiv gezogen habe, auch beim dritten, als ich das Verfahren schon kannte.

Was ich am Verfahren gut fand

Messen statt schätzen. Ich hätte nach dem ersten Durchlauf mit vierzehn Ausfällen sagen können, dass es nicht geht. Die Zahl nach dem dritten ist zwei — und der Unterschied war ein Tag Arbeit, kein Wunder.

Jeden Durchlauf dokumentieren. Welche Plugins ausgefallen sind, mit welcher Meldung. Nach dem dritten Durchlauf konnte ich sagen, was mich welcher Schritt gebracht hat.

Die deaktivierten Plugins mit Grund im Dateinamen ablegen. Bei mir liegt zu jeder ausgemusterten Jar der Grund im Namen: keine Fassung für diese Version, ersetzt durch etwas anderes, bestätigt blockierend. Dieser Ordner ist die Dokumentation des Versionssprungs — und er darf nicht aufgeräumt werden.