ISPConfig-facturatie automatiseren

ISPConfig heeft een commando voor elk moment waarop geld en machines elkaar raken: het account aanmaken, opschorten, naar een ander pakket verplaatsen, verwijderen. Wat het niet heeft is iets dat beslist wanneer je ze draait.

Die twee helften aan elkaar knopen is grotendeels gewoon werk. Twee dingen aan ISPConfig zijn niet gewoon, en allebei slopen ze stilletjes een eerste poging: de statuscode van een aanroep zegt helemaal niets, en een account is geen klant.

De statuscode zegt niets

Alles komt terug als HTTP 200. Validatiefouten, dat bestaat niet, een verkeerd wachtwoord, een methode die de remote gebruiker niet mag aanroepen: allemaal 200. Het oordeel staat in een code-veld in de JSON-body.

Classificeer op code en op de tekst, nooit op de status. De reden dat dit voor een facturatiekoppeling zwaarder telt dan voor wat dan ook is de pollronde: een client die 200 als succes behandelt leest een authenticatiefout als een geslaagde lege inventaris, en markeert daarna elk account van die klant als verdwenen. Eén verlopen sessie, en je afstemming verwijdert een hostingbedrijf.

Het message-veld komt in twee smaken, en het verschil is bruikbaar. Validatiefouten uit de formulierlaag van het paneel zijn een met <br> gescheiden lijst met vertaalsleutels, geen zinnen: domain_error_unique voor een domein dat al gehost wordt. Controles in de remote-bibliotheek zijn gewone Engelse zinnen: Invalid client_id 99999. Match op de sleutels, citeer de zinnen.

Eén account is één website, geen klant

ISPConfig scheidt twee dingen die de meeste controlepanelen samensmelten. Een client is een paneellogin met limieten voor het hele account. Een web_domain is één gehoste site. Eén client kan meerdere websites bezitten.

Een Provibr-hostingaccount is één website, herkenbaar aan zijn domein. Er een aanmaken vraagt dus om een eigenaar, dus de agent maakt een verse client aan met een website eronder, en leidt de clientlogin af uit het domein zodat hij de eigenaar altijd terug kan vinden.

Die keuze is wat het verwijderpad veilig maakt, en het verwijderpad is waar deze koppeling bijna misging. Verderop meer daarover.

De levenscyclus, in kaart

Opschorten is idempotent in beide richtingen

Opschorten klapt de active-vlag van de website tussen y en n. Er zijn geen bitmaskers en geen halve standen: een site staat aan of hij staat uit.

Een tweede opschorting op een al opgeschorte site antwoordt code: ok met een response van 0, wat betekent dat er nul rijen wijzigden. Dat is geen fout, en een aanmaanronde die alles opschort wat te laat is, inclusief wat ze gisteren opschortte, hoeft zich nergens voor te verontschuldigen. Het is de moeite waard om te beseffen hoe zeldzaam dat is: op HestiaCP is diezelfde tweede opschorting een HTTP 401, niet te onderscheiden van een verkeerd geheim, op een paneel dat je adres blokkeert na vijf geweigerde aanmeldingen (zie HestiaCP-facturatie en -provisioning automatiseren).

Eén ding om van te weten, ook al gebruikt de koppeling het niet: ISPConfig heeft ook een slot op clientniveau, en dat zetten klapt elke website van die client in één keer op inactief. Een klant die zichzelf in het paneel op slot zet, of een resellerslot erboven, komt daardoor in de pollronde als opgeschort naar boven. Dat klopt, en het is niet iets wat je facturatiesysteem gedaan heeft.

Van pakket wisselen is hier een echte actie

Een ISPConfig-pakket is een klanttemplate: een benoemde set limieten, in het paneel gebouwd door een beheerder. De remote API kan er geen aanmaken, en dat is prima, want een plan hoort naar een pakket te verwijzen in plaats van er een te verzinnen. Provibr geeft de pakketnaam door en de agent zoekt het template-id op.

Daarmee is ISPConfig een van de controlepanelen waar een planwijziging werkelijk een planwijziging is. CloudPanel en CyberPanel moeten hem ronduit weigeren; hier gebeurt hij en verschuiven de limieten meteen.

Twee gemeten waarschuwingen als je dit zelf schrijft. Stuur een minimale update, met niets anders erin dan de nieuwe template: een update met het hele clientrecord kwam terug als remote_fault zonder bruikbare melding, en dat gold ook voor een die een expliciete template met expliciete limieten combineerde. En weet dat de template limieten die je ook meestuurt overschrijft, wat de goede volgorde is maar mensen de eerste keer verrast.

Het klaar-signaal geldt voor de hele server

