CloudPanel-Abrechnung automatisieren

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

1. 01Die Bestellung ist bezahlt: die Site muss innerhalb von Sekunden existieren, richtig konfiguriert.
2. 02Die Rechnung ist überfällig: die Site muss dunkel werden und zurückkommen, sobald bezahlt wird.
3. 03Das Abonnement endet: die Site muss weg, wirklich weg, samt Daten.

Für Moment eins hat CloudPanel einen sauberen Befehl, für Moment drei ebenso. Für Moment zwei hat es überhaupt nichts. Das ist keine kleine Fußnote unter einer ansonsten gewöhnlichen Integration, sondern die bestimmende Tatsache der Abrechnungsautomatisierung auf diesem Panel, und sie gehört in die Mitte dieser Seite statt in eine Zeile am Ende.

Die drei Momente und was CloudPanel bietet

Alles läuft über clpctl, das Kommandozeilenwerkzeug des Panels. Eine REST-API gibt es nicht: CloudPanel ist ein serverseitig gerendertes Panel plus eine CLI, und Automatisierung geht über diese CLI oder gar nicht.

Die beiden vorhandenen Befehle sind gute Befehle. site:add:php nimmt die Domain, die PHP-Version, eine vhost-Vorlage und den Linux-Site-Benutzer samt Passwort und kehrt zurück, nachdem vhost, Pool und Home-Verzeichnis geschrieben sind. site:delete --force ist ein echtes Löschen, kein weiches. Dazwischen liegt die Lücke.

Die fehlende Mitte, und wie sie gefüllt wird

Stilllegen ist die Aktion, die ein Abrechnungssystem häufiger ausführt als jede andere, denn sie ist diejenige, die unbeaufsichtigt läuft, nach Zeitplan, gegen Konten, auf die niemand schaut. Sie ist außerdem der einzige umkehrbare Hebel zwischen „weiter kostenlos hosten“ und „das Geschäft dieser Person löschen“.

CloudPanel hat kein Wort dafür. Es gibt kein site:suspend, kein site:disable, kein Wartungskennzeichen im Panel und keinen Status pro Site, den Sie umlegen könnten. Wenn Sie CloudPanel-Hosting verkaufen, ist Stilllegen also etwas, das Sie bauen. Die realistischen Möglichkeiten, mit ihrem ehrlichen Preis:

Den PHP-FPM-Pool der Site stoppen. Schnell, umkehrbar, und die Site hört wirklich auf auszuliefern. Es erzeugt allerdings einen 502 statt einer Erklärung, Ihre Kundschaft sieht also eine kaputte Website statt eines stillgelegten Kontos. Und es ist eine systemd-Operation auf dem Host, keine von clpctl. Sie halten sie über Panel-Upgrades hinweg selbst am Laufen.

Den vhost bearbeiten. Die NGINX-Konfiguration der Site ist eine Datei auf dem Host, und eine einzige Zeile darin entscheidet, ob die Site antwortet. Umkehrbar, sofort wirksam, und es kostet den Kunden nichts außer Zugang. Der Haken ist, dass Sie in eine Datei schreiben, die CloudPanel gehört. Es kommt also sehr darauf an, wie Sie hineinschreiben.

Löschen, mit vorheriger Sicherung. Eindeutig, und auf eine Weise endgültig, die Sie irgendwann einen Kunden kosten wird, der am einunddreißigsten Tag zahlt. Wiederherstellen ist kein Schalter, mit allem, was das für DNS, Zertifikate und die Mail bedeutet, die Sie danach schreiben müssen.

Eine vierte, saubere Möglichkeit gibt es nicht. Entscheidend ist, dass Sie bewusst eine wählen und dafür sorgen, dass die Person am Telefon weiß, welche es ist. Der Fehlerfall ist hier nicht technisch: Es ist eine Support-Kraft, die einem Kunden verspricht, seine Site sei gleich wieder da, auf einem System, auf dem Zurückkommen das Einspielen einer Sicherung bedeutet.

Wie eine sorgfältige vhost-Bearbeitung aussieht

Die zweite Option ist diejenige, die es wert ist, richtig gemacht zu werden, und „richtig“ ist eine kurze Liste. So macht es Provibr, und die Begründung gilt, ob Sie nun Provibr einsetzen oder es selbst schreiben.

Markieren Sie, was Sie einfügen. Die Stilllegung ist ein return 403; zwischen einem Anfangs- und einem Endkommentar. Entfernen heißt, genau die Zeilen dazwischen zu löschen. Die Wiederaufnahme hinterlässt die Datei also Byte für Byte so, wie sie war, und ein return 403;, das der Kunde aus eigenen Gründen gesetzt hat, bleibt unberührt. Ein Suchen-und-Ersetzen auf return 403 hätte diese Eigenschaft nicht.

Jeder öffentliche server-Block, nicht der erste. Ein vhost hat meist einen Block für Port 80 und einen für 443. Schreiben Sie nur in einen, bekommen Sie eine über HTTP stillgelegte und eine über HTTPS kerngesunde Site, schlimmer als gar keine Stilllegung, denn es sieht aus, als hätte es funktioniert.

Prüfen Sie die Konfiguration vor dem Neuladen. nginx -t läuft zuerst. Eine Stilllegung, die jede andere Site auf der Maschine mitnimmt, ist keine Stilllegung, und dies ist konstruktionsbedingt ein geteilter Webserver.

Machen Sie den Zustand vom Host aus lesbar. Weil die Markierung ein Kommentar in einer Datei ist, sind die stillgelegten Sites ein grep weit entfernt, und der Agent liest das zurück, statt der eigenen Datenbank zu glauben. Bearbeitet jemand die Datei von Hand, fällt es beim nächsten Durchlauf auf.

