Facturatie automatiseren met Virtualmin

Twee vragen bepalen of een hostingpaneel betalende klanten kan dragen: wordt een bestelling een werkend account zonder dat jij er iets aan doet, en verandert een onbetaalde factuur werkelijk iets op de server.

Deze pagina beantwoordt allebei voor Virtualmin, in het concrete: welk Virtualmin-commando achter elke stap zit, wat waar wordt opgeslagen, en waar de automatisering bewust stopt. Alles is gemeten tegen een echte installatie van Virtualmin GPL 8.1.2.

Van bestelling naar account

Een bestelling heeft vier dingen nodig: een domein, een e-mailadres, een plan en een wachtwoord.

Het plan is de interessante. Een Provibr-webplan pint precies één Virtualmin-plan vast op precies één integratie en geeft het een eigen naam. Die tussenstap bestaat omdat een Virtualmin-plan de eigen beschrijving van het paneel is (schijfquotum, maandelijks verkeer, aantallen mailboxen en domeinen, welke features aan staan) en de inhoud daarvan kan op jouw machine veranderen zonder dat wij het horen. We verwijzen er dus naar op naam en lezen terug wat er werkelijk gebeurd is, in plaats van te bewaren wat we denken dat het betekent.

Achter de schermen draait de bestelling create-domain op het paneel, met het domein, het plan en het wachtwoord. Verder:

Twee details van de aanmaakstap zijn het weten waard.

De unix-gebruiker komt uit het domein. mijn-klant.nl wordt mijn-klant. Koppeltekens zijn hier de normale vorm, en het plafond is dat van Linux zelf: 32 tekens. Dat is anders dan bij DirectAdmin en cPanel, die hun eigen strengere naamgeving opleggen. Je kiest de gebruikersnaam niet; het paneel leidt hem af.

Het wachtwoord wordt nooit vastgelegd. Provibr bewaart het feit dát je er een gaf, niet de waarde. Het wachtwoord reist gescheiden van het auditspoor dat de bestelling vastlegt, dus een wachtwoord van een hostingaccount bestaat nergens in de geschiedenis van het platform. Raak je het kwijt, dan zet je een nieuw; je zoekt het niet op.

Wat waar wordt opgeslagen

Een hostingaccount wordt een gewone serverrij van het type webserver. De identiteit is het interne nummer dat Virtualmin aan het domein geeft, niet de naam.

Die keuze is bewust en ze doet ertoe voor facturatie. Virtualmin kan een domein hernoemen, en een klant of beheerder doet dat vroeg of laat. Een sleutel op naam raakt los van zijn rij zodra dat gebeurt: je factuur blijft dan iets rekenen dat het platform niet meer terugvindt. Een numerieke id overleeft de hernoeming.

De accountgrens is de unix-gebruiker, niet het domein. Sub-servers en aliassen onder één account zouden anders elk als apart hostingaccount in de capaciteitstelling landen, en dan betaal je licentiecapaciteit voor aliassen.

⚠️ Hier zit een vertaalstap die makkelijk misgaat als je dit zelf bouwt. De mutatieprogramma's van Virtualmin (disable-domain, enable-domain, modify-domain) nemen alleen --domain als selector. Dat is gemeten op 8.1.2: er is geen --user-selector. Maar het platform adresseert accounts op gebruikersnaam, want dát is de identiteit van het account. Die vertaalslag hoort bij de agent, die één gescopete opzoeking op het paneel doet om het huidige domein te bepalen, en niet bij het platform, dat dan een kopie van jouw domeinnamen zou moeten bijhouden en bij de eerste hernoeming buiten Provibr om stilzwijgend het verkeerde domein zou aansturen.

(Verwante valkuil: modify-domain --user betekent hernoemen, niet selecteren. Die vlag wordt nooit verstuurd.)

Het capaciteitsmodel, in één alinea

Je koopt capaciteit per resourcetype (virtuele machines, dedicated machines, hostingaccounts, gameservers) en dat is tegelijk een limiet en een prijs. Elk account telt mee, of het nu draait of niet. Alleen een opgeschort account niet, en een verwijderd evenmin. Iets stopzetten geeft dus geen plek vrij: verwijder het, of verhoog je capaciteit. Verhogen gaat direct in en het meerdere over de rest van de periode wordt naar rato op je volgende factuur gezet; verlagen gaat óók direct in, en het ongebruikte deel komt terug als tegoed.

Geïmporteerde accounts tellen precies zoals bestelde. Een paneel vol bestaande klanten overnemen is een capaciteitsbeslissing, geen gratis handeling.

Wat een onbetaalde factuur doet

Je organisatie draagt één licentiestatus: actief, respijt of opgeschort. Twee losse dingen kunnen die verschuiven (een openstaande betaling en een overschrijding), en als ze allebei gelden wint de strengste, zodat de banner niet tussen twee verhalen heen en weer springt.

De proefperiode laat de vorm het duidelijkst zien. Een nieuwe organisatie draait twee weken op proef, zonder dat er om betaalgegevens gevraagd wordt en met alles werkend. Loopt die af zonder betaalmethode, dan word je dat verteld en verandert er nog niets. Een week later begint het paneel te waarschuwen. Twee weken na het einde van de periode worden servers opgeschort. Elke stap wordt aangekondigd voordat hij plaatsvindt: dat is de regel waar het hele schema omheen gebouwd is, niet een beleefdheid die er later opgeplakt is.

Bij een lopend abonnement is het mechanisme hetzelfde: de status gaat eerst naar respijt en pas daarna naar opgeschort, de banner noemt de oorzaak, en de oplossing staat eraan gelinkt. Een opschorting wegens betaling en een opschorting wegens capaciteit zien er anders uit en lezen anders, omdat ze iets anders van je vragen.

