Riventus.net – Wiederaufbau

Dieses Monorepo enthält die gesicherte und inventarisierte Ausgangslage des alten Minecraft-Netzwerks Riventus.net sowie Buildlogik, Betriebswerkzeuge und Dokumentation für den Wiederaufbau. Der aktuelle Zielstand läuft als datenbankgesteuerter RiventusCloud-Cluster auf himmel.node.servhosting.eu und rexlgames.de. Der öffentliche Velocity-Proxy bleibt auf himmel; eine PandaSpigot-Lobby läuft dynamisch und elf Spielgruppen bleiben On-Demand.

Sortierter Arbeitsbestand

applications/            # Proxy, Core, Lobby und 11 Game-Composition-Roots
modules/platform-api/    # gemeinsame Plattformverträge
modules/social-*/         # Social-Domain und 1.8-Wire-Vertrag
modules/proxy-system/    # vollständige Riventus-System-Fähigkeiten
adapters/*/platform/     # Panda-/Velocity-Plattformadapter
adapters/*/social*/       # MariaDB-, Velocity- und Lobby-Social-Adapter
adapters/velocity/system/ # Velocity-Runtime des Netzwerksystems
compat/runtime-overrides/ # 3 reviewbare Runtime-Rekonstruktionen

servers/
├── BungeeCord/          # vollständiger Proxy-Stand
├── Lobby/               # vollständiger Lobby-Stand
├── 1vs1/                # zehn Instanzen
├── SuperJump/           # zehn Instanzen
├── EndWars/             # drei Instanzen
├── FFA/                 # drei unterschiedliche FFA-Server
└── …                    # BashIt, EagleLeague, GunGame, Teamsurvival, TempleRun

artifacts/
└── plugin-bundle/       # 23 JARs aus Plugins.zip, nicht in Server eingemischt

website/
└── legacy-site/         # statischer Webauftritt von Mai 2017

Die Projekte stammen aus dem vollständigeren Source.zip. Die Server enthalten den vollständigen, etwa 2,3 GiB großen SMB-Netzwerkstand mit 32 Backends und exakt den dort installierten JAR-Varianten. Abweichende JARs aus Plugins.zip liegen bewusst separat unter artifacts/.

Einstieg

• Bestandsaufnahme – was in den Archiven steckt
• Plugin-Inventar – Sourcecode, JARs und Plattformen
• Alte Netzwerkstruktur – Proxy, Lobby und geplante Gameserver
• Alte Website – Webauftritt und erhaltene Markenassets
• Varianten und Konflikte – doppelte Source- und JAR-Stände
• Sortierte Struktur – Herkunft und Zuordnung der Arbeitskopien
• Vollständiger Serverbestand – Analyse der SMB-Netzwerksicherung
• Sicherheit – unbedingt vor Git, Build oder Serverstart lesen
• Migrationsvorschlag – sinnvoller Weg zu Gradle und einem neuen Serversystem
• Gradle-Build – reproduzierbarer Build der Composition- und Rekonstruktionsartefakte
• RiventusCloud-Deployment – aktive Velocity-Topologie, Fork, Gruppen und Verifikation
• RiventusCloud-Betrieb – aktuelles Runbook für Status, Wartung und Upgrade
• LuckPerms-/Velocity-Migration – zentrale Plattform, Ränge und Friends
• Plugin-Laufzeitvalidierung – behobene Abhängigkeiten und sequenzielle Live-Tests
• Datenbankbetrieb – MariaDB auf rexlgames, TLS, Secrets und Restore-Grenze
• Berechtigungen – Owner-Rechte und Grenze der Cloud-Befehle
• Restarbeiten und Laufzeitfehler – was noch fehlt oder nicht funktioniert
• Architekturentscheidungen – ADRs für Sicherheit und Betrieb
• Architektur-Grilling – abgeschlossene Interviewentscheidungen und Herleitung
• Multi-Cluster-Grilling – abgeschlossene Entscheidungen zu Cloud-State, zwei Nodes, Artefakten und Minecraft 26.2
• Multi-Cluster-Implementierungsplan – Meilensteine, gemeinsames Cutover, Gates und Abbruchbedingungen
• Zielarchitektur – konsolidierte Modul-, Runtime-, Daten- und Migrationsarchitektur
• RiventusProxy-Host – aktiver einheitlicher Velocity-Host
• RiventusCore-Host – Backend-Host, Datenhoheit, Adapter und sichere Ablösung der Kleinstplugins
• RiventusLobby-Host – aktive Lobby und migrierte Cloud-Schilder
• Cloud-Join-Koordination – aktiver ServiceMessageBus- und On-Demand-Join-Pfad
• Identity-/Nick-Migration – automatische Nicks, Legacy-Brücke und guarded Datenimport
• Glossar – gemeinsame Begriffe für Cloud, Gruppen und Services

Plugin-Build

Alle aktiven Quellen liegen in zielorientierten applications/, modules/, adapters/ und compat/; der frühere projects/-Migrationsbestand ist vollständig entfernt. Die Quellen von 1vs1, SuperJump, EndWars, FFA-Classic, TempleRun, BashIt, GunGame und QuickSG gehören direkt ihren Game-Applications. Social und das vollständige Velocity-Netzwerksystem liegen in Modulen und Adaptern, die drei Runtime-Overrides unter compat/. PandaSpigot 1.8.8 und Velocity 3.5.1 sind die aktiven APIs; LuckPerms ist die einzige aktive Permissionquelle.

Mit JDK 21:

./gradlew clean buildPlugins

Die deploybaren Java-21-JARs liegen anschließend unter build/plugins/. Der aktive Backend-Composition-Root wird als RiventusCore.jar gebaut. Der aktive Proxy-Composition-Root bündelt Plattform, Netzwerk und Social als RiventusProxy.jar; die früheren Standalone-JARs dürfen nicht zusätzlich installiert werden. Der aktive Lobby-Composition-Root erzeugt build/plugins/RiventusLobby.jar mit Navigation, Friends-GUI, Pets, Read-only-Toplisten und gruppenbasierten Cloud-Schildern. Details und bekannte Grenzen stehen in docs/GRADLE-BUILD.md und docs/LOBBY-HOST.md.

Aktiver Zielstand

Die installierten Runtime-Artefakte enthalten den Monorepo-Stand bis 761dc71; für die vorherige vollständige Gruppen-Laufzeitprüfung wurden außerdem die Validator-Korrekturen f2d3f82 und a55a28a verwendet. Der separate RiventusCloud-Fork läuft auf Commit 61c791e0.

• RiventusProxy, RiventusCore und RiventusLobby melden sich ohne Aktivierungsfehler bereit.
• RiventusLobby 2.1.1 registriert den Friends-Hotbar-Befehl, stellt die exakte historische 28-Pet-Auswahl bereit und schützt alle Mount-Übergänge gegen PandaSpigot-Reentranz.
• Dauerhaft laufen nur Proxy-1 und Lobby-1.
• 27 erhaltene DynamicSigns-Positionen wurden auf gruppenbasierte Cloud-Schilder migriert.
• Zehn Spielgruppen bestanden den gemeinsamen Batch-Lauf; Teamsurvival wurde nach seiner gezielten Laufzeitkorrektur separat erfolgreich load-validiert.
• Der öffentliche Ping liefert Minecraft-Protokoll 47 und die historische zweizeilige Riventus-MOTD.

Diese Prüfung bestätigt Start, Pluginbesitz, Abhängigkeiten und sauberen Stop. Echte Client-Interaktionen und vollständige Mehrspieler-Spielabläufe bleiben eine separate Abnahmegrenze.

Der aktuelle Source-Stand führt die acht sourcebasierten Game-Modi vollständig unter applications/games/ und benennt den bisherigen Zielnamen Teamsurvival wieder zu QuickSG. Diese Application-/Cloud-Umbenennung ist lokal gebaut, aber noch nicht auf den Zielhosts ausgerollt.

Im neueren, ebenfalls noch nicht ausgerollten Source-Stand sind Friends und das historische Netzwerksystem vollständig in den Proxy-Host migriert. Coins und Nick gehören zum Core; DynamicSigns, Lobby, Top10 und RankSigns gehören zum Lobby-Host. Für belegte Varianten gilt die freigegebene Regel: Die deployed Runtime ist Verhaltensbaseline, konfliktfreie Source-Funktionen werden ergänzt, und offensichtliche Sicherheits-, Threading- und Zeichenkodierungsfehler werden behoben. Der eigenständige Clans-Spielmodus ist bewusst ausgeschlossen; das Social-Clan-System bleibt erhalten. Der Quellstand ist gebaut, aber kein Deployment-, Client- oder Gameplaynachweis.

Lokale Zugangsdaten

Die aktuellen lokalen Datenbankvariablen liegen in .env. Die Datei ist absichtlich von Git ausgeschlossen und muss Modus 0600 besitzen. Neue Arbeitskopien verwenden .env.example als Vorlage:

cp .env.example .env
chmod 0600 .env

Werte aus .env dürfen weder committed noch in Logs, Tickets oder Chat ausgegeben werden. Das Repository enthält ausschließlich Variablennamen.

Ablage

legacy/
├── archives/
│   ├── downloads/       # zwei ZIP- und zwei RAR-Downloads
│   └── embedded/        # Source.zip und Plugins.zip aus SlionPlugins.zip
├── runtime/             # entpackter Serverstand (BungeeCord + Lobby)
├── source/              # 25 entpackte Eclipse-Projekte
├── source-rar/          # zweiter, kleinerer Source-Stand aus der RAR
├── plugin-jars/         # 23 separat überlieferte Plugin-JARs
├── website/             # statischer Webauftritt von 2017
└── checksums.sha256     # SHA-256 aller sechs Archivdateien

legacy/ ist absichtlich komplett von Git ausgeschlossen. Darin liegen unter anderem alte Zugangsdaten, Logs, Konfigurationen und 732 Playerdata-Dateien. Der Bestand bleibt so als unveränderte Referenz erhalten; eine später modernisierte und bereinigte Codebasis sollte außerhalb dieses Verzeichnisses entstehen.

Der frühere sanitizierte projects/-Migrationsbestand wurde nach vollständiger Fähigkeitsmigration entfernt; seine unveränderte Provenienz bleibt unter legacy/. servers/, artifacts/ und website/ bleiben wegen Binärdateien, Konfigurationen und personenbezogenen Daten ignoriert.

Die versionierbare Monorepo-Ebene umfasst derzeit Gradle-Konfiguration, Buildlogik, Dokumentation, systemd-Definitionen unter ops/ und geheimnisfreie Hilfswerkzeuge unter tools/. Die ignorierten Rohbestände bleiben trotzdem Teil des lokalen Arbeitsbereichs und ihre Herkunft ist in docs/ dokumentiert.