Săriți la conținut

Blog ·

Modulul WHMCS pentru CyberPanel și alternativa

Ce poate și ce nu poate un modul WHMCS pentru CyberPanel, fiindcă API-ul lui fixează plafonul. Limite măsurate și un strat de aprovizionare deasupra.

De Provibr

Dacă rulați WHMCS și vreți să vindeți găzduire OpenLiteSpeed, mergeți în căutarea unui modul de aprovizionare pentru CyberPanel. Măsurat pe 21 august 2026, rezultatele acelei căutări sunt un depozit GitHub întreținut de o persoană și un fir de forum comunitar.

Aceasta nu este o critică a muncii nimănui. Este descrierea unui gol: o bucată de software care se așază între facturile dumneavoastră și site-urile clienților dumneavoastră și pe care majoritatea gazdelor o găsesc ca proiect secundar, nu ca produs.

Această pagină este despre ce poate face un asemenea modul, ce nu poate face structural și cum arată o formă diferită de soluție. Prima parte contează cel mai mult, pentru că plafonul nu este modulul. Este API-ul CyberPanel.

Plafonul: ce permite API-ul CyberPanel

Măsurat față de CyberPanel 3.0, nu citit din documentație. Orice modul (cel de pe GitHub, unul pe care îl scrieți dumneavoastră înșivă sau cel descris mai jos) este mărginit de toate acestea.

Crearea unui site răspunde înainte să știe rezultatul

createWebsite revine în aproximativ trei secunde cu createWebSiteStatus: 1. Acela nu este un verdict; înseamnă că munca a început. Endpointul pornește o comandă în fundal și revine imediat. Progresul real se află într-un fișier de stare care trebuie interogat separat.

Măsurat cu date introduse greșit intenționat:

CazRăspunsul HTTPCe s-a întâmplat de fapt
Domeniu deja existentcreateWebSiteStatus: 1 (succes)This website already exists. [404]
Pachet necunoscutcreateWebSiteStatus: 1 (succes)Package matching query does not exist. [404]
Domeniu invalidcreateWebSiteStatus: 0refuzat imediat

Doar forma domeniului și a adresei de e-mail este validată din start. Un modul care se încrede în primul răspuns va marca o comandă WHMCS ca activă pentru un site care nu a fost creat niciodată, iar clientul primește date de autentificare de bun venit pentru ceva ce nu există.

Sondarea acelui fișier de stare are încă două capcane. Citirea unei stări finalizate o șterge, așa că o sondare în plus transformă o creare încheiată într-un „încă se lucrează” permanent. Iar apelul de stare se află pe partea din API-ul CyberPanel care refuză orice administrator ce nu se numește literalmente admin.

Întreaga creare durează aproximativ cincizeci de secunde, dintre care aproape douăzeci și opt sunt o încercare de SSL pe care CyberPanel o face necondiționat. API-ul suprascrie acel indicator, indiferent ce trimiteți. Orice modul are nevoie de un timp de expirare care să o acomodeze.

Schimbarea pachetului schimbă un câmp din baza de date

changePackageAPI revine în aproximativ 270 de milisecunde, iar panoul afișează noul nume. Măsurat ulterior din interiorul serverului, cu un pachet care purta alte limite: cota de disc era neschimbată (soft 0, hard 0) și configurația vhost purta încă limitele de memorie și de procese ale pachetului vechi.

Nu s-a aplicat nimic. Așadar, o comandă de upgrade din WHMCS se poate încheia, poate factura și poate schimba numele în panou, în timp ce limitele reale ale clientului sunt exact ce erau. Niciun modul nu poate repara asta. Întreaga implementare a endpointului este o modificare de câmp.

Suspendarea nu blochează contul

CyberPanel suspendă un site rescriindu-i configurația vhost către o pagină de suspendare și repornind serverul web. Utilizatorul unix nu este blocat; FTP-ul, e-mailul și bazele de date continuă să funcționeze. Dacă suspendați pentru neplată, clientul dumneavoastră tot are e-mailul și baza sa de date. S-ar putea să fie exact ce vreți, dar ar trebui să fie o decizie, nu o surpriză.

Există și o muchie mai ascuțită: implementarea este if state == "Suspend": … else: <reluare>, fără nicio validare. Măsurat: trimiterea lui "suspend" cu literă mică a reactivat un site suspendat și a raportat succes. Orice modul ar trebui să păstreze acele două valori drept constante, niciodată să le asambleze dintr-o variabilă.

