Vender alojamento web com CyberPanel

O CyberPanel é o painel que os alojadores com OpenLiteSpeed citam mais vezes ao lado do DirectAdmin. Medido no GitHub a 21 de agosto de 2026: 2007 estrelas, 723 forks e 362 problemas em aberto, com uma cadência de lançamentos mais lenta do que a da maioria dos seus pares.

Tem uma API REST, e tudo o que é preciso para nela vender alojamento (criar um site, suspendê-lo, mudar o seu pacote, eliminá-lo) faz parte dessa API. O que não tem é algo que decida quando fazer essas coisas, e o que tem de facto é um conjunto de respostas fáceis de ler mal.

Antes de tudo: o acesso à API está desativado

Num CyberPanel acabado de instalar, a API está desligada, e isso vale também para o administrador principal. Ativa-se em Users → API Access, para o utilizador admin. Nada mais é necessário; entra-se com as credenciais que já existem.

Deixe-o desligado e cada chamada regressa como API Access Disabled., envie-se o que se enviar. A parte que custa uma tarde é a ordem: o CyberPanel verifica esse interruptor antes de verificar a palavra-passe, por isso, com ele desligado, uma palavra-passe certa e uma errada devolvem o mesmo 403. Tudo aponta para as credenciais quando o problema está uma caixa de verificação mais à frente.

Uma vez ligado o interruptor, o contrato por baixo é limpo e verdadeiramente útil:

palavra-passe certa      → HTTP 200  {"verifyConn": 1}
palavra-passe errada     → HTTP 401  {"verifyConn": 0, "error_message": "Invalid password."}
utilizador desconhecido  → HTTP 404  {"error_message": "Administrator not found."}

Três situações, três ações diferentes para o cliente, todas distinguíveis.

O administrador tem de se chamar admin

Não uma definição: uma condição, e vem do CyberPanel, não de algo construído por cima. Parte da sua API é guardada por uma verificação literal do nome que recusa qualquer utilizador que não seja admin, e essa parte é precisamente a que lista os sites do painel e indica até onde chegou um novo.

Ambas são incontornáveis para nele vender alojamento: é precisa a lista para saber o que existe, e é precisa a indicação de progresso pela razão exposta na secção seguinte. Um administrador que tenha sido renomeado não pode ser usado, e tudo o que se construa deve dizê-lo durante o teste de ligação, antes de a primeira encomenda o descobrir por si.

Uma conta é um domínio, não um nome de utilizador

Esta é a diferença estrutural face ao DirectAdmin, ao cPanel e ao Virtualmin, e muda a forma de modelar o produto.

O registo de site do CyberPanel tem um campo domain único, e cada comando o visa: a eliminação usa domainName, a suspensão e a mudança de pacote usam websiteName, e as três procuram o site pelo domínio. Não há nome de utilizador a endereçar. O utilizador unix é gerado, não escolhido: cinco letras extraídas do domínio mais quatro dígitos aleatórios. Medido para provibr-test-1.example.com: provi7346, com o diretório pessoal nomeado a partir do domínio, não do utilizador. Não é possível escolher esse nome, nem prevê-lo, e aparece em exatamente uma resposta de API e em nenhuma listagem.

Uma consequência que convém conhecer antes da centésima conta: criar um site cria também, por baixo, um login de painel, com acesso à API ativado, e esse login sobrevive à eliminação do site. Medido após uma eliminação: utilizador unix desaparecido, diretório pessoal desaparecido, vhost desaparecido, linha de base de dados desaparecida; o login de proprietário ainda lá. O caminho de limpeza do CyberPanel é guardado por uma verificação que não pode ter êxito no momento em que corre, e o erro daí resultante é engolido. Se nada acima do painel o remover, cada cliente cancelado deixa um login para trás.

Criar um site anuncia sucesso antes de saber

Isto é a coisa mais importante a compreender sobre a API do CyberPanel.

createWebsite responde em cerca de três segundos com:

{"status": 1, "createWebSiteStatus": 1, "error_message": "None",
 "tempStatusPath": "/home/cyberpanel/2424", "LinuxUser": "provi7346"}

Isto chega antes de a maior parte do trabalho estar feita: o ponto de acesso constrói uma linha de comando, inicia-a sem esperar, e devolve o controlo. O verdadeiro progresso vive num ficheiro de estado, legível através de uma chamada separada. Medido, uma criação real:

+ 2,8s   10%  Creating DNS records..
+ 4,8s   25%  Setting up directories..
+ 6,9s   70%  Setting up SSL..        ← fica aqui 28 segundos
+35,3s   80%  Creating mail child domain..
+49,5s  100%  Website successfully created. [200]

Cerca de cinquenta segundos, dos quais uns vinte e oito são uma tentativa de SSL que o painel faz seja o que for que se envie: a API sobrepõe-se a esse campo sem condições, pelo que não há forma de criar um site sem SSL. Num domínio que ainda não resolve publicamente, isso são vinte e oito segundos à espera de um certificado que não vai chegar.

E a primeira resposta não é um veredicto. Medido com dados propositadamente errados:

Apenas a forma do domínio e do e-mail é verificada de imediato. Se o domínio está livre e se o pacote existe só é visível no ficheiro de estado. Uma integração que confie na primeira resposta anuncia uma encomenda bem-sucedida para um domínio que já estava ocupado.

Dois pormenores tornam a sondagem mais difícil do que parece. Ler um estado concluído elimina o ficheiro, pelo que uma segunda sondagem devolve «ficheiro inexistente» com um indicador de «ainda não terminou»: um cliente que sonda uma vez a mais vê «ainda a trabalhar» para sempre, para uma criação que teve êxito. E a chamada de estado vive apenas na superfície reservada a admin, o que é a razão pela qual a exigência do nome admin acima não é opcional.

A suspensão é um truque do servidor web, não um bloqueio de conta

Suspender e reativar são a parte bem-comportada desta API: ambas produzem efeito de imediato, e a própria lista do painel mostra o novo estado logo de seguida.

Mas convém saber o que faz. O CyberPanel reescreve a configuração vhost do site para uma página de suspensão e reinicia o servidor web. O utilizador unix não é bloqueado; o FTP, o correio e as bases de dados continuam a funcionar. O site torna-se inacessível, e mais nada. Isso difere do DirectAdmin, e conta a partir do momento em que se usa a suspensão para fazer cumprir um pagamento.

Mais uma coisa, que merece uma constante no código e não uma variável: a implementação é if state == "Suspend": … else: <reativar>, sem qualquer validação do valor. Medido num site real:

1. state:"Suspend"  → lista: Suspended
2. state:"suspend"  → {"websiteStatus": 1, "error_message": "None"}
3. lista:            → Active     ← uma minúscula reativou o site

Uma gralha reativa silenciosamente um cliente suspenso e anuncia sucesso.

Mudar de pacote muda a contabilidade, e nada mais

changePackageAPI devolve o controlo em cerca de 270 milissegundos e o painel mostra o novo nome do pacote. Medido a seguir a partir do interior do servidor, com um pacote com limites propositadamente diferentes: a quota de disco estava inalterada (soft 0, hard 0) e a configuração vhost ainda trazia os limites de memória e de processos do pacote antigo.

Nada foi aplicado. Toda a operação é uma atualização de um campo em base de dados. Leia-se o nome do pacote no CyberPanel como administração, não como um limite que se tenha movido com ele. E o que estiver acima do painel deve dizê-lo, em vez de dar a entender que uma atualização de gama produziu efeito.

Não há dados de utilização

O CyberPanel é o único painel de controlo no Provibr sem gráficos de utilização, e isso não é uma omissão da integração: o painel não a mede.

A largura de banda é calculada e depois descartada: nunca chega à listagem. A utilização de disco sai de uma cache guardada no registo do site, e num site acabado de criar esse campo está vazio, pelo que o valor comunicado recai em zero. Um zero vindo de uma cache vazia não se distingue de um site que realmente não consome nada. Um gráfico que fica em zero para sempre parece uma medição; é por isso que não há nenhum.

O que o Provibr faz com isto

O Provibr liga-se através de um agente dentro da sua própria rede que faz a ligação para o exterior, pelo que o painel não precisa de expor nada. Pede quatro coisas: o endereço do painel, incluindo a porta 8090, o nome de utilizador admin, a palavra-passe desse administrador e (enquanto o painel ainda usar o certificado com que veio de origem) a impressão digital SHA-256 a fixar.

Esta última não é opcional na prática. Todo o CyberPanel acabado de instalar apresenta o mesmo certificado autoassinado, emitido para www.example.com e assinado pelo próprio CyberPanel. Um navegador chama-lhe incorreto em vez de autoassinado, e a cadeia nunca é validada. Fixar a impressão digital significa confiar nesse único certificado em vez de desativar a verificação. Coloque-se o próprio certificado no nome de anfitrião do painel e a cadeia valida-se sozinha; deixe-se então o campo vazio.

Convém ter noção do que é esta palavra-passe. O CyberPanel não tem qualquer token de API que cubra estes comandos: dentro da sua própria API, a via do token está ativada ou desativada por ponto de acesso, e os quatro que criam, suspendem, mudam de pacote e removem um site exigem todos a palavra-passe. Trata-se, portanto, da palavra-passe completa do administrador principal.

Com isto no sítio: os pacotes tornam-se vendáveis como planos web sob um nome e um preço próprios, as encomendas criam sites e esperam pelo resultado verdadeiro em vez da primeira resposta, a suspensão e a reativação funcionam a pedido e quando se excede a capacidade, e os sites que já existem podem ser importados.

O que não faz

O Provibr gere sites, não o painel: não instala o CyberPanel, não o atualiza e não altera definições do servidor. Não há consola. O DNS, as caixas de correio e as bases de dados ficam intactos: o CyberPanel faz tudo isso sozinho e nada acima o comanda. E não há gráficos de utilização, porque não há nada de honesto para traçar.

Não é preciso apostar num só painel. O Provibr faz correr hoje os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo lado a lado, num só inventário, com um só modelo de permissões e um só registo de atividade.