HestiaCP-Abrechnung automatisieren

Ein automatisiertes Hosting-Produkt hat genau drei Momente, in denen Geld und Maschinen einander berühren:

1. 01Die Bestellung ist bezahlt: innerhalb von Sekunden muss ein Konto mit dem richtigen Paket existieren.
2. 02Die Rechnung ist überfällig: das Konto muss dunkel werden und zurückkommen, sobald bezahlt wird.
3. 03Das Abonnement endet: das Konto muss weg, wirklich weg, samt Daten.

Für jeden dieser Momente hat HestiaCP einen Befehl. Was es nicht hat, ist irgendetwas, das entscheidet, wann Sie ihn ausführen. Diese Seite handelt davon, die beiden Hälften zu verbinden, und von den Stellen, an denen die API von HestiaCP so antwortet, dass ein erster Versuch leise kaputtgeht.

Die drei Momente und die Befehle darunter

Beachten Sie die Antwortspalte. Eine geglückte Änderung ist bei HestiaCP HTTP 204 mit nichts im Body. Nicht 200. Ein Client, der gegen die Annahme geschrieben wurde, Erfolg sei 200, weist jeden Aufruf zurück, der funktioniert hat, und wiederholt ihn dann meistens, und so wird aus einer funktionierenden Anbindung eine ausgesperrte (siehe unten).

Die eigentliche Antwort steht in einer Antwortkopfzeile, Hestia-Exit-Code, mit einer Zahl aus einer festen Tabelle. Der HTTP-Status ist davon abgeleitet und faltet rund zwanzig Codes auf vier Status. Lesen Sie die Kopfzeile; behandeln Sie den Status als Hinweis.

Stilllegen ist nicht symmetrisch, und hier wiegt das schwerer als sonst

Das ist die Falle, die speziell eine Abrechnungsanbindung trifft, denn eine Abrechnungsanbindung ist das Einzige, das dasselbe Konto zweimal stilllegt.

Gemessen, am selben Konto:

v-suspend-user   an einem aktiven Konto        → 204, Exit 0
v-suspend-user   an einem stillgelegten Konto  → 401, Exit 5   („user X is suspended“)
v-unsuspend-user an einem stillgelegten Konto  → 204, Exit 0
v-unsuspend-user an einem aktiven Konto        → 204, Exit 0

Reaktivieren ist idempotent. Stilllegen nicht. Und der Fehler, den es erzeugt, ist HTTP 401, derselbe Status wie bei falschem Geheimnis, bei einem Schlüssel außerhalb seines Umfangs und bei einer gesperrten Adresse.

Ein Mahnlauf, der alles Überfällige stilllegt, einschließlich dessen, was er gestern schon stillgelegt hat, meldet also Authentifizierungsfehler für Konten, die genau in dem Zustand sind, den Sie wollten. Exit-Code 5 bei v-suspend-user bedeutet „war schon so“ und muss als Erfolg gelesen werden.

Nach einem Authentifizierungsfehler niemals wiederholen

HestiaCP sperrt eine Adresse nach fünf abgelehnten Anmeldungen, mit fail2ban, maxretry = 5 und einem iptables-DROP. Sobald das feuert, laufen Aufrufe nicht mehr auf Anwendungsebene in einen Timeout, sondern auf Netzwerkebene. Ihre Überwachung sagt, das Panel sei nicht erreichbar, und nichts in Ihren Protokollen zeigt auf ein Problem mit den Zugangsdaten.

Für eine Abrechnungsanbindung wiegt das schwerer als für alles andere, denn eine Abrechnungsanbindung ist das, was nachts unbeaufsichtigt läuft. Zwei Folgen:

• Die Exit-Codes 9, 10 und 21 dürfen niemals eine automatische Wiederholung auslösen. Das sind falsches Geheimnis, Berechtigung verweigert und API abgeschaltet. Keiner davon ist eine vorübergehende Störung, und alle drei zählen für die Sperre.
• Ein Befehl außerhalb der Berechtigungen des Schlüssels zählt ebenfalls als fehlgeschlagene Anmeldung. Das liegt nicht auf der Hand: dieselbe Protokollzeile wird für ein falsches Geheimnis geschrieben wie für einen gültigen Schlüssel, der nach einem Befehl greift, den er nicht ausführen darf. Ein mit dem mitgelieferten billing-Satz beschränkter Schlüssel hat kein v-list-user-packages und kein v-list-web-domains, eine Abfragerunde über Pakete und Domains verbraucht den Sperrzähler also planmäßig. Verwenden Sie einen unbeschränkten Schlüssel des Administrators.

Eine Sperre aufzuheben braucht eine Shell auf dem Panel-Host: v-delete-firewall-ban <Adresse> HESTIA. Kann die Software, die Sie bauen, diesen Satz nicht sagen, verbringt die Person mit Bereitschaft die Nacht mit dem falschen Problem.

Eine bezahlte Bestellung kostet zwei Aufrufe, braucht also ein Zurückrollen

HestiaCP hat keinen Befehl, der einen Benutzer anlegt und gleich eine Domain darunter hängt. Das lässt ein Fenster offen:

v-add-user       provibrtest1 …                        → 204, Exit 0
v-add-web-domain provibrtest1 „keine gültige Domain“    → 422, Exit 2
v-list-user      provibrtest1                           → das Konto existiert, mit null Domains

