ISPConfig-Abrechnung automatisieren

ISPConfig hat einen Befehl für jeden Moment, in dem Geld und Maschinen einander berühren: das Konto anlegen, es sperren, es in ein anderes Paket verschieben, es entfernen. Was es nicht hat, ist irgendetwas, das entscheidet, wann sie auszuführen sind.

Die beiden Hälften zu verbinden ist größtenteils gewöhnliche Arbeit. Zwei Dinge an ISPConfig sind nicht gewöhnlich, und beide machen einen ersten Versuch leise kaputt: Der Statuscode eines Aufrufs sagt Ihnen überhaupt nichts, und ein Konto ist kein Kunde.

Der Statuscode sagt nichts

Alles kommt als HTTP 200 zurück. Validierungsfehler, „das gibt es nicht“, ein falsches Passwort, eine Methode, die der Remote-Benutzer nicht aufrufen darf: alle, 200. Das Urteil steht in einem Feld code im JSON-Body.

Klassifizieren Sie über code und über den Text, niemals über den Status. Der Grund, warum das für eine Abrechnungsanbindung schwerer wiegt als für alles andere, ist die Abfragerunde: Ein Client, der 200 als Erfolg behandelt, liest einen Authentifizierungsfehler als erfolgreichen leeren Bestand und markiert dann jedes Konto dieses Kunden als verschwunden. Eine abgelaufene Sitzung, und Ihr Abgleich löscht ein Hostinggeschäft.

Das Feld message kommt in zwei Geschmacksrichtungen, und der Unterschied ist nützlich. Validierungsfehler aus der Formularschicht des Panels sind eine mit <br> getrennte Liste von Übersetzungsschlüsseln und keine Sätze: domain_error_unique für eine Domain, die bereits gehostet wird. Prüfungen in der Remote-Bibliothek sind gewöhnliche englische Sätze: Invalid client_id 99999. Gleichen Sie die Schlüssel ab, zitieren Sie die Sätze.

Ein Konto ist eine Website, kein Kunde

ISPConfig trennt zwei Dinge, die die meisten Control Panels verschmelzen. Ein Client ist ein Panel-Login mit kontoweiten Grenzen. Eine web_domain ist eine gehostete Website. Ein Client kann mehrere Websites besitzen.

Ein Hosting-Konto in Provibr ist eine Website, gekennzeichnet durch ihre Domain. Eines anzulegen braucht daher einen Eigentümer, der Agent legt also einen frischen Client und darunter eine Website an und leitet den Client-Login aus der Domain ab, damit er den Eigentümer immer wiederfindet.

Diese Entscheidung ist es, die den Löschpfad sicher macht, und der Löschpfad ist die Stelle, an der diese Anbindung beinahe schiefgegangen wäre. Dazu unten mehr.

Der Lebenszyklus, abgebildet

Sperren ist in beide Richtungen idempotent

Eine Sperre schaltet das Flag active der Website zwischen y und n um. Es gibt keine Bitmasken und keine Teilzustände: Eine Website ist an oder sie ist aus.

Ein zweites Sperren an einer bereits gesperrten Website antwortet code: ok mit einer Antwort von 0, was null geänderte Zeilen bedeutet. Das ist kein Fehler, und ein Mahnlauf, der alles Überfällige sperrt, einschließlich dessen, was er gestern gesperrt hat, hat sich für nichts zu entschuldigen. Es lohnt sich zu würdigen, wie selten das ist: Wie HestiaCP-Abrechnung automatisieren zeigt, ist dasselbe zweite Sperren dort ein HTTP 401, nicht zu unterscheiden von einem falschen Geheimnis, auf einem Panel, das Ihre Adresse nach fünf abgelehnten Anmeldungen sperrt.

Eines sollten Sie kennen, auch wenn die Anbindung es nicht nutzt: ISPConfig hat außerdem eine Sperre auf Client-Ebene, und sie zu setzen schaltet jede Website dieses Clients auf einmal inaktiv. Ein Kunde, der sich im Panel selbst sperrt, oder eine Reseller-Sperre über ihm taucht daher in der Abfragerunde als gesperrt auf. Das ist richtig so, und es ist nichts, was Ihr Abrechnungssystem getan hat.

Ein Paket zu wechseln ist hier eine echte Handlung

Ein ISPConfig-Paket ist eine Kundenvorlage: ein benannter Satz Grenzen, den ein Administrator im Panel baut. Die Remote-API kann keine anlegen, und das ist in Ordnung, denn ein Plan sollte auf ein Paket verweisen, statt es zu erfinden. Provibr übergibt den Paketnamen, und der Agent schlägt die Kennung der Vorlage nach.

Damit ist ISPConfig eines der Control Panels, bei denen ein Planwechsel wirklich ein Planwechsel ist. CloudPanel und CyberPanel müssen ihn rundheraus ablehnen; hier geschieht er, und die Grenzen bewegen sich sofort.

Zwei gemessene Warnungen, falls Sie das selbst schreiben. Schicken Sie eine minimale Aktualisierung, die nichts als die neue Vorlage trägt: Eine Aktualisierung mit dem ganzen Client-Datensatz kam als remote_fault ohne brauchbare Meldung zurück, und ebenso eine, die eine ausdrückliche Vorlage mit ausdrücklichen Grenzen kombinierte. Und wissen Sie, dass die Vorlage Grenzen überschreibt, die Sie zusätzlich schicken, was die richtige Richtung ist, beim ersten Mal aber überrascht.

