Săriți la conținut

Blog ·

Vânzarea serverelor de joc cu GameAP

Vindeți găzduire de servere de joc pe GameAP: tokenul admin, de ce nu există o listă de jocuri, cum funcționează plasarea și porturile și ce face suspendarea.

De Provibr

GameAP este un proiect mic. La 21 august 2026, depozitul său GitHub avea 60 de stele, 9 forks și 2 contributori. Merită spus cu voce tare, pentru că fixează așteptările: nu există în jurul lui un ecosistem mare de module de facturare, scripturi de provizionare și fire de discuție. Dacă rulați GameAP și vreți să vindeți ceea ce găzduiește, sunteți în mare parte pe cont propriu.

Această pagină este despre închiderea acelui decalaj. Provibr se conectează la un panou GameAP și provizionează, controlează și importă servere de joc pe el. Tot ce urmează a fost măsurat pe un panou GameAP 4.4.2 real, nu recopiat dintr-o listă de funcționalități, inclusiv părțile în care GameAP se comportă altfel decât v-ați aștepta.

Ce acoperă de fapt integrarea

CapabilitateSuportat
Creare, pornire, oprire, repornire, reinstalare, ștergereDa
Suspendare și reactivareDa, cu o rezervă (vedeți mai jos)
Importul serverelor existenteDa
Consolă în browserNu
Grafice de utilizare (CPU, memorie, disc, rețea)Nu
Gestionarea panoului, a nodurilor, a fișierelor sau a utilizatorilor săiNu

Cele două rânduri „nu” nu sunt scăpări, iar motivele se află la sfârșit.

Pasul 1: tokenul API

GameAP se autentifică cu un singur token API. Fără client OAuth2, fără pereche de chei, fără sesiune de menținut în viață: un singur purtător, iar aceasta este toată acreditarea.

Patru lucruri contează în privința lui.

Trebuie creat de un administrator și trebuie să poarte permisiunea de creare. Tokenurile GameAP au domeniu limitat. Un token fără admin:server:create poate lista serverele perfect, dar nu le poate crea sau șterge. Merită să știți asta înainte de prima comandă, pentru că un token cu domeniu corect, dar greșit ales pare sănătos exact până în momentul în care un client vă plătește. Provibr verifică permisiunea de creare atunci când testați conexiunea, nu la prima comandă.

Ștergerea depinde de aceeași permisiune. Nu există deloc un domeniu server:delete în GameAP. Am măsurat o ștergere reușită cu un token care purta doar admin:server:create plus domeniile de server obișnuite. Un singur token acoperă întregul ciclu de viață.

Tokenul are forma id|secret. Aceasta este forma Laravel Sanctum: un id numeric, o bară verticală și un secret de 48 de caractere. Provibr păstrează această formă și respinge un token lipit fără id-ul în față. Este o veritabilă greșeală de lipire, iar prinderea ei este mai bună decât o 401 derutantă mai târziu.

Nu expiră. Tabelul personal_access_tokens din GameAP nu are o coloană expires_at. Aceasta este cea mai curată acreditare de lungă durată dintre toate panourile pe care le-am integrat: agentul continuă să funcționeze luni întregi fără ca cineva să reintroducă ceva. Comparați cu panourile unde secretul este o parolă și fiecare rotație devine un tichet de suport.

O notă practică: GameAP afișează tokenul o singură dată și păstrează apoi doar un hash. Copiați-l imediat. Nici Provibr nu îl stochează, așa că retrimiterea acreditărilor înseamnă crearea unui token nou.

Pasul 2: transportul și onestitatea în privința lui

O instalare GameAP implicită servește HTTP simplu pe portul 8025, cu 443 închis. Nu există niciun câmp pentru amprentă TLS în formularul de acreditări, pentru că fără TLS nu există niciun certificat de fixat.

Asta funcționează. Înseamnă totodată că tokenul API și tot ce face integrarea circulă necriptat. Dacă acest lucru contează pentru dumneavoastră (iar pe un panou care găzduiește serverele clienților dumneavoastră probabil că ar trebui), puneți în față un reverse proxy cu TLS. Agentul validează atunci lanțul de certificate în mod normal, fără o fixare.

Pasul 3: planul și de ce nu există o listă de selecție

Un server GameAP se construiește dintr-un joc (un titlu precum samp sau minecraft) și un game mod, care este șablonul său. Împreună, acestea corespund aproximativ a ceea ce este un egg în Pterodactyl.

Iată cea mai clară diferență față de orice alt panou de joc pe care îl suportăm: Provibr nu le poate lista pentru dumneavoastră. Cu un token de agent cu domeniu limitat, /api/games, /api/game_mods și /api/nodes returnează toate trei o 403. Citirea catalogului este restricționată prin rol la o sesiune de administrator, iar nicio permisiune de token nu o deblochează.

Așadar, nu există niciun meniu derulant. Vă deschideți propriul panou GameAP, citiți codul jocului și id-ul modului și le introduceți în plan. Un plan de joc poartă apoi acel cod de joc, acel id de mod și limitele de resurse, iar comanda este pilotată de plan din acel punct.

Este mai multă tastare decât o listă de selecție. Este totodată forma onestă: un meniu derulant pe care nu l-am putea popula ar fi mai rău decât un câmp care spune ce vrea.

Pasul 4: plasare și porturi

Două consecințe decurg din aceeași 403.

Nodul provine dintr-o setare, nu din motorul de plasare. Provibr clasifică nodurile după capacitatea liberă când poate. Aici nu poate, pentru că nu poate citi deloc lista de noduri. În schimb, integrarea poartă un id de nod, care este 1 pe un panou cu un singur nod. Pe un panou cu mai multe noduri, un server ajunge pe nodul pe care l-ați numit, și nimic nu este clasificat.

Porturile provin dintr-un interval pe care îl stabiliți. GameAP nu are un sistem propriu de alocare: nimic nu distribuie un port liber. Agentul alege un set liber de porturi (joc, interogare și RCON) dintr-un interval pe care îl configurați pe integrare.

Ce face de fapt o comandă

Aici GameAP se deosebește cel mai mult de un panou precum Pterodactyl și aici greșește o integrare naivă.

  1. POST /api/servers scrie înregistrarea în baza de date. Nu instalează nimic.
  2. Un al doilea apel pornește instalarea, iar daemonul panoului o rulează ca sarcină asincronă.
  3. Provibr interoghează acea sarcină până când ajunge la o stare finală.
  4. Apoi serverul pornește.

Regula esențială: răspunsul HTTP al unei acțiuni înseamnă doar că sarcina a fost pusă în coadă. Nu înseamnă că a reușit. Am măsurat un stop care a revenit cu o eroare dintr-o concurență pe gazdă. Fiecare server de joc rulează ca propria unitate systemd pe nod, iar systemctl stop poate pierde o cursă cu sine însuși. Rezultatul sarcinii este adevărul; răspunsul HTTP este o confirmare de primire. Provibr citește sarcina.

Alte două realități măsurate de care merită să țineți cont. Nu există niciun id extern și nicio cheie de idempotență, iar numele serverelor nu sunt unice: am creat două servere cu același nume și am obținut două 201 cu id-uri diferite. Id-ul returnat de apelul de creare este singura identitate care există, ceea ce înseamnă că o creare reluată produce în tăcere un duplicat. Iar mediul de instalare nu este complet peste tot: o instalare de TeamSpeak 3 pe un panou standard a eșuat pentru că lipsea lbzip2 pentru extragerea .tar.bz2, în timp ce o instalare SA-MP pe aceeași mașină a decurs curat. Așteptați-vă ca „instalarea merge pentru un joc și nu pentru altul” să devină o categorie de suport.

Suspendarea: citiți asta înainte să vă bazați pe ea

Când Provibr suspendă un server de joc, pentru a impune o limită de capacitate, oprește serverul și îl marchează blocat în panou.

Amândouă jumătățile sunt necesare, și iată de ce: indicatorul blocked al GameAP nu impune nimic. Am setat blocked pe un server SA-MP care rula și a rămas online, răspunzând la interogări de joc live. Apoi am trimis o pornire către un server blocat și am primit înapoi o sarcină normală. Indicatorul este administrativ.

Așa că Provibr oprește serverul pentru a impune efectiv limita. Dar oricine are acces direct la panoul GameAP îl poate porni din nou. Blocarea este o noțiune Provibr la fel de mult ca una a panoului, iar noi preferăm să o scriem aici decât să vă lăsăm să o descoperiți în timpul primei depășiri.

Ce nu face Provibr aici

Fără consolă. GameAP are într-adevăr una, printr-un websocket, dar rulează pe un token separat, de scurtă durată, dintr-o etapă proprie de autentificare și cu propriul protocol de cadre, un traseu diferit de tunelul pe care agentul nostru îl partajează cu celelalte panouri de joc. Aceasta este muncă reală, nu un comutator. Activarea filei înainte de a exista această muncă ar promite un tunel care nu este acolo.

Fără grafice de utilizare. GameAP nu raportează, per server, nici CPU, nici memorie, nici disc, nici rețea. Nu există niciun punct final. Un grafic blocat la zero arată ca o măsurătoare, iar „nicio măsurătoare” și „nicio utilizare” nu sunt același lucru, așa că afișăm mai degrabă nimic.

Fără gestionarea panoului. Nodurile, fișierele, utilizatorii și panoul însuși rămân ai dumneavoastră. Un server de joc pe panou este subiectul integrării.

Ce înseamnă asta pentru un furnizor mic

Dacă GameAP este ceea ce rulați, alegerea este de obicei prezentată ca „păstrați-vă panoul și facturați manual” sau „treceți la ceva pe care un sistem de facturare îl vorbește deja”. Este o alegere falsă și una costisitoare: migrarea unui panou plin de servere de joc în producție nu este treabă de un weekend.

Provibr se conectează la panouri de control, hipervizoare și panouri de joc, unele lângă altele. Nu trebuie să alegeți unul singur. Păstrați GameAP pentru jocurile pe care le găzduiți deja, adăugați lângă el ceea ce aveți nevoie și rulați comenzile, contorizarea capacității și suspendarea pentru neplată pentru toate, dintr-un singur loc.

Î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ă.