Ein echter Unix-Benutzer, mit Home-Verzeichnis, ohne Website, und mit einer Zeile in jeder Zählung. War die Domain Ihrer Kundschaft auf Ihrem Panel schon belegt (und das kommt vor, weil Kundschaft umzieht), dann scheitert die Bestellung und Sie halten ein halbes Konto in der Hand, das nie jemandem auffällt.

Die Regel ist einfach und muss eingebaut sein: scheitert Schritt zwei, den Benutzer löschen und den ursprünglichen Fehler melden. Eine abgelehnte Domain darf nie ein halbes Konto hinterlassen.

Provibr tut genau das, und der Fehler, den die Kundschaft sieht, ist der von HestiaCP zur Domain und kein zweiter Fehler über eine Aufräumaktion.

Wo die Rechnung tatsächlich liegt

Es lohnt sich, das auszusprechen, denn es ist das häufigste Missverständnis: Provibr stellt Ihrer Kundschaft keine Rechnung. Es schickt ihr keine Rechnung, mahnt sie nicht und weiß nicht, was Sie ihr berechnen. Diese Beziehung gehört Ihnen.

Was Provibr berechnet, ist die Kapazität, die Sie reservieren: wie viele Hosting-Konten Sie gleichzeitig betreiben dürfen, pro Monat, zu einem gestaffelten Stückpreis. Was Sie Ihrer eigenen Kundschaft für ein HestiaCP-Konto berechnen und wie, bleibt vollständig in Ihrem eigenen Abrechnungssystem.

Es gibt zwei Wege, die beiden Hälften zu verbinden:

Ein WHMCS-Modul. Betreiben Sie bereits WHMCS, installieren Sie das Provibr-Provisioning-Modul und lassen Sie ein WHMCS-Produkt auf einen Provibr-Webhosting-Plan zeigen. Eine bezahlte Bestellung legt das Konto an, eine Stilllegung legt es still, eine Beendigung entfernt es. Ihre Kundschaft behält ein Konto, eine Rechnung und einen Login. Das Modul ist eine schlichte ZIP-Datei, die Sie selbst installieren und die in Ihrem WHMCS läuft. Auf unserer Seite muss nichts eingeschaltet werden.

Die REST-API. Betreiben Sie FOSSBilling, Blesta, etwas Eigenes oder eine Tabelle mit einem Cronjob, steuern Sie es direkt an. Ein Schlüssel, eine Basis-URL und genau die Rechte, die das Mitglied hinter dem Schlüssel ohnehin hat.

Die eine Regel für die Ansteuerung aus eigenem Code

Alles, was eine Maschine berührt, ist asynchron, und das muss es auch sein. Ihre Infrastruktur ist nur über den Agenten in Ihrem eigenen Netzwerk erreichbar, und der verbindet ausgehend. Ein Endpunkt, der ein Konto ändert, kann also nicht mit dem Ergebnis antworten. Er antwortet, dass der Auftrag angenommen wurde, und reicht Ihnen einen Befehl zum Verfolgen, den Sie lesen, bis sein Status endgültig ist: fertig, fehlgeschlagen, abgelaufen oder abgebrochen. Ein fehlgeschlagener Befehl trägt den Fehlercode des Agenten selbst samt Parametern, denselben, den das Panel auf Ihrem Bildschirm darstellt.

Lesen funktioniert nie so. Ein Bestand, eine Adresse oder eine Rechnung antwortet sofort, denn diese Antwort kommt aus einer Datenbank und nicht von Ihrem Host.

Die praktische Folge für einen Abrechnungs-Hook: markieren Sie die Bestellung nicht auf die Angenommen-Antwort hin als erledigt. Bei HestiaCP dauert v-add-user etwa eine Sekunde und v-delete-user etwa drei, das Warten ist also kurz, aber die Antwort, die Sie zuerst bekommen, lautet „wir haben es gesendet“ und nicht „es hat geklappt“.

Stilllegen ist auch Ihre eigene Kostenkontrolle

Ein Zusammenhang, der leicht übersehen wird. In Provibr zählt ein stillgelegter Server nicht zu Ihrer Kapazität, und für ein Hosting-Konto gibt es kein „gestoppt“: es gibt aktiv und stillgelegt.

Die Mahnaktion, die Sie aus kaufmännischen Gründen ohnehin ausführen wollten, ist also zugleich die, die den Platz freigibt, für den Sie bezahlen. Legen Sie ein überfälliges Konto still, zählt es sofort nicht mehr mit; löschen Sie es, zählt es ebenfalls nicht mehr; lassen Sie es laufen und unbezahlt, zahlen Sie dafür.

Was dies nicht automatisiert

Provibr verwaltet Konten, nicht das Panel. Es installiert HestiaCP nicht, aktualisiert es nicht, ändert keine Servereinstellungen und rührt weder DNS noch Postfächer noch Datenbanken an. Wer sein eigenes Postfach über HestiaCP löscht, tut das, ohne dass irgendetwas darüber es weiß oder sich darum kümmert. Für ein Hosting-Konto gibt es keine Konsole. Und es gibt keine teilweise Stilllegung: ein Konto ist aktiv oder nicht.

Verkaufen Sie auch VPS, Gameserver oder cPanel-Konten, gelten dort dieselben drei Momente, und sie können in einem Bestand liegen. Provibr betreibt heute seine Controlpanels, Hypervisoren und Gamepanels nebeneinander, mit einem Rechtemodell und einem Aktivitätsprotokoll über das Ganze.