Een website aanmaken antwoordt in milliseconden, en dat antwoord betekent aangenomen, niet klaar. De databaserij bestaat; de virtual host en de documentroot worden asynchroon door de serverdaemon neergezet.

Het signaal om op te wachten is de taakwachtrijteller van die server, waarvan gemeten is dat hij op een rustige machine in ongeveer acht seconden van drie naar nul zakte, en in een eerdere ronde in ongeveer drieëntwintig seconden. Het is een globale teller, geen teller per commando. Op een drukke server met meerdere klanten kan hij boven nul blijven door taken van andere klanten, of nul bereiken terwijl jouw werk nog openstaat.

De regel is dus een timeout met een eerlijke melding in plaats van eindeloos wachten: poll tot de wachtrij leeg is of tot het aanmaakbudget van 180 seconden op is, en meld het account daarna als aangemaakt, want dat is het. De site wordt nog ingericht is een betere mededeling aan een betalende klant dan een spinner die nooit stopt.

Verwijderen is een privacyvraag, geen opruimvraag

Dit is het deel van dit artikel dat je moet onthouden als je niets anders onthoudt, en het gaat eigenlijk niet over ISPConfig.

Het verwijderpad had een defect dat geen enkele fixture kon zien: het vergeleek twee velden die in werkelijkheid nooit gelijk zijn, dus de tak die de bezittende client verwijderde was dode code. Elke verwijdering liet een paneellogin achter met de naam, het e-mailadres, de contactgegevens en het wachtwoord van de klant. Het commando antwoordde ok, de website was weg, de teller ging naar nul, en de persoonsgegevens van iemand die had gevraagd om te vertrekken bleven op de node staan.

Niets boven het paneel kan dat zien. Een opruimworker en een AVG-export ruimen onze kant op; ze hebben geen zicht op wat er op jouw hostingnode achterblijft. De regel die eruit voortkwam is het stelen waard:

> Meet een verwijderpad tegen de database van het paneel zelf, en nooit tegen het commando antwoordde ok.

Op ISPConfig zijn dat vier tellingen, en alle vier moeten ze nul zijn: websites, clients, systeemlogins, en de clientmap op schijf. En meet met het paneel in plaats van met de opruimhelper van je eigen test, want die helper kan hetzelfde misverstand dragen en dan ziet de machine er schoon uit terwijl de koppeling lekt.

De veilige verwijderregel zelf is één regel: verwijder de website; verwijder de bezittende client alleen als er geen websites meer onder hangen. ISPConfig heeft een aanroep die een client verwijdert met alles eronder, en op een geïmporteerd account zou die de andere sites van de klant meenemen. Verwijder nooit meer dan er gevraagd is.

Niets is meteen klaar

Je paneel is alleen bereikbaar via de agent in je eigen netwerk, en die agent verbindt uitgaand, dus een endpoint dat een account wijzigt kan niet met het resultaat antwoorden. Het antwoordt dat de opdracht is aangenomen en geeft je een commando om te volgen tot de status definitief is: klaar, mislukt, verlopen of geannuleerd. Lezen werkt nooit zo, want een inventaris of een factuur komt uit een database en niet van jouw host.

Het praktische gevolg voor een facturatiehook: markeer de bestelling niet als afgerond op het aangenomen-antwoord. Alles wat iets aanmaakt accepteert ook een idempotentiesleutel van je eigen makelij, dus een herhaalde webhook en een dubbele klik kosten je niets.

Waar de factuur staat

Provibr factureert jouw klanten niet, maant ze niet aan, en weet niet wat je ze in rekening brengt. Die relatie is van jou.

Wat Provibr factureert is de capaciteit die je reserveert: hoeveel hostingaccounts je tegelijk mag draaien, tegen een stuksprijs die in staffels daalt naarmate het aantal stijgt. Voor een hostingaccount bestaat er geen gestopt: er is actief en opgeschort, en een opgeschort account telt niet mee. De aanmaanactie die je om commerciële redenen toch al wilde is dus ook degene die de plek vrijmaakt waarvoor je betaalt.

Wat niet geautomatiseerd is

Provibr beheert accounts, niet het paneel. Het installeert ISPConfig niet, werkt het niet bij, en raakt mailboxen, databases en DNS niet aan: een klant die zijn eigen mailbox verwijdert doet dat zonder dat iets erboven het weet of erom geeft. Er is geen console voor een hostingaccount, geen herinstallatie, en geen gedeeltelijke opschorting.

Zit je hier nog vóór het facturatiedeel, dan is het bijbehorende stuk Webhosting verkopen met ISPConfig, dat de remote gebruiker, de scoping en het model van één paneel met meerdere servers behandelt. De inloggegevens, het certificaat en het pakketscherm staan op de documentatiepagina van ISPConfig.