Eine Rechteverwaltung für fünf Server

Mein Minecraft-Netzwerk ist über Wochen gewachsen: ein Spielserver, ein Testserver, ein Server aus einem gekauften Paket, eine Lobby, ein Proxy. Und die Rechteverwaltung war entsprechend gewachsen — nämlich gar nicht.

Zwei Server hatten je eine eigene lokale Rechtedatenbank. Drei hatten überhaupt keine Rechteverwaltung, sondern nur die eingebaute Unterscheidung zwischen Serveradmin und allen anderen.

Das Ergebnis war absehbar: Wer auf einem Server ein Recht bekam, hatte es auf dem anderen nicht. Und ich musste mir merken, wo ich was eingestellt hatte.

Der Zielaufbau

Eine gemeinsame Datenbank für alle fünf, mit derselben Fassung der Rechteverwaltung überall — auf den Spielservern als Server-Plugin, auf dem Proxy als eigenständige Fassung.

Die drei Einstellungen, um die es geht:

storage-method: mysql        # gemeinsame Datenbank statt lokaler Datei
messaging-service: sql       # Änderungen werden über dieselbe Datenbank verteilt
server: global               # Rechte gelten überall, nicht pro Server

Der mittlere Punkt hat mich positiv überrascht: Um Änderungen zwischen Servern zu verteilen, braucht es keinen zusätzlichen Dienst. Die Datenbank selbst reicht als Übertragungsweg. Ich habe es geprüft, indem ich auf einem Server ein Recht gesetzt und auf einem anderen sofort abgefragt habe — ohne Neustart, ohne Neuladen.

Der dritte Punkt ist eine Entscheidung: Rechte könnten auch pro Server gelten. Für mein Netz war „überall gleich" richtig, weil die Server verschiedene Welten sind und keine verschiedenen Rollenwelten.

Die Zusammenführung ohne Verlust

Der heikle Teil. Zwei Bestände, die beide echte Daten enthielten, mussten zu einem werden.

Erstens: beide exportieren. Die Rechteverwaltung kann ihren gesamten Bestand in eine Datei schreiben. Das ist gleichzeitig die Sicherung.

Zweitens: vergleichen. Nicht zusammenführen, sondern erst ansehen: Welche Gruppen gibt es auf beiden Seiten? Welche Rechte unterscheiden sich? Gibt es Namensgleichheit mit unterschiedlicher Bedeutung?

Bei mir war der Unterschied klein und stammte fast vollständig aus Einstellungen, die ein Verwaltungsmenü automatisch gesetzt hatte.

Drittens: den größeren Bestand importieren, dann den kleineren ergänzen. Wichtig ist die Richtung des Imports — er führt zusammen, statt zu ersetzen. Wer das andersherum versteht, verliert einen Bestand.

Viertens: alte lokale Dateien nicht löschen, sondern umbenennen. Falls etwas fehlt, ist es noch da.

Warnung

Der Punkt, an dem man in dieser Situation Daten verliert, ist nicht das Zusammenführen, sondern das Aufräumen davor. Wer alte Gruppen löscht, weil sie „ja nicht mehr gebraucht werden", entfernt Rechtezuweisungen von Spielern, die noch daran hängen. Erst zusammenführen, dann eine Weile laufen lassen, dann aufräumen.

Was danach möglich wurde

Eine Rolle gilt überall. Wer auf einem Server Moderator ist, ist es auf allen. Das klingt selbstverständlich und war es vorher ausdrücklich nicht.

Rechte für den Serverwechsel. Mein eigenes Plugin prüft die Wechselbefehle jetzt gegen Rechte statt gegen eine eigene Liste — und die Vergabe läuft über die zentrale Verwaltung wie alles andere.

Eine Standardgruppe mit sinnvollen Rechten. Vorher hatte niemand außer Serveradmins irgendetwas. Jetzt gibt es eine Grundausstattung für alle, und Sonderrechte werden ergänzt statt einzeln vergeben.

Was eine gemeinsame Rechteverwaltung sonst noch löst