Nu există date de consum

Traficul este calculat de CyberPanel și apoi aruncat înainte să ajungă la vreo listă. Consumul de disc provine dintr-un cache de pe înregistrarea site-ului, care este gol pe un site nou, așa că valoarea revine la zero, iar un zero dintr-un cache gol nu se poate distinge de un site care nu consumă nimic.

WHMCS are un hook de colectare a consumului care așteaptă cifre de disc și de trafic. Pe CyberPanel nu există nimic onest de pus în el: un modul care îl umple totuși raportează o valoare implicită, nu o măsurătoare.

Accesul la API este dezactivat, iar ordinea verificării ascunde de ce

Pe un CyberPanel proaspăt instalat, API-ul este dezactivat, inclusiv pentru administratorul principal, iar indicatorul este verificat înainte de parolă, așa că, atâta timp cât este dezactivat, o parolă corectă și una greșită returnează identicul API Access Disabled. Eșecul de la prima rulare al fiecărui modul pentru acest panou arată ca o problemă de date de autentificare și nu este.

Ce înseamnă asta pentru un modul

Nimic din cele de mai sus nu se poate repara în interiorul unui modul WHMCS, pentru că nimic din asta nu este o problemă a modulului. Ce diferă între module este cât de onest o tratează:

  • Sondează starea creării sau se încrede în primul răspuns?
  • Citește starea o singură dată și consemnează rezultatul, sau sondează până șterge din greșeală rezultatul?
  • Vă spune că o schimbare de pachet nu a aplicat nimic?
  • Lasă hookul de consum gol, sau îl umple cu zerouri care arată ca date?
  • Spune „accesul la API este dezactivat” în loc de „date de autentificare invalide”?

Acestea sunt întrebările de pus oricărui modul pe care îl aveți în vedere. Se răspunde la ele citind codul și contează mai mult decât lista de funcții. Mai este una, despre dumneavoastră și nu despre cod: cine îl întreține peste optsprezece luni? Un modul de aprovizionare se află pe calea critică a fiecărei comenzi pe care o primiți.

Alternativa: un strat de aprovizionare, nu un modul de panou

Provibr se așază între sistemul dumneavoastră de facturare și infrastructura dumneavoastră. Nu este un modul WHMCS pentru CyberPanel; este o platformă de aprovizionare care vorbește cu CyberPanel și cu care WHMCS comunică printr-un singur modul, indiferent de ce se află dedesubt.

Diferența practică:

Un modul WHMCS pentru CyberPanelProvibr
Panouri acoperiteCyberPanelPanouri de control, hipervizoare și panouri de joc, inclusiv CyberPanel
Integrare WHMCSacest modulun singur modul pentru toate
Facturare non-WHMCSscrieți alt modulAPI REST
AccesibilitateWHMCS trebuie să ajungă la panouagentul inițiază conexiunea spre exterior; nimic expus
Stocarea credențialelorîn baza de date WHMCSîntr-un seif al agentului pe propria dumneavoastră gazdă
Rezultatul creăriidepinde de modulsondează starea reală
Grafice de consum pe CyberPanelniciunul disponibilniciunul, și spune asta
Schimbarea pachetului pe CyberPanelnu aplică nimicnu aplică nimic, și spune asta
Costgratuitper cont de găzduire administrat, pe lună
DNS, e-mail, baze de datepanoupanou
Cine îl întreținevariazăo companie care îl vinde

Două rânduri merită dezvoltate, pentru că sunt cele oneste.

Cost. Modulul este gratuit, iar Provibr nu este. Provibr percepe pentru capacitatea pe care o rezervați (câte conturi de găzduire aveți voie să rulați în același timp) la un preț unitar pe paliere care scade pe măsură ce numărul crește. Ceea ce le percepeți dumneavoastră propriilor clienți rămâne în întregime al dumneavoastră. Dacă aveți douăsprezece site-uri CyberPanel și niciun plan de creștere, un modul gratuit este răspunsul corect.

Aceleași limite, altă onestitate. Provibr nu repară schimbarea de pachet a CyberPanel, nu inventează cifre de consum și nu blochează un cont suspendat. Nu poate: acelea sunt proprietăți ale panoului. Ce face este să refuze să pretindă altceva.

