WISP

O WISP é vendido como serviço alojado: o painel é executado pela wisp.gg e o nó que suporta os seus servidores de jogos corre no seu próprio hardware. O agente fala com o painel através da API e com o daemon do nó para a consola. Ambas as ligações são de saída, por isso não é preciso abrir nada à Internet.

O WISP mantém a divisão do Pterodactyl entre duas superfícies de API, e nenhuma chave sozinha chega às duas. Crie-as numa conta de administrador e cole ambas, juntamente com o endereço do painel.

• Endereço do painel: o URL completo, por exemplo https://panel.example.com. Acrescente uma porta apenas se o painel funcionar mesmo numa; um painel atrás de um proxy inverso responde na porta predefinida do seu esquema.
• Chave de API de aplicação: usada para criar, suspender, reinstalar e remover servidores.
• Chave de API de cliente: usada para os comandos de energia, as estatísticas em direto e a consola.
• Impressão digital TLS (opcional): deixe-a vazia num painel WISP alojado; o certificado dele vem de uma autoridade pública e não há nada para fixar.

Um painel WISP alojado está acessível por https com um certificado de uma autoridade pública, por isso o campo da impressão digital fica vazio. Preencha-o apenas quando executar o WISP por si próprio atrás de um certificado autoassinado; o agente passa então a confiar nesse certificado em concreto em vez de desligar a verificação. Leia-a com:

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Deixe o campo vazio para um certificado de uma autoridade pública e também quando o painel só estiver acessível por http. Uma impressão digital ao lado de um endereço http é recusada, porque não há certificado para fixar. Um painel em http simples funciona, mas as duas chaves viajam então sem encriptação.

Um servidor é construído a partir de um egg, exatamente como no Pterodactyl. O WISP lista todos os seus eggs com as respetivas variáveis numa única chamada, por isso o seletor preenche-se sozinho e um plano pode substituir qualquer variável que o egg marque como editável.

Um plano de jogos guarda o egg, os limites de recursos e as substituições de variáveis. A encomenda passa por um plano: é o plano que decide que egg é usado e quanto o servidor pode consumir, e um plano pode estar ligado a mais do que um painel.

Um nó WISP comunica os seus núcleos, a memória e o disco, mas não quanto disso já foi distribuído. O Provibr soma esse valor a partir dos servidores que estão no nó, tal como faz num hipervisor.

Criar, iniciar, parar, reiniciar, forçar a paragem, suspender, reativar, reinstalar e eliminar funcionam todos. Um servidor suspenso pode mesmo assim ser removido, e removê-lo liberta novamente a sua alocação de porta.

A consola é um terminal ao vivo no daemon do nó, no mesmo painel que o resto da sua infraestrutura, e os gráficos de utilização vêm das medições do próprio painel. O CPU, a memória, o disco e a rede são lidos em cada sondagem; o WISP não comunica o tempo de atividade, por isso um contentor que reinicie entre duas sondagens nem sempre é reconhecido como um reinício.

O Provibr não gere o painel, os seus nós, ficheiros, cópias de segurança, bases de dados ou utilizadores. Os extras do próprio WISP também não fazem parte da integração: o splitter, os subdomínios, os agendamentos de wipe, as lojas de mods. O que o Provibr aprovisiona, conta e cobra é um servidor de jogos no painel; os servidores que não foram criados através do Provibr ficam intactos.