Der Hauptzweck war, dass Rechte überall gelten. Zwei Nebeneffekte haben sich als mindestens genauso wertvoll erwiesen.

Eine Stelle für alles. Vorher musste ich wissen, auf welchem Server ich etwas ändere. Jetzt ist es ein Befehl, egal von wo — die Änderung ist auf allen Servern sofort wirksam.

Eine Historie. Die Verwaltung schreibt mit, wer wann welches Recht vergeben hat. Bei fünf Servern mit eigenen Dateien gab es das nicht einmal ansatzweise.

Und ein Nachteil, der dazugehört: Ein Fehler wirkt jetzt überall. Wer eine Gruppe falsch konfiguriert, tut es für das ganze Netzwerk. Das ist der Preis für Einheitlichkeit, und er ist es wert — aber er verlangt mehr Sorgfalt bei Änderungen an Gruppen als vorher bei Änderungen an einem einzelnen Server.

Wie ich Gruppen heute schneide

Beim Zusammenführen musste ich entscheiden, wie die Gruppenstruktur aussehen soll. Was sich bewährt hat:

Wenige Gruppen mit klaren Aufgaben. Standard, Unterstützer, Team, Verwaltung. Nicht mehr als eine Handvoll.

Rechte an Gruppen, nicht an Personen. Eine Einzelvergabe ist immer eine Ausnahme und sollte einen Grund haben, der irgendwo steht.

Vererbung statt Wiederholung. Wer im Team ist, hat automatisch alles, was Unterstützer haben.

Serverbezogene Ausnahmen nur, wo sie fachlich sind. Die meisten Rechte gelten überall. Ein Recht, das auf einem bestimmten Server anders gilt, braucht eine Begründung — sonst entsteht wieder die Uneinheitlichkeit, die man gerade beseitigt hat.

Der letzte Punkt war bei mir eine bewusste Entscheidung gegen Flexibilität. Man könnte alles pro Server unterschiedlich machen. Die Frage ist, ob man das später noch überblickt — und die Antwort ist bei mir nein.

Was der Umbau für die Datenbank bedeutet

Eine gemeinsame Rechteverwaltung heißt, dass jeder Server bei jeder Prüfung dieselbe Datenbank befragt — und Rechteprüfungen passieren häufig.

Drei Dinge, die deshalb wichtig sind:

Zwischenspeicherung im Plugin. Die Verwaltung hält Rechte im Speicher und fragt nicht bei jeder Prüfung nach. Änderungen werden über einen eigenen Weg verteilt.

Die Datenbank muss erreichbar sein, wenn ein Server startet. Sonst startet er ohne Rechte — und das bedeutet, dass niemand etwas darf, inklusive der Verwaltung.

Der Ausfall der Datenbank ist ein Ausfall des Netzwerks. Das ist der Preis für Einheitlichkeit. Bei mir liegt sie deshalb auf derselben Infrastruktur wie die Server — ein Netzwerkproblem zwischen beiden ist damit ausgeschlossen.

Der zweite Punkt ist der, den man beim Aufbau bedenken muss: Die Startreihenfolge zählt jetzt, und zwar für jeden Server.

Der Fehler, der mir dabei aufgefallen ist

Beim Umbau ist etwas herausgekommen, das mit der Zusammenführung nichts zu tun hatte: Die Rechteprüfung meines eigenen Plugins greift nur beim Befehl, nicht beim Weg über ein Portal in der Lobby.

Das heißt: Wer den Befehl für einen bestimmten Server nicht benutzen darf, kommt trotzdem hin, indem er durch das entsprechende Portal läuft. Die Rechte wirken damit wie eine Befehlssperre, nicht wie eine Zugangssperre.

Für meinen aktuellen Aufbau ist das unkritisch — die Server, die wirklich nicht offen sein sollen, hängen gar nicht am Portalsystem. Aber es ist genau die Sorte Lücke, die entsteht, wenn eine Prüfung an einem Weg hängt und nicht am Ziel. Es steht als bekannter Punkt in den Notizen, mit dem Vermerk, dass der Portalweg dieselbe Prüfung bekommen muss, sobald ein Server tatsächlich gesperrt werden soll.