Vender alojamento web com ISPConfig

A maioria dos painéis de controlo gere um servidor. O ISPConfig gere um parque: uma só instalação colocada à frente de máquinas separadas de web, correio, DNS e base de dados, com os sites e as caixas de correio distribuídos por elas e uma única interface sobre o conjunto. Fá-lo há muitíssimo tempo, é de código aberto, e não custa nada.

É também o painel desta categoria com a ideia mais completa do que é um cliente. O ISPConfig tem clientes, revendedores, limites e modelos como objetos de primeira classe, o que é mais do que a maioria dos seus concorrentes pode dizer. O que não tem (e é toda a razão de ser de uma página como esta) é qualquer noção de um cliente que lhe paga.

O que o ISPConfig já lhe dá

Três coisas, e são invulgarmente boas.

Clientes, não apenas contas. Um cliente ISPConfig é uma pessoa ou uma empresa que possui coisas: sites, caixas de correio, zonas DNS, bases de dados. É a forma que um produto de alojamento realmente tem, e não é preciso inventá-la.

Limites, e modelos para os aplicar. Cada cliente tem limites: quantos domínios web, quantas caixas de correio, quantas bases de dados, quanto espaço. Os modelos de cliente permitem definir um conjunto de limites uma vez e aplicá-lo a muitos clientes, o que é exatamente um catálogo de produtos com outro nome. Um limite de -1 significa ilimitado, o que convém saber antes de ler um modelo e concluir que algo está avariado.

Revendedores. O ISPConfig compreende que um cliente pode ele próprio ter clientes. Se se vende a agências que vendem aos seus próprios clientes, essa hierarquia existe no painel em vez de numa folha de cálculo que se mantém ao lado.

Em conjunto, essas três cobrem as partes que a maioria dos painéis obriga a construir por si próprio.

A parte invulgar: um painel, várias máquinas

É isto que verdadeiramente separa o ISPConfig do DirectAdmin, do cPanel, do CloudPanel e dos restantes.

Uma só instalação ISPConfig pode comandar servidores web dedicados, um servidor de correio separado, servidores DNS separados e um servidor de base de dados separado, configurados numa disposição multisservidor, com espelhamento disponível para as partes que precisam de redundância. Quando se adiciona um site, o ISPConfig escreve-o na máquina que é suposto carregá-lo.

Para um alojador, decorrem duas consequências. A boa: crescer significa acrescentar uma máquina atrás do painel, e não montar um segundo painel e repartir os clientes por dois sistemas que se ignoram. A que há que prever: a sua ideia de «um servidor» e a ideia de «um servidor» do ISPConfig deixam de ser a mesma coisa. Uma conta já não está presa a uma máquina que se possa apontar com o dedo, o que não faz mal, mas qualquer inventário que se mantenha acima do ISPConfig tem de se dar bem com um cliente cujo site está numa máquina e cujas caixas de correio estão noutra.

A API remota, e as duas coisas a saber sobre ela

A automatização do ISPConfig passa pela sua API remota, disponível nas variantes SOAP e JSON. Duas propriedades moldam tudo o que nela se construa.

Funciona por sessão, não por token. Chama-se login com o nome e a palavra-passe de um utilizador remoto, recebe-se de volta um session_id, e passa-se esse em cada chamada seguinte. A sessão só é válida por um tempo limitado. É um ciclo de vida diferente dos tokens bearer que a maioria dos painéis modernos distribui: o cliente tem de manter uma sessão, aperceber-se de que expirou, e voltar a iniciar sessão. E não o deve fazer repetindo às cegas, porque um ciclo de início de sessão contra credenciais erradas é a forma de se acabar trancado do lado de fora de algo.

As permissões são por função, e são verificadas. Cria-se um utilizador remoto no painel (System, depois Add Remote User) e assinalam-se as categorias de chamadas que pode fazer. O ISPConfig verifica essa permissão em cada chamada que recebe.

Esta segunda propriedade tem verdadeiro valor e merece ser usada como deve ser. Significa que a credencial que está na sua automatização não tem de conseguir fazer tudo o que o ISPConfig faz. Dê-se-lhe as funções que o aprovisionamento realmente chama e mais nada, e um erro no próprio código não conseguirá chegar às partes do painel que nunca se pretendeu tocar. Muito poucos painéis desta classe permitem sequer traçar essa linha.

As próprias funções leem-se como seria de esperar. Os clientes criam-se com client_add. Os sites são sites_web_domain_add, sites_web_domain_update, sites_web_domain_get e sites_web_domain_delete. E, decisivamente para qualquer uso comercial, há sites_web_domain_set_status, uma forma real e suportada de ligar e desligar um site, ou seja, o verbo único à volta do qual gira a faturação de alojamento e de que vários painéis concorrentes simplesmente carecem.

O que continua a não fazer

Tudo o que precede é infraestrutura. Nada disso é comércio.

O ISPConfig não vai receber uma encomenda, não vai receber um pagamento, não vai produzir uma fatura, não vai cobrar nenhuma, e não vai decidir no trigésimo primeiro dia que este cliente deixou de pagar e deve ser desligado. Tem a alavanca (set_status), mas nada que decida quando a acionar. Não há catálogo com preços, não há fluxo de inscrição, não há calendário de cobrança, e nenhuma vista que diga o que o seu parque lhe custa face ao que rende.

Isto não é uma crítica. Um painel de controlo que tentasse ser também um sistema de faturação seria pior nas duas coisas. Mas significa que o trabalho interessante, quando se vende alojamento ISPConfig, está inteiramente na camada acima, e essa camada é a mesma de que se precisaria para qualquer outro painel:

• Um formulário de encomenda e um catálogo, com planos que correspondem aos modelos de cliente.
• Um pagamento que despoleta o aprovisionamento em segundos.
• Um percurso de cobrança (em atraso, avisado, suspenso, restaurado) ligado a set_status no passo certo.
• Capacidade visível, para se saber quantas contas se transportam por todas essas máquinas e quanto custam.
• Um registo de auditoria, para que «quem alterou aquele limite» tenha resposta.
• Um modelo de permissões para o seu próprio pessoal, para que o suporte possa agir sem poder eliminar um cliente.

Onde o Provibr se encaixa

O suporte para o ISPConfig está em produção. Um agente dentro da sua própria rede fala com a API remota do painel, de modo que nada do painel tem de estar exposto à Internet e não é preciso abrir portas. Criar um cliente com um site e um plano, suspendê-lo, retomá-lo, mudar-lhe o plano e removê-lo funciona, as contas que já lá estavam podem ser importadas, e o disco e o tráfego aparecem nos gráficos. À volta disso está a camada descrita acima: planos e capacidade com um preço unitário, um modelo de permissões para a sua equipa, um registo de atividade, e uma API REST e um módulo WHMCS para que a plataforma com que já fatura o possa comandar.

A credencial guardada no cofre do agente pode ser muito mais estreita do que um administrador, porque o ISPConfig concede as suas permissões remotas função a função: o utilizador remoto pode ficar limitado exatamente às chamadas que o Provibr faz e a mais nada. Em qual das suas máquinas o ISPConfig coloca um site continua a ser decisão do ISPConfig, as ações sobre a conta são as mesmas de qualquer forma, e cada conta vale um servidor web na sua capacidade, seja qual for a máquina que acabe por a executar.

O que a integração não faz é mexer em contas que não foram criadas por ela: essas ficam em paz até serem importadas, e é quem gere que escolhe quais. Uma nota prática sobre a própria ligação: uma instalação nova de ISPConfig é autoassinada, pelo que vale a pena fixar a sua impressão digital TLS ao adicionar a integração.

O que não fará

Gerir contas não é gerir o painel. Instalar o ISPConfig, atualizá-lo, acrescentar servidores por trás dele, configurar o encaminhamento de correio e cuidar do DNS: isso fica consigo, no ISPConfig, onde é o seu lugar. Um cliente que edita a sua própria caixa de correio fá-lo sem que nada acima do painel o saiba ou se importe.

Não é preciso normalizar tudo num só painel para manter uma única visão de conjunto. O Provibr faz correr hoje os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo lado a lado, sob um só inventário, um só modelo de permissões e um só registo de atividade. Um painel aberto multisservidor para os clientes que querem correio e DNS incluídos, outra coisa para os que pedem o cPanel pelo nome, e um só lugar onde se veem ambos.