WISP

WISP wird als gehosteter Dienst verkauft: wisp.gg betreibt das Panel, und der Node, der Ihre Gameserver trägt, läuft auf Ihrer eigenen Hardware. Der Agent spricht über die API mit dem Panel und für die Konsole mit dem Daemon des Nodes. Beides ist ausgehend, es muss also nichts ins Internet geöffnet werden.

WISP behält die Aufteilung von Pterodactyl in zwei API-Hälften bei, und kein einzelner Key erreicht beide. Legen Sie sie auf einem Administratorkonto an und fügen Sie beide zusammen mit der Adresse des Panels ein.

• Adresse des Panels: die vollständige URL, zum Beispiel https://panel.example.com. Geben Sie nur dann einen Port an, wenn das Panel tatsächlich darauf läuft; hinter einem Reverse Proxy antwortet es auf dem Standardport seines Schemas.
• Application-API-Key: er verwaltet Server: anlegen, sperren, neu installieren, entfernen.
• Client-API-Key: er trägt Ein- und Ausschalten, Live-Statistiken und die Konsole.
• TLS-Fingerprint (optional): bei einem gehosteten WISP-Panel bleibt das Feld leer; dessen Zertifikat stammt von einer öffentlichen Zertifizierungsstelle, es gibt also nichts zu pinnen.

Ein gehostetes WISP-Panel ist über https mit einem öffentlich vertrauenswürdigen Zertifikat erreichbar, das Fingerprint-Feld bleibt also leer. Tragen Sie hier nur dann etwas ein, wenn Sie WISP selbst hinter einem selbstsignierten Zertifikat betreiben; der Agent vertraut dann genau diesem einen Zertifikat, statt die Prüfung abzuschalten. Lesen Sie ihn aus mit:

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Lassen Sie das Feld leer bei einem Zertifikat einer öffentlichen Zertifizierungsstelle und ebenso dann, wenn das Panel nur über http erreichbar ist. Ein Fingerprint neben einer http-Adresse wird abgelehnt, weil es kein Zertifikat gibt, auf das sich pinnen ließe. Ein Panel auf schlichtem http funktioniert zwar, aber beide Keys reisen dann unverschlüsselt.

Ein Server wird aus einem Egg gebaut, genau wie bei Pterodactyl. WISP listet all seine Eggs samt ihren Variablen in einem einzigen Aufruf auf, die Auswahlliste füllt sich also selbst, und ein Plan kann jede Variable überschreiben, die das Egg als bearbeitbar kennzeichnet.

Ein Game-Plan trägt das Egg, die Ressourcengrenzen und etwaige überschriebene Variablen. Bestellt wird über einen Plan: Der Plan entscheidet, welches Egg verwendet wird und was der Server verbrauchen darf, und ein Plan lässt sich mit mehr als einem Panel verknüpfen.

Ein WISP-Node meldet seine Kerne, seinen Arbeitsspeicher und seine Festplatte, aber nicht, wie viel davon bereits vergeben ist. Provibr addiert das aus den Servern auf dem Node zusammen, wie es das auch bei einem Hypervisor tut.

Erstellen, Starten, Stoppen, Neustarten, Kill, Sperren, Freigeben, Neuinstallieren und Löschen funktionieren alle. Ein gesperrter Server lässt sich weiterhin entfernen, und beim Entfernen wird seine Port-Allocation wieder frei.

Die Konsole ist ein Live-Terminal auf dem Daemon des Nodes, im selben Panel wie der Rest Ihrer Infrastruktur, und die Verbrauchsgrafiken stammen aus den eigenen Messungen des Panels. Prozessor, Arbeitsspeicher, Festplatte und Netzwerk werden bei jeder Abfrage ausgelesen; eine Uptime meldet WISP nicht, ein Container, der zwischen zwei Abfragen neu startet, wird also nicht immer als Neustart erkannt.

Provibr verwaltet weder das Panel noch seine Nodes, Dateien, Backups, Datenbanken oder Benutzer. Auch die WISP-eigenen Zugaben gehören nicht zur Integration: der Splitter, Subdomains, Wipe-Zeitpläne, Mod-Stores. Was Provibr bereitstellt, zählt und berechnet, ist ein Gameserver auf dem Panel; Server, die Sie nicht über Provibr angelegt haben, bleiben unangetastet.