Das Fertig-Signal gilt für den ganzen Server

Eine Website anzulegen antwortet in Millisekunden, und diese Antwort bedeutet angenommen, nicht fertig. Die Datenbankzeile existiert; der virtuelle Host und das Dokumentenverzeichnis werden vom Server-Daemon asynchron angelegt.

Das Signal, auf das man wartet, ist der Zähler der Auftragswarteschlange für diesen Server, der gemessen auf einer ruhigen Maschine in etwa acht Sekunden von drei auf null fiel und bei einem früheren Lauf in etwa dreiundzwanzig Sekunden. Es ist ein globaler Zähler, keiner je Befehl. Auf einem ausgelasteten Server mit mehreren Mandanten kann er wegen der Aufträge anderer Kundschaft über null bleiben oder null erreichen, während Ihre Arbeit noch aussteht.

Die Regel lautet daher: eine Zeitgrenze mit einer wahrheitsgemäßen Meldung statt eines endlosen Wartens. Fragen Sie ab, bis die Warteschlange leer ist oder bis das Anlegebudget von 180 Sekunden abläuft, und melden Sie das Konto dann als angelegt, denn das ist es. „Die Website wird noch eingerichtet“ ist einer zahlenden Kundschaft lieber zu sagen als ein Ladekringel, der nie aufhört.

Löschen ist eine Datenschutzfrage, keine Aufräumfrage

Das ist der Teil dieses Artikels, den Sie behalten sollten, wenn Sie sonst nichts behalten, und es geht dabei eigentlich nicht um ISPConfig.

Der Löschpfad hatte einen Defekt, den keine Fixture sehen konnte: Er verglich zwei Felder, die nie gleich sind, der Zweig, der den besitzenden Client entfernte, war also toter Code. Jede Löschung ließ ein Panel-Login mit Namen, E-Mail-Adresse, Kontaktdaten und Passwort der Kundschaft zurück. Der Befehl antwortete ok, die Website war weg, der Zähler ging auf null, und die personenbezogenen Daten einer Person, die um ihren Weggang gebeten hatte, blieben auf dem Node.

Nichts oberhalb des Panels kann das sehen. Ein Aufräum-Worker und ein Datenauskunftsexport räumen unsere Seite auf; sie haben keinen Blick darauf, was auf Ihrem Hosting-Node übrig bleibt. Die Regel, die daraus entstanden ist, lohnt sich zu stehlen:

> Messen Sie einen Löschpfad an der Datenbank des Panels selbst und niemals an „der Befehl hat ok geliefert“.

Auf ISPConfig sind das vier Zählungen, und alle vier müssen null sein: Websites, Clients, System-Logins und das Client-Verzeichnis auf der Platte. Und messen Sie es mit dem Panel statt mit dem Aufräumhelfer Ihres eigenen Tests, denn der Helfer kann dasselbe Missverständnis tragen, und dann sieht die Maschine sauber aus, während die Anbindung leckt.

Die sichere Löschregel selbst ist eine Zeile: die Website entfernen; den besitzenden Client nur dann entfernen, wenn ihm keine Website mehr gehört. ISPConfig hat einen Aufruf, der einen Client und alles darunter löscht, und auf einem importierten Konto würde der die anderen Websites der Kundschaft mitnehmen. Löschen Sie nie mehr, als verlangt wurde.

Nichts geschieht sofort

Ihr Panel 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, denn ein Bestand oder eine Rechnung 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. Alles, was etwas anlegt, akzeptiert außerdem einen selbst gewählten Idempotency-Key, ein wiederholter Webhook und ein Doppelklick kosten Sie also nichts.

Wo die Rechnung liegt

Provibr stellt Ihrer Kundschaft 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, zu einem Stückpreis, der mit steigender Anzahl in Stufen fällt. Für ein Hosting-Konto gibt es kein „gestoppt“: Es gibt aktiv und gesperrt, und ein gesperrtes Konto zählt nicht. Die Mahnaktion, die Sie aus kaufmännischen Gründen ohnehin wollten, ist also zugleich die, die den Platz freigibt, für den Sie bezahlen.

Was nicht automatisiert ist

Provibr verwaltet Konten, nicht das Panel. Es installiert ISPConfig nicht, aktualisiert es nicht und rührt weder Postfächer noch Datenbanken noch DNS an: Wer sein eigenes Postfach löscht, tut das, ohne dass irgendetwas oberhalb des Panels es weiß oder sich darum kümmert. Für ein Hosting-Konto gibt es keine Konsole, keine Neuinstallation und keine teilweise Sperre.

Wenn Sie noch vor dem Abrechnungsteil stehen, ist das Begleitstück Webhosting mit ISPConfig verkaufen, das den Remote-Benutzer, die Zuschneidung und das Modell mit einem Panel und mehreren Servern behandelt. Die Zugangsdaten, das Zertifikat und der Paketbildschirm sind auf der ISPConfig-Dokumentationsseite beschrieben.