Cum se potrivește în WHMCS

Un singur modul, instalat ca un simplu fișier zip în modules/servers/. În WHMCS adăugați un server care indică spre Provibr cu o cheie de API, apoi îndreptați un produs WHMCS către un plan de găzduire web Provibr. O comandă plătită creează contul, o suspendare îl suspendă, o reziliere îl elimină. Clientul dumneavoastră păstrează un singur cont, o singură factură și o singură autentificare.

Cheia de API poartă domenii de acces, iar ceea ce poate face de fapt este intersecția dintre acele domenii și permisiunile membrului căruia îi aparține, așa că o cheie nu poate decât să restrângă accesul, niciodată să îl lărgească. Retrageți o permisiune unui coleg și fiecare cheie a lui devine mai restrânsă la următoarea cerere, fără ca nimeni să revoce ceva.

Dacă nu rulați WHMCS, aceleași operațiuni sunt disponibile prin API-ul REST: o cheie, o adresă de bază. Tot ce atinge o mașină răspunde „acceptat” cu o comandă de urmărit, pentru că infrastructura dumneavoastră este accesibilă doar prin agentul din interiorul propriei rețele. Citirile răspund imediat.

Când modulul este alegerea mai bună

Ca să fim direcți: dacă CyberPanel este singurul panou pe care îl rulați, aveți deja WHMCS, volumul dumneavoastră este mic și vă simțiți confortabil să citiți PHP când ceva se strică, un modul înseamnă mai puțină mașinărie și niciun cost lunar. Limitele din partea de sus a acestei pagini se aplică ambelor opțiuni în egală măsură.

Argumentul pentru un strat deasupra lui începe atunci când rulați mai mult de un panou, când vreți credențialele departe de gazda dumneavoastră WHMCS, când altceva decât WHMCS trebuie să plaseze comenzi, sau când vreți ca acea cale de aprovizionare să fie produsul cuiva, nu weekendul cuiva.

Provibr rulează astăzi panourile sale de control, hipervizoarele și panourile de joc unele lângă altele, într-un singur inventar, sub un singur model de permisiuni, cu un singur jurnal de activitate. Nu trebuie să alegeți între CyberPanel și tot restul.

Întrebări frecvente

Există un modul CyberPanel oficial pentru WHMCS?

Măsurat pe 21 august 2026, căutarea aceea returna un depozit GitHub întreținut de o singură persoană și un fir de forum. Asta descrie un gol, nu este o critică la adresa muncii cuiva.

De ce raportează modulul succes pentru un site care nu a fost creat niciodată?

Pentru că createWebsite răspunde înainte de a cunoaște rezultatul. Un domeniu care există deja și un pachet necunoscut se întorc amândouă ca createWebSiteStatus: 1, iar asta înseamnă că lucrarea a început, nu că a reușit. În avans se validează doar forma domeniului și a adresei de e-mail.

Schimbarea pachetului pe CyberPanel aplică ceva cu adevărat?

Nu. Măsurat pe CyberPanel 3.0, changePackageAPI răspunde în circa 270 de milisecunde și panoul arată numele nou, în timp ce cota de disc și limitele vhost rămân neschimbate. Întreaga implementare a acelui endpoint este o modificare de câmp, iar niciun modul nu poate repara asta.

De ce o parolă corectă dă „API Access Disabled”?

Pentru că pe un CyberPanel proaspăt instalat API-ul este oprit, inclusiv pentru administratorul principal, iar indicatorul este verificat înaintea parolei. O parolă corectă și una greșită întorc același răspuns, așa că primul eșec al oricărui modul pentru acest panou pare o problemă de acreditări și nu este.

Modul sau strat de aprovizionare?

Dacă CyberPanel este singurul panou folosit, WHMCS există deja și volumul este mic, un modul înseamnă mai puțină mașinărie și niciun cost lunar. Un strat deasupra începe să merite când există mai mult de un panou, când acreditările trebuie să plece de pe gazda WHMCS, sau când altceva decât WHMCS trebuie să plaseze comenzi.

Începeți cu o gazdă și un agent

Creați un cont, instalați agentul cu o singură comandă și conectați primul dumneavoastră host Proxmox. Perioada de probă durează 14 zile și nu cere date de plată.