Blog ·
Cum să vindeți găzduire web cu CyberPanel
CyberPanel are un API, dar crearea unui site raportează succes înainte să știe. Ce returnează cu adevărat API-ul, capcanele și cum construiți pe el.
De Provibr
CyberPanel este panoul pe care furnizorii de găzduire care rulează OpenLiteSpeed îl numesc cel mai des alături de DirectAdmin. Măsurat pe GitHub la 21 august 2026: 2.007 stele, 723 de bifurcări și 362 de probleme deschise, cu un ritm de lansare mai lent decât majoritatea omologilor săi.
Are un API REST, și tot ce vă trebuie pentru a vinde găzduire pe el (a crea un site, a-l suspenda, a-i schimba pachetul, a-l șterge) face parte din acel API. Ce nu are este ceva care să decidă când să facă aceste lucruri, iar ce are într-adevăr este un set de răspunsuri ușor de citit greșit.
Înainte de toate: accesul la API este dezactivat
Pe un CyberPanel proaspăt instalat, API-ul este dezactivat, iar asta este valabil și pentru administratorul dumneavoastră principal. Îl activați din Users → API Access, pentru utilizatorul admin. Nu este nevoie de nimic altceva; vă conectați cu datele de autentificare pe care le aveți deja.
Lăsați-l dezactivat și fiecare apel revine cu API Access Disabled., indiferent ce trimiteți. Ce vă costă o după-amiază este ordinea: CyberPanel verifică acest indicator înainte de a verifica parola, așa că, atâta timp cât este dezactivat, o parolă corectă și una greșită returnează același 403. Totul indică datele dumneavoastră de autentificare, în timp ce problema se află o casetă de bifat mai încolo.
Odată ce indicatorul este activat, contractul de dedesubt este curat și cu adevărat util:
parolă corectă → HTTP 200 {"verifyConn": 1}
parolă greșită → HTTP 401 {"verifyConn": 0, "error_message": "Invalid password."}
utilizator necunoscut → HTTP 404 {"error_message": "Administrator not found."}Trei situații, trei acțiuni diferite pentru client, toate trei distingibile.
Administratorul trebuie să se numească admin
Nu o setare, ci o condiție, și vine de la CyberPanel, nu de la ceva construit deasupra sa. O parte din API-ul său este păzită de o verificare literală a numelui, care refuză orice utilizator în afară de admin, iar acea parte este tocmai cea care enumeră site-urile din panou și raportează cât de departe a ajuns unul nou.
Ambele sunt inevitabile dacă vreți să vindeți găzduire pe el: aveți nevoie de listă pentru a ști ce există și de raportarea progresului din motivul expus în secțiunea următoare. Un administrator redenumit nu poate fi folosit, iar orice construiți ar trebui să spună asta în timpul testului de conexiune, înainte ca prima dumneavoastră comandă să o afle în locul dumneavoastră.
Un cont este un domeniu, nu un nume de utilizator
Aceasta este diferența structurală față de DirectAdmin, cPanel și Virtualmin, și schimbă felul în care modelați produsul.
Înregistrarea de site a CyberPanel are un câmp domain unic, iar fiecare comandă îl vizează: ștergerea preia domainName, suspendarea și schimbarea pachetului preiau websiteName, iar toate trei caută site-ul după domeniu. Nu există niciun nume de utilizator de adresat. Utilizatorul unix este generat, nu ales: cinci litere extrase din domeniu plus patru cifre aleatorii. Măsurat pentru provibr-test-1.example.com: provi7346, cu directorul personal numit după domeniu, nu după utilizator. Nu puteți alege acel nume, nu îl puteți prezice și apare în exact un răspuns de API și în nicio enumerare.
O consecință merită cunoscută înainte de al o sutălea cont al dumneavoastră: crearea unui site creează dedesubt și un cont de autentificare în panou, cu accesul la API activat, iar acel cont supraviețuiește ștergerii site-ului. Măsurat după o ștergere: utilizatorul unix dispărut, directorul personal dispărut, vhost dispărut, rândul din baza de date dispărut; contul de autentificare al proprietarului tot acolo. Calea de curățare a CyberPanel este păzită de o verificare care nu poate reuși în momentul în care rulează, iar eroarea rezultată este înghițită. Dacă nimic aflat deasupra panoului nu îl elimină, fiecare client reziliat lasă în urmă un cont de autentificare.
Crearea unui site raportează succes înainte să știe
Acesta este cel mai important lucru de înțeles despre API-ul CyberPanel.
createWebsite răspunde în aproximativ trei secunde cu:
{"status": 1, "createWebSiteStatus": 1, "error_message": "None",
"tempStatusPath": "/home/cyberpanel/2424", "LinuxUser": "provi7346"}Asta sosește înainte ca cea mai mare parte a muncii să fi avut loc: endpointul construiește o linie de comandă, o pornește fără să aștepte și revine. Progresul real se află într-un fișier de stare, care se citește printr-un apel separat. Măsurat, o creare reală:
+ 2,8s 10% Creating DNS records..
+ 4,8s 25% Setting up directories..
+ 6,9s 70% Setting up SSL.. ← rămâne aici 28 de secunde
+35,3s 80% Creating mail child domain..
+49,5s 100% Website successfully created. [200]Aproximativ cincizeci de secunde, dintre care aproape douăzeci și opt sunt o încercare de SSL pe care panoul o face oricum: API-ul suprascrie acel câmp necondiționat, așa că nu există nicio modalitate de a crea un site fără SSL. Pe un domeniu care nu se rezolvă încă public, asta înseamnă douăzeci și opt de secunde de așteptare pentru un certificat care nu va sosi.
Iar primul răspuns nu este un verdict. Măsurat cu date introduse greșit intenționat:
| Caz | Răspunsul HTTP | Ce s-a întâmplat de fapt |
|---|---|---|
| Domeniu deja existent | createWebSiteStatus: 1 (succes) | This website already exists. [404] în fișierul de stare |
| Pachet necunoscut | createWebSiteStatus: 1 (succes) | Package matching query does not exist. [404] |
| Domeniu invalid | createWebSiteStatus: 0, "Invalid domain." | refuzat din start |
| E-mail invalid | createWebSiteStatus: 0, "Invalid email." | refuzat din start |
Doar forma domeniului și a adresei este verificată imediat. Dacă domeniul este liber și dacă pachetul există se vede abia în fișierul de stare. O integrare care se încrede în primul răspuns va raporta o comandă reușită pentru un domeniu care era deja luat.
Două detalii fac sondarea mai grea decât pare. Citirea unei stări finalizate șterge fișierul, așa că o a doua sondare returnează „fișier inexistent” cu un indicator „neterminat”. Un client care sondează o dată în plus vede la nesfârșit „încă se lucrează” pentru o creare care a reușit. Iar apelul de stare există doar pe suprafața accesibilă exclusiv lui admin, motiv pentru care cerința privind numele admin de mai sus nu este opțională.
Suspendarea este un truc de server web, nu o blocare de cont
Suspendarea și reluarea sunt partea cuminte a acestui API: ambele produc efect imediat, iar lista proprie a panoului afișează pe loc noua stare.
Dar să știți ce face. CyberPanel rescrie configurația vhost a site-ului către o pagină de suspendare și repornește serverul web. Utilizatorul unix nu este blocat; FTP-ul, e-mailul și bazele de date continuă să funcționeze. Site-ul devine inaccesibil și nimic altceva. Asta diferă de DirectAdmin și contează din momentul în care folosiți suspendarea pentru a impune plata.
Încă un lucru, care merită o constantă în codul dumneavoastră, nu o variabilă: implementarea este if state == "Suspend": … else: <reluare>, fără nicio validare a valorii. Măsurat pe un site real:
1. state:"Suspend" → listă: Suspended
2. state:"suspend" → {"websiteStatus": 1, "error_message": "None"}
3. listă: → Active ← o literă minusculă a reluat site-ulO greșeală de tastare reactivează în tăcere un client suspendat și raportează succes.
Schimbarea pachetului schimbă evidența contabilă și nimic altceva
changePackageAPI revine în aproximativ 270 de milisecunde, iar panoul afișează noul nume de pachet. Măsurat ulterior din interiorul serverului, cu un pachet care avea intenționat 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. Întreaga operațiune este o modificare de câmp în baza de date. Citiți numele pachetului în CyberPanel ca evidență contabilă, nu ca o limită care s-ar fi mutat odată cu el, iar ce se află deasupra panoului ar trebui să spună asta, în loc să sugereze că o trecere la un plan superior a avut efect.
Nu există date de consum
CyberPanel este singurul panou de control din Provibr fără grafice de consum, iar aceasta nu este o omisiune a integrării: panoul nu îl măsoară.
Traficul este calculat și apoi aruncat: nu ajunge niciodată în listă. Consumul de disc provine dintr-un cache stocat pe înregistrarea site-ului, iar pe un site proaspăt creat acel câmp este gol, așa că valoarea raportată revine la zero. Un zero dintr-un cache gol nu se poate distinge de un site care într-adevăr nu consumă nimic. Un grafic care rămâne la zero pentru totdeauna arată ca o măsurătoare; de aceea nu există niciunul.
Ce face Provibr cu el
Provibr se conectează printr-un agent din propria dumneavoastră rețea, care inițiază conexiunea spre exterior, așa că panoul nu trebuie să expună nimic. Cere patru lucruri: adresa panoului, inclusiv portul 8090, numele de utilizator admin, parola acelui administrator și, atâta timp cât panoul încă folosește certificatul livrat din fabrică, amprenta SHA-256 de fixat.
Ultima nu este opțională în practică. Fiecare CyberPanel proaspăt instalat prezintă același certificat autosemnat, emis pentru www.example.com și semnat chiar de CyberPanel. Un browser îl numește greșit, nu autosemnat, iar lanțul nu se validează niciodată. A fixa amprenta înseamnă a avea încredere în acel singur certificat, în loc să dezactivați verificarea. Puneți propriul certificat pe numele de gazdă al panoului și lanțul se validează de la sine; lăsați atunci câmpul gol.
Fiți conștient de ce este această parolă. CyberPanel nu are niciun token de API care să acopere aceste comenzi: în interiorul propriului său API, calea tokenului este activată sau dezactivată per endpoint, iar cele patru care creează, suspendă, reîmpachetează și elimină un site cer toate parola. Așadar, aceasta este parola completă a administratorului dumneavoastră principal.
Odată ce acest lucru este pus la punct: pachetele devin vandabile ca planuri de găzduire web sub un nume și un preț ale dumneavoastră, comenzile creează site-uri și așteaptă rezultatul real în loc de primul răspuns, suspendarea și reluarea funcționează la cerere și atunci când depășiți capacitatea, iar site-urile care există deja pot fi importate.
Ce nu face
Provibr gestionează site-uri, nu panoul: nu instalează CyberPanel, nu îl actualizează și nu modifică setările serverului. Nu există consolă. DNS-ul, căsuțele de e-mail și bazele de date rămân neatinse; CyberPanel face toate acestea singur și nimic aflat deasupra lui nu le comandă. Și nu există grafice de consum, pentru că nu există nimic onest de reprezentat.
Nu trebuie să pariați pe un singur panou. Provibr rulează astăzi panourile sale de control, hipervizoarele și panourile de joc unele lângă altele, într-un singur inventar, cu un singur model de permisiuni și un singur jurnal de activitate.