Was all das nicht ändert: CloudPanel selbst kennt weiterhin keine stillgelegte Site. Das Panel zeigt sie als gewöhnliche Site, denn aus Sicht des Panels ist sie eine. Jede Person mit CloudPanel-Zugang (auch der Kunde, den Sie gerade stillgelegt haben) kann diese Datei öffnen und die Zeile herausnehmen. Der Zustand ist lesbar und er wird am Webserver durchgesetzt, aber er gehört nicht dem Panel, und keine Konstruktion auf diesem Panel kann das ändern.

Einen Höherstufungspfad gibt es ebenso wenig, denn es gibt keine Pakete

CloudPanel hat keine Pläne, keine Kontingente und keine Grenzen pro Site. Damit fällt ein ganzer Moment aus der Liste oben weg: Es gibt keinen Aufruf „Paket ändern“, weil es kein Paket gibt.

Es heißt außerdem, dass der Unterschied zwischen Ihren Plänen anderswo echt sein muss. Landen Ihr 5-€-Plan und Ihr 15-€-Plan auf demselben CloudPanel mit überall demselben, dann hat Ihre Kundschaft einen Preis gekauft, und die erste Person, die das durchschaut, erzählt es den übrigen. Durchsetzung lebt oberhalb des Panels: getrennte Hosts je Stufe, Kontingente auf Dateisystemebene, oder Grenzen, die Ihre eigene Plattform anwendet und zählt.

Abgleich braucht eine Liste, und die gibt es nicht

clpctl kann Panel-Benutzer auflisten. Sites kann es nicht auflisten: Die liegen in der Panel-eigenen SQLite-Datenbank auf dem Host.

Für die Abrechnung ist das ein echtes Loch, denn ein Abrechnungssystem sollte jederzeit zwei Fragen stellen können: Existiert alles, was ich berechne, noch? und Steht hier etwas, das ich nicht berechne? Beide beantwortet man, indem man die eigenen Aufzeichnungen mit einer Liste dessen vergleicht, was wirklich auf der Maschine liegt. Ohne Liste erfahren Sie von einer von Hand gelöschten Site, wenn die Kundschaft schreibt, und von einer von Hand angelegten nie.

Was Sie auch über CloudPanel bauen, muss diese Liste woanders herbekommen als aus clpctl, und dafür braucht es Host-Zugang. In der Praxis gibt es genau einen Ort: die panel-eigene Datenbank /home/clp/htdocs/app/data/db.sq3, wo ein einfaches select über die Tabelle site in einem Zug die Domain, den Linux-Benutzer, den Typ, die vhost-Vorlage und die PHP-Version liefert. Provibr liest sie dort.

Das funktioniert, und es lohnt sich, klar zu sagen, worauf Sie sich damit einlassen. Dieses Schema ist die interne Angelegenheit von CloudPanel, keine veröffentlichte Schnittstelle, es kann sich also in einer Version ändern, ohne dass jemand ein Versprechen gebrochen hätte. Es zu lesen ist die richtige Entscheidung (ein Abrechnungssystem ohne Abgleich ist schlechter), aber es gehört auf die kurze Liste der Dinge, die nach einem Panel-Upgrade erneut zu prüfen sind, neben den Ausgabeformaten von clpctl.

Die Zugangsberechtigung ist kein API-Token

Das gehört deutlich gesagt, denn es ist der größte praktische Unterschied zwischen CloudPanel und einem Panel mit REST-API.

clpctl läuft als root. Es schreibt NGINX-Konfiguration, legt Linux-Benutzer an und verwaltet Dienste; root ist kein Versehen, sondern die Aufgabe. Was es ansteuert, hält damit administrativen Zugriff auf einen Produktions-Webserver, der die Sites anderer Leute trägt, und kein eng gefasstes Token, das nur eine API-Oberfläche berühren kann.

Zwei Folgen für alle, die hier Abrechnung anschließen. Die Schadensreichweite ist eine andere: Ein geleaktes Panel-API-Token lässt jemanden Konten anlegen und löschen, während eine geleakte Shell-Berechtigung auf dem Webserver ein anderes Gespräch mit anderen Pflichten ist. Und minimale Rechte sind Ihre eigene Arbeit: Es gibt kein Rechte-Häkchen, auf das Sie sich stützen könnten, Abgrenzung ist also etwas, das Sie entwerfen statt einstellen.

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 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. 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.

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. 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, und der Grund, warum die fehlende Mitte oben nicht nur Wohlwollen, sondern auch Geld kostet. In Provibr zählt ein stillgelegter Server nicht zu der Kapazität, für die Sie bezahlen. Für ein Hosting-Konto gibt es kein „gestoppt“: es gibt aktiv und stillgelegt.

Auf einem Panel, auf dem Stilllegen eine echte, unterstützte Aktion ist, gibt der Mahnschritt, den Sie aus kaufmännischen Gründen ohnehin wollten, also zugleich den Platz frei, für den Sie bezahlen. Auf einem Panel ohne diese Aktion ist jedes unbezahlte Konto, das Sie noch nicht löschen wollten, Kapazität, die Sie weiter tragen. Das ist ein Argument dafür, Ihre Stilllegungsregel früh festzulegen und sie aufzuschreiben.

Alles oben über das Panel ist eine Eigenschaft von CloudPanel und keine Beschreibung einer Integration, und das ist Absicht: Die Lücken sind echt, und es steht uns nicht zu, sie wegzuwünschen. Was eine Integration sehr wohl tun kann, ist sorgfältig zu wählen, welche der drei Optionen sie nimmt, und laut zu sagen, was diese Wahl weiterhin nicht löst.

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.