Wat opschorten op het paneel doet

Als het platform een hostingaccount opschort, stuurt het disable-domain. Virtualmin zet het wachtwoord van de beheergebruiker op slot en vervangt de website door een foutpagina. De data blijft staan.

Drie eigenschappen van die stroom zijn het uitschrijven waard, want ze scheiden een echte automatisering van een script dat erop lijkt.

De rij wordt pas op opgeschort gezet als de agent bevestigt. Een commando versturen is niet hetzelfde als dat het gebeurd is. Zou het platform de rij bij het versturen markeren, dan zou een mislukte opschorting een draaiend account laten meetellen als "telt niet mee voor je limiet", precies de boekhoudfout die de handhaving moet voorkomen.

Een offline agent betekent uitgesteld, niet klaar. Is de agent onbereikbaar, dan wordt de handhaving overgeslagen, wordt er een gebeurtenis vastgelegd die dat zegt, en probeert de volgende ronde het opnieuw. Er wordt niets stilletjes als afgerond gemarkeerd.

De uitkomst lezen is een verse uitlezing, niet het antwoord van het commando zelf. disable-domain geeft een muur voortgangstekst terug ("Locking administration user's password ..", "Replacing website with error page ..") en die tekst is een citaat, geen contract. De stand komt uit een verse list-domains erna. Dat is een huisregel over elk paneel dat we koppelen: geen enkele mutatie wordt op zijn eigen antwoord vertrouwd.

Die laatste regel is wat de opschortdetectie überhaupt juist maakt, en dit is de gemeten reden. Bij een opgeschort account krijgt list-domains er een veld disabled bij. Bij een actief account ontbreekt dat veld gewoon: er is geen disabled: "No". Een parser die op een waarde zoekt vindt niets en leest élk account als actief, ook de opgeschorte. In een facturatiecontext is dat niet cosmetisch: een account dat je wegens niet-betalen opschortte rapporteert zichzelf als live, en je capaciteitstelling staat fout in de richting die je geld kost.

Boven je limiet uitkomen

Meer accounts draaien dan je gekocht hebt wordt niet geblokkeerd op het moment dat je het doet. Het wordt gedetecteerd, je krijgt het te horen, en je krijgt tijd.

1. 01De overschrijding wordt gedetecteerd. Je krijgt een melding en een banner die het resourcetype noemt en met hoeveel je eroverheen zit.
2. 02Je hebt een volle werkdag om het op te lossen: accounts verwijderen, of je capaciteit verhogen.
3. 03Verloopt de respijtperiode, dan schort het platform de nieuwste accounts boven je limiet op. Nieuwste eerst, zodat wat je het langst geleden opbouwde blijft staan. Een opgeschort account houdt zijn schijf en zijn data.
4. 04Zodra je weer binnen je limiet zit sluit de overschrijding.

Een tweede overschrijding binnen een week krijgt een uur in plaats van een dag. Zonder dat zou de respijtperiode eindeloos te verversen zijn door even onder de limiet te duiken en er weer overheen te gaan.

⚠️ Er wordt niets voor je gestart als de overschrijding is opgelost. Een account weer aanzetten is een beslissing, en het platform neemt die niet terwijl er niemand kijkt. Je hervat hem zelf, en dat stuurt enable-domain.

Achter stap 4 zit een klein stukje rekenwerk dat makkelijk omgedraaid wordt. De overschrijding geldt pas als opgelost wanneer accounts die meetellen plus accounts die door déze overschrijding zijn opgeschort weer binnen de limiet vallen, niet alleen dat eerste getal. Zonder die optelling zou de handhaving zichzelf op het moment van handelen meteen opgelost verklaren, want de telling zakt juist ónder de limiet dóór het opschorten.

Wat nooit automatisch gebeurt

Verwijderen. Geen onbetaalde factuur, geen overschrijding en geen verlopen proefperiode verwijdert een hostingaccount. Opschorten houdt de schijf en de data; verwijderen is een aparte, uitdrukkelijke handeling die jij doet. De enige destructieve stap in de levenscyclus is precies de stap die het platform niet namens jou zet.

Gedeeltelijk verrekenen met tegoed. Je kunt vooruit opwaarderen, en het saldo is een grootboek: één regel per mutatie, nooit bewerkt, correcties zijn tegenboekingen met een reden in plaats van herschrijvingen. Dekt het saldo de hele maand, dan wordt de maand uit tegoed betaald en wordt er niets geïncasseerd. Dekt het die niet, dan wordt het volledige bedrag geïncasseerd en blijft het saldo staan. Half-om-half bestaat niet.

Geschiedenis herschrijven. Een factuurregel legt de plannaam vast zoals die op het moment van factureren was. Iets later hernoemen verandert niet wat er op een oude factuur staat.

Wat dit betekent

Virtualmin geeft je een degelijk hostingpaneel en helemaal geen commerciële laag. Het gat is niet het provisionen (create-domain is één commando), het is alles eromheen: tellen wat een klant heeft, weten dat een factuur onbetaald bleef, daar iets omkeerbaars aan doen, en achteraf kunnen uitleggen wat er wanneer gebeurd is.

Provibr koppelt aan controlepanelen, hypervisors en gamepanelen naast elkaar. Het facturatiemodel hierboven is over al die panelen hetzelfde, en dat is het praktische argument voor een kleine hoster: de Virtualmin-machine die je al draait blijft precies werken zoals hij werkt, en de VPS of het gamepaneel dat je er volgend jaar bij zet landt in dezelfde capaciteitstelling, dezelfde factuur en dezelfde opschortstroom.