WISP-Abrechnung automatisieren

WISP sperrt einen Server für Sie, und diese Sperre hält: Ein Kunde, der noch Zugangsdaten fürs Panel hat, kann nicht auf Start drücken. Was WISP nicht hat und auch nie behauptet zu haben, ist irgendeine Vorstellung davon, ob dieser Kunde Sie bezahlt hat.

Auf dieser Seite geht es um die Schicht dazwischen. Sie behandelt außerdem das eine, was WISP von jedem anderen Gamepanel hier unterscheidet und mit seiner API nichts zu tun hat: Das Panel gehört nicht Ihnen.

Das Panel ist gehostet, der Node gehört Ihnen

WISP wird als gehosteter Dienst verkauft. wisp.gg betreibt das Panel; der Node, der Ihre Gameserver trägt, läuft auf Ihrer eigenen Hardware. Ein Agent in Ihrem Netzwerk spricht ausgehend mit dem Panel über dessen API und für die Konsole mit dem Daemon Ihres Nodes, sodass nichts zum Internet geöffnet werden muss.

Für eine Abrechnungsanbindung hat diese Trennung eine echte Folge: Es gibt nichts, was Sie aktualisieren, und nichts, was Sie festnageln können. WISP kann seine API ändern, ohne dass eine Freigabe dazwischenliegt, die Sie steuern. Provibr ist gegen v3.7.5 getestet und liest die laufende Version aus dem Panel selbst, sodass ein Auseinanderlaufen im Verbindungstest auftaucht statt in einer gescheiterten Bestellung um zwei Uhr morgens.

Ein verwandtes Detail lohnt sich zu wissen, bevor Sie den eigenen Code verdächtigen. Die Vordertür des Panels sitzt hinter einer Cloudflare-Prüfung; jeder /api/…-Pfad geht glatt hindurch. Das wurde mit drei verschiedenen User Agents gemessen, und alle drei antworteten 200. Es ist eine Einstellung bei wisp.gg, nicht bei Ihnen und nicht bei uns, wenn WISP also jemals dieselbe Prüfung auf die API legt, hören alle WISP-Anbindungen auf einen Schlag auf, und lokal gibt es nichts zu reparieren. Der Fehlschlag hat eine erkennbare Form (403, eine Kopfzeile Cf-Mitigated: challenge und HTML statt JSON) und verdient eine eigene Meldung, damit das Panel sagt, es lässt uns nicht herein, statt falscher Schlüssel.

Der Lebenszyklus, abgebildet

Fünf Aktionen, und alle fünf antworten mit einem leeren 204. Im Body steht buchstäblich nichts, die Hausregel gilt also ohne Ausnahme: Keine Änderung vertraut ihrer eigenen Antwort. Lesen Sie den Server danach zurück.

Sperren wirkt wirklich, und es ist idempotent

Diese Kombination ist unter Gamepanels seltener, als sie sein sollte, und sie ist der ganze Grund, warum ein Mahnlauf auf WISP im guten Sinne langweilig ist.

Ein zweites Sperren an einem bereits gesperrten Server antwortet erneut 204. Nichts, wofür man einen Sonderfall braucht, nichts, was als „war schon so“ zu behandeln wäre, kein Fehler, den man schlucken muss. Vergleichen Sie das mit Control Panels, bei denen zweimal sperren ein Authentifizierungsfehler ist, und Sie sehen, wie viel einer Mahnanbindung sonst damit vergeht, sich für das Panel zu entschuldigen.

Löschen funktioniert auch an einem gesperrten Server, und das zählt für die Kündigung, die einen Monat nach der Sperre eintrifft. Ein zweites Löschen antwortet 404, und das ist das richtige Ergebnis für einen Beendigungs-Hook: Es ist nichts mehr aufzuräumen.

Die Zustandsregeln auf der Provibr-Seite sind absichtlich strenger als die des Panels:

Lesen Sie die Sperr-Zeile zweimal. Sie können einen Server sperren, der bereits gestoppt ist, und einen, der noch installiert wird. Wirkte eine Sperre nur an laufenden Servern, könnte ein Kunde seinen eigenen Server stoppen, aufhören zu zahlen und wäre unantastbar. Eine Durchsetzung, der man mit einem Druck auf Stopp ausweichen kann, ist keine Durchsetzung, und eine Kündigung, die mitten in der Installation eintrifft, sollte nicht warten müssen, bis die Installation fertig ist.

Zwei Schlüssel, kein Präfix, und der Fehler, der daraus folgt

WISP behält die Trennung von Pterodactyl zwischen zwei API-Oberflächen bei, und kein einzelner Schlüssel deckt beide ab. Der Application-Schlüssel baut, sperrt, installiert neu und entfernt; der Client-Schlüssel macht Power, Live-Statistiken und die Konsole. Beide werden auf einem Administratorkonto erstellt.

Und hier ist die Falle. WISP-Schlüssel tragen kein Präfix, anders als das ptla_ von Pterodactyl oder das papp_ von Pelican: Es sind 48 Zeichen ohne erkennbaren Kopf, nichts kann Ihnen also sagen, dass Sie sie vertauscht eingefügt haben. Wir nicht, und das Panel auch nicht, denn WISP antwortet auf einen falschen Schlüssel mit 403 und einer leeren Meldung. Ein 403 bedeutet normalerweise dieser Schlüssel darf das nicht, ein Kunde, der zwei Schlüssel vertauscht hat, geht also ins Panel und hakt Berechtigungen ab, die nie das Problem waren. Scheitert der Verbindungstest, tauschen Sie die beiden Schlüssel, bevor Sie irgendetwas anderes ändern.

Die andere Hälfte dieser Zugangsdaten verdient einen Satz in Ihrem eigenen Handbuch: Der Application-Schlüssel ist nicht nur Serververwaltung. Dieselbe Node-Liste, die eine Anbindung liest, trägt auch den Lizenzschlüssel Ihres Nodes und das Token seines Daemons. Behandeln Sie ihn als Zugangsdaten für das ganze Panel, und ziehen Sie ihn in WISP zurück, falls Sie die Anbindung je trennen.

Nichts geschieht sofort, und die API sagt das auch

Ihr Panel liegt in Ihrem eigenen Netzwerk und der Agent verbindet ausgehend, ein Endpunkt, der eine Maschine ändert, kann also nicht mit dem Ergebnis antworten. Er antwortet, dass der Auftrag angenommen wurde, und reicht Ihnen etwas zum Verfolgen:

POST /v1/servers/{serverId}/actions/suspend
Authorization: Bearer pvk_...
Idempotency-Key: dunning-inv-10482

{
  "command": {
    "id": "cmd_...",
    "kind": "game.suspend",
    "status": "pending"
  }
}

Das ist 202 Accepted, nicht 200. Danach lesen Sie den Befehl, bis sein Status endgültig ist: done, failed, timed_out oder cancelled. Lesen funktioniert nie so, denn ein Bestand oder eine Rechnung kommt aus einer Datenbank und nicht von Ihrem Host.

Alles, was etwas anlegt, akzeptiert einen selbst gewählten Idempotency-Key. Schlüsseln Sie ihn auf etwas Stabiles von Ihrer Seite, etwa die Rechnungsnummer plus die Mahnstufe, und ein Cronjob alle fünfzehn Minuten, ein wiederholter Webhook und ein Administrator, der zweimal klickt, werden alle harmlos.

Zwei Formen, die diese Anbindung kaputt gemacht haben, bevor Sie ihr begegnet sind

Beide lohnen sich zu lesen, selbst wenn Sie WISP nie anfassen, denn beide sind die Art von Fehlschlag, die Erfolg meldet.

Jede Identität ist eine Zeichenkette mit Präfix, keine Zahl. Ein WISP-Server ist server_01m0n8m94afcj2kk5mzt9z379q; Nodes, Eggs und Allocations sehen genauso aus. Die Plattform hatte eine Prüfung, dass die externe Kennung eines Gameservers aus Buchstaben und Ziffern besteht, was auf jedes andere Gamepanel zutrifft und hier falsch ist. Das Ergebnis war keine Fehlermeldung: WISP-Kunden über ihrer Grenze wurden dem Durchsetzungs-Worker gemeldet und dann übersprungen, jede einzelne Runde, für immer. Sie waren markiert und wurden nie gesperrt. Eine gemeinsame Identitätsprüfung deckt jetzt beide Formen ab.

Ein Plattengewicht von null wird abgelehnt. WISP verlangt limits.io und fordert einen Wert zwischen 10 und 1000. Das Planfeld der Plattform steht standardmäßig auf null, jede WISP-Bestellung wäre also in einem 422 über ein Feld geendet, von dem die meisten Menschen nie gehört haben. Es gibt jetzt zwei Zäune: Das Planformular lehnt eine Null ab und sagt warum, und der Agent hebt eine Null vor dem Senden auf das Standardgewicht. Zwei Zäune für einen Fehler sind Absicht, denn einer davon liegt auf der Seite, die Sie sehen können.

Was Sie nicht sehen können und nicht vortäuschen sollten

Das ist der ehrliche Teil, und er ist kurz.

• Es gibt kein Statusfeld an einem WISP-Server. Pterodactyl hat eines, mit installing und install_failed darin. WISP hat suspended und container.installed, beides boolesche Werte. Eine fehlgeschlagene Installation sieht daher genauso aus wie eine laufende: installed bleibt in beiden Fällen false. Wird gerade gebaut und kaputt sind auf dieser Oberfläche dasselbe Bild, und ein Produkt, das etwas anderes behauptet, rät.
• Ein Node meldet seine eigene Belegung nicht. Das Feld, das andere Panels dafür nutzen, fehlt, auch wenn Sie ausdrücklich danach fragen. Die Belegung wird stattdessen aus den Servern aufsummiert, was funktioniert und einen Aufruf mehr kostet.
• In den Live-Statistiken gibt es keine Uptime. Ein Container, der zwischen zwei Abfragen neu gestartet ist, lässt sich nicht mit Sicherheit erkennen. Dem steht gegenüber, dass WISP diese Statistiken nicht zwanzig Sekunden lang zwischenspeichert, wie Pterodactyl es tut, die Graphen erfinden also keinen Einbruch, den es nie gab. Unterm Strich besser, mit einer scharfen Kante.

Kapazität, und wie sie auf die Mahnung trifft

Provibr berechnet Ihnen Kapazität, nicht Ihre Kundschaft. Was Sie für einen Gameserver berechnen, bleibt vollständig in Ihrem eigenen Abrechnungssystem; wir sehen nie eine Kundenrechnung und sprechen nie mit Ihrer Kundschaft.

Die Regel, die im ersten Monat jeden erwischt: Jeder Server zählt, ob er läuft oder nicht. Ein gesperrter zählt nicht, und ein gelöschter auch nicht. Eine Maschine zu stoppen gibt nichts frei.

Das passt recht ordentlich zur Mahnung. Sperren Sie einen Kunden wegen Nichtzahlung, zählt er in diesem Moment nicht mehr gegen Ihre Kapazität; entsperren Sie ihn, wenn er zahlt, und er zählt wieder. Sie zahlen keine Plattformkapazität für jemanden, der Sie nicht bezahlt.

Was bewusst nicht automatisiert ist

Provibr verwaltet Server, nicht das Panel. Es installiert WISP nicht, rührt den Daemon Ihres Nodes über die Konsole hinaus nicht an und verwaltet bei diesem Anbieter weder Backups noch Firewall-Regeln noch die IP-Vergabe: Diese Fähigkeiten stehen im Register auf aus, statt halb umgesetzt zu sein. Es gibt keine verbrauchsabhängige Abrechnung auf die Nutzung von WISP, denn die Statistiken je Server werden im Panel angezeigt und nicht über die API bereitgestellt, und gegen einen Endpunkt, den es nicht gibt, lässt sich nicht abrechnen.

Wenn Sie noch auswählen, ist der Vergleich, den Sie zuerst lesen sollten, Ein Gamepanel nach seiner API auswählen, der sechs Panels an genau einer Frage misst: ob eine Sperre etwas bewirkt. Die Verbindung selbst, die zwei Schlüssel und das Feld für den Fingerabdruck sind auf der WISP-Integrationsseite beschrieben.