Perguntas frequentes

Uma plataforma de gestão de servidores para quem opera a sua própria infraestrutura. Os hipervisores, a rede e os contratos de centro de dados continuam a ser seus; o Provibr dá à sua equipa um único painel a partir do qual os controlar, e a maquinaria para entregar capacidade a clientes.

Hipervisores para máquinas virtuais, painéis de controlo para contas de alojamento e painéis de jogos para servidores de jogos. Servidores dedicados, equipamento de rede e distribuição de energia estão no roteiro. A página de integrações indica o estado exato de cada fornecedor, disponível ou roteiro, por isso esta resposta nunca fica desatualizada sem que ninguém dê por isso.

Não. O Provibr comunica com a API do Proxmox através de um token que cria, a partir de um agente executado num host Linux separado, na mesma rede. No próprio hipervisor não é instalado nada e não é necessário que nenhuma porta do Proxmox esteja acessível a partir do exterior.

Sim, e é assim que está previsto trabalhar. Os seus prefixos, os respetivos gateways e o intervalo utilizável são registados na gestão de endereços da plataforma, e cada máquina recebe um endereço do pool para o qual o seu plano aponta.

A lista completa está no seletor de idioma no topo de cada página: hoje, 9 idiomas. O painel, este site e as mensagens que o seu agente gera estão todos traduzidos, para que o mesmo evento seja lido corretamente por toda a sua equipa. A ferramenta de linha de comandos e tudo o que se cola numa shell mantêm-se em inglês de propósito.

Sim. Existe uma API REST pública para servidores, agentes, integrações, endereços, planos, faturação e webhooks; a chave cria-se na sua página de perfil e transporta um âmbito por cada parte do painel, nunca mais do que já tem. Como o seu agente se liga para fora, um endpoint que altera uma máquina aceita a ordem e entrega algo que se pode acompanhar, em vez de responder com o resultado. A documentação descreve todos os endpoints e remete para o documento OpenAPI 3.1.

No host do agente, cifradas num cofre cuja chave é misturada com a identidade da própria máquina. Passam uma única vez pela plataforma, em trânsito, para chegarem ao agente. O registo de auditoria dessa transferência guarda os nomes dos campos e nunca os valores, e a plataforma não consegue reconstruir o token depois disso.

TLS 1.3 com autenticação mútua. A inscrição e a sessão de trabalho usam endpoints separados e, no endpoint da sessão, a plataforma fixa a impressão digital do certificado do agente, pelo que um certificado roubado sem a chave correspondente não serve de nada.

A sessão é fechada e o agente apaga a sua própria identidade e o cofre de credenciais. A partir desse momento não guarda nada de útil: nem certificado, nem token, nem forma de voltar a entrar sem uma nova licença e uma nova inscrição.

Sim, com uma assinatura sobre o binário em bruto. É verificada pelo agente antes da preparação e novamente por um script pertencente a root antes de o binário ser executado, contra uma chave pública que só o root pode substituir. Uma versão não assinada ou alterada é recusada, mesmo que a soma de verificação corresponda.

Não. Cada consulta, cada canal em tempo real e cada evento estão limitados a uma única organização, e a ligação em tempo real é autorizada com um ticket de utilização única associado à sua organização antes de o socket abrir.

Sim. Os comandos, os respetivos resultados, as ligações e desligações dos agentes, as mudanças de estado das integrações, as atribuições de endereços, as mudanças de pacote e os eventos de faturação vão todos parar a um registo de atividade que pode percorrer e filtrar. É conservado, não é descartado ao fim de um dia.