Mytho · Server-Verwaltung

Überblick

Mytho ist ein modularer MMO-Backend-Stack in Rust. Er ist getrennt in eine Control-Plane (dieser Master) und mehrere Daten-Dienste (Auth, Chat, Game, Datenbank), alle in Docker. Je Umgebung (Live/Test/Dev) läuft ein eigener, vollständig getrennter Stack mit eigenen Datenbanken – dieses Dashboard verwaltet den Stack seines Realms (das Dev-Dashboard zusätzlich realmübergreifend Deployment und Nutzer). Diese Seite beschreibt die geplante Zielarchitektur, den aktuellen Stand und das Gameserver-Konzept.

Zielarchitektur v5 (geplant)

Leitprinzip: Ein Edge Load Balancer (Traefik) ist ab dem MVP der einzige öffentliche Eingang für die austauschbaren HTTP/WSS-Dienste (Status, Login/Auth, Realm-Gateway, Chat). Gameplay-Verbindungen werden dagegen gezielt vom Realm-Gateway zugewiesen (konkrete Zieladresse + Zone-Ticket) – kein zufälliges Round-Robin. Der Master bleibt interne Control Plane und liegt nicht im Gameplay-Datenpfad. Master, NATS, Redis und PostgreSQL bleiben privat. (Quelle: Mytho_*_v5 in Server/doku/.)

Ausfallsicherheit

• Auth signiert Token mit Ed25519; andere Dienste prüfen sie lokal mit dem öffentlichen Schlüssel. Fällt Auth aus, bleiben eingeloggte Spieler aktiv – nur neue Logins sind blockiert.
• Fällt der Master aus, laufen die Dienste weiter und melden sich danach selbst wieder an.
• Mehrere Game-Server-Instanzen: fällt eine aus, sind nur deren Zonen betroffen.

Aktueller Stand vs. geplant

Dienste

Datenbanken (je Realm)

Jeder Realm (Live/Test/Dev) hat seine eigenen drei Datenbanken in einem eigenen Postgres-Container – Daten vermischen sich nie. Schema-Migrationen liegen in db/init/ und werden bei Promotion/Rebuild idempotent nachgezogen.

Dashboard-Funktionen

• Dienste: Live-Status aller registrierten Dienste (Heartbeat, Kennzahlen wie Konten-/Charakter-/Quest-Zahlen der Datenbanken).
• Steuerung: Container starten/stoppen/neustarten (nur mit ENABLE_DOCKER_CONTROL=true). Im Dev-Overlay zusätzlich Deployment: Promotion überträgt gebaute Images Dev → Test → Live, Rebuild baut einen Realm aus dem Quellcode neu – beides mit Migrations-Phase und Live-Protokoll.
• Realms: Realm-Verzeichnis pflegen (Name, Status, Sichtbarkeit public/dev/gm) – wirkt direkt auf die Realmauswahl im Client.
• Nutzer: Konten als filterbare Tabelle (Suche/Rolle/Status) mit Inline-Rollenwahl und Bann-Editor (temporär/permanent). Konto anlegen legt Konten auf einem wählbaren Realm an (Passwort-Hashing bleibt im Auth-Dienst des Ziel-Realms). Mit konfigurierten Sibling-Mastern (ADMIN_REALM_MASTER_URLS, Dev-Overlay) schaltet ein Realm-Umschalter die Kontenverwaltung auf Test/Live um.
• Nutzer → Commands verwalten (nur Rolle admin): Mindestrolle je Spiel-Kommando – Admin-Kanal (admin.add_gold, admin.add_experience, admin.set_level, admin.add_item, admin.set_speed, admin.kill_npc), dieselben Kommandos auf andere Spieler (admin.set_level.other …, Standard gm: greift nur, wenn der GM im Spiel einen Mitspieler anvisiert hat; der Server nimmt immer das Maximum aus Grund- und .other-Schlüssel), Anzeige-Tags über dem Spielernamen (tag.adm …), Weltinhalte schreiben (world.push) und Chat-Nachrichten senden (chat.send, Standard player – höher stellen beschränkt den Chat z. B. im Wartungsfenster auf Team-Rollen). Die Spalte Chat-Befehl zeigt die auslösende Chat-Eingabe (z. B. /addgold <betrag>; Quelle: ChatCommandHandler.gd, DB-Spalte chat_commands, nicht editierbar). Quelle: auth_db.command_permissions. Der Gameserver übernimmt Änderungen binnen 60 s; laufende Sitzungen behalten die Rolle aus ihrem Launch-Ticket bis zum nächsten Login. Fehlt ein Eintrag, gilt der Standardwert aus dem Code (fail-safe).
• Nutzer → Verstöße (ab Rolle gm): Anti-Cheat-Protokoll – eine Zeile je beendeter Spielsitzung, in der der Gameserver Client-Updates wegen fehlender Plausibilität verworfen hat, mit Verteilung je Art, Sitzungsdauer und der Angabe, ob die Sitzung wegen der Strike-Schwelle (50) getrennt wurde. Der laufende Server-Log ist auf eine Zeile alle 5 s je Sitzung gedrosselt und verliert die Verteilung; eine Zeile je Verstoß wäre umgekehrt selbst ein Flut-Vektor. Für Rollen ab qa greifen die Plausibilitäts-Prüfungen nicht (Speed-/Teleport-Tests sind Arbeitsmittel, Tester sollen keine Strikes sammeln) – solche Sitzungen erscheinen normalerweise nicht. Quelle: auth_db.violation_log, Aufbewahrung 24 Stunden (VIOLATION_LOG_RETENTION_HOURS), danach automatische Löschung. Fehlt die Tabelle, bleibt die Liste leer (fail-safe).
• Tests → Systemcheck (ab Rolle dev, Löschen ab gm): Einsendungen des Client-Systemchecks, abgegeben über die Seite /systemcheck im Dienst tester – ohne Anmeldung. Der Browser des Einsenders liest den Bericht selbst, übertragen werden nur der Bericht als JSON und die Formularangaben (Eindruck, MMO-Erfahrung, Maestia-Kenntnis, Zeit für geschlossene Tests, Discord/E-Mail). Das Formular gibt es auf Deutsch und Englisch (/systemcheck?lang=en); die gewählte Sprache steht in der Einsendung, damit ihr in der richtigen Sprache anschreibt. Der Master stuft beim Lesen nach den Schwellen des Clients ein (flüssig 60/40, gut 45/30, spielbar 30/20, knapp ab 20 FPS; mehr als 20 Ausreißer je Minute kosten eine Stufe), die Einstufung steht also nicht in der Datenbank. Ansicht: Kennzahlen, Verteilung der Einstufung, Auswertung je Grafikkarte und je Prozessor, Bewerber für geschlossene Tests, alle Einsendungen mit Details und Rohbericht; Excel mit drei Blättern. „Formular ansehen“ (auch über die Nummer in der Bewerberliste) öffnet eine Einsendung komplett als Blatt: der Bericht aufbereitet wie auf der Formularseite (Urteil, Kennzahlen, Strecke, Hardware, alle Messwerte, Hinweise), darunter alle Antworten; mit Druckansicht, Schließen per Knopf, Escape oder Klick daneben. Standardmäßig ohne gestörte Messungen, Kurzläufe und ausgeblendete Einsendungen. Quelle: auth_db.systemcheck_submissions (Migration 45). Fehlt die Tabelle, bleibt die Liste leer und die Seite meldet „nicht eingerichtet“.

Autoritätsübersicht (Client vs. Server)

Wer bestimmt welchen Spielwert? Legende der Spalte Verwaltung:

• Server-autoritativ – der Server rechnet/entscheidet, der Client kann es nicht fälschen.
• Server-persistiert (client-gemeldet) – der Server speichert, die Werte kommen vom Client, aber mit Plausibilitätsgrenzen (Anti-Cheat verwirft Unmögliches).
• Content (world_db) – vom Editor gepflegt, Schreiben nur ab Rolle dev.
• Client/lokal – (noch) nicht server-abgesichert oder bewusst rein lokal.

Kurzfazit: Alles, was Werte erzeugt (Gold, Items, Belohnungen, Level per GM), ist server-autoritativ. Was der Client noch meldet (Bestände, Zähler, Position), ist server-persistiert mit Plausibilitätsgrenzen. Noch offen (an die NPC-/Kampf-Autorität gekoppelt): NPC-Bewegung/HP/Aggro, Kampf/Schaden/Loot, fälschungssicherer Quest-Zähler, dupe-sicherer Inventar-Voll-Sync sowie die ENet-Transport-Verschlüsselung.

Gameserver-Konzept

Sharding: eine Instanz je Zone

Die Spielwelt wird in Zonen (und Layer/Ebenen) aufgeteilt. Jede Zone/Ebene läuft als eigene Game-Server-Instanz. Reicht die Kapazität nicht, kommen weitere Instanzen hinzu (horizontale Skalierung). Im v5-Modell weist das Realm-Gateway dem Spieler die konkrete Instanz zu (Auswahl über den Master nach Health/Last).

Verbindungsablauf (v5)

Wie ein Client in die Spielwelt kommt – vom Launcher-Login über den Edge bis zum gezielt zugewiesenen Zone-Server:

Weitere Bausteine (geplant)

• Server-autoritativ: der Game-Server ist die Wahrheit über Position/Zustand (Anti-Cheat).
• Interest-Management: ein Client erhält nur Updates aus seinem Sichtbereich/seiner Zone.
• Zonenwechsel/Handover: Übergabe zwischen Instanzen über ein neues Ziel-Ticket, koordiniert über Master/Bus.
• Persistenz: kontrolliertes Speichern (u. a. Logout-Position) über den Persistence Service (API + Redis-Cache), nicht direkt aus dem Zone-Server.

Sicherheit

Zugriffszonen (Master)

• Öffentlich: GET /healthz – ohne Authentifizierung.
• Intern (Dienste): POST /api/register, /api/heartbeat – nur mit Bearer-Token MASTER_SERVICE_TOKEN.
• Administrativ: Dashboard, /api/services, /api/realms*, /api/accounts*, /api/commands* (nur admin), /api/containers*, /api/promotions* – nur mit HTTP Basic (MASTER_ADMIN_USER/MASTER_ADMIN_PASSWORD).

Härtung

• Secrets werden nur als SHA-256-Hash gehalten und in konstanter Zeit verglichen; in production verhindern fehlende oder schwache/Default-Secrets den Start.
• Veröffentlichter Port nur an 127.0.0.1 gebunden; externer Zugriff ausschließlich hinter TLS-Reverse-Proxy oder VPN. CORS ist deaktiviert.
• Rate-Limit für Registrierung und fehlgeschlagene Admin-Anmeldungen (Heartbeats nicht limitiert); Request-Timeout und globales Concurrency-Limit.
• Container-Steuerung standardmäßig deaktiviert (ENABLE_DOCKER_CONTROL=true nötig); Deployment und realmübergreifende Nutzerverwaltung nur im Dev-Overlay.
• Passwörter werden ausschließlich im Auth-Dienst mit argon2id gehasht – auch bei der Konto-Anlage aus dem Dashboard leitet der Master nur weiter und hasht nie selbst.
• Dashboard rendert externe Werte nur als Text (kein HTML-Sink); strikte CSP (default-src 'self', ohne unsafe-inline) plus X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cache-Control: no-store; serverseitige Eingabe-Validierung + Body-Limit 16 KiB.
• Private Schlüssel werden nie geloggt; in production startet Auth nur mit gültigem AUTH_SIGNING_KEY.

Bedienung

cd Server
docker compose up -d --build          # bauen + starten
docker compose logs -f master         # Logs
docker compose down                   # stoppen
docker compose up -d --scale gameserver=3   # skalieren

Mehr Details

Ausführliche Dokumentation liegt im Repo unter Server/doku/ (Architektur, Dienste, Konfiguration, API, Datenbank, Betrieb, Gameserver-Konzept).