WISP

WISP se vende como servicio alojado: wisp.gg ejecuta el panel, y el nodo que aloja los servidores de juego corre en hardware propio. El agente habla con el panel por su API y con el daemon del nodo para la consola. Las dos conexiones son salientes, así que no hace falta abrir nada a internet.

WISP conserva la separación de Pterodactyl entre dos API, y ninguna clave llega a las dos. Créelas en una cuenta de administrador y pegue las dos junto con la dirección del panel.

• La dirección del panel: la URL completa, por ejemplo https://panel.example.com. Solo hay que añadir un puerto si el panel se ejecuta realmente en él; detrás de un proxy inverso responde en el puerto predeterminado de su esquema.
• La clave de API de aplicación: sirve para crear, suspender, reinstalar y eliminar servidores.
• La clave de API de cliente: sirve para el encendido y apagado, las estadísticas en vivo y la consola.
• La huella TLS (opcional): en un panel WISP alojado se deja vacía, porque su certificado viene de una autoridad pública y no hay nada a lo que anclarse.

Un panel WISP alojado es accesible por https con un certificado de confianza pública, así que el campo de la huella se queda vacío. Solo hay que rellenarlo cuando WISP se ejecuta por cuenta propia detrás de un certificado autofirmado; el agente confía entonces en ese certificado concreto en lugar de desactivar la verificación. Se lee con:

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

Con un certificado de una autoridad pública se deja el campo vacío, y también si el panel solo es accesible por http. Una huella junto a una dirección http se rechaza, porque no hay ningún certificado al que anclarse. Un panel en http sin cifrar sí funciona, pero entonces las dos claves viajan sin cifrar por la red.

Un servidor se construye a partir de un egg, exactamente igual que en Pterodactyl. WISP enumera todos sus eggs con sus variables en una sola llamada, así que el selector se rellena solo y un plan puede sobrescribir cualquier variable que el egg marque como editable.

Un plan de juego lleva el egg, los límites de recursos y las variables que se sobrescriban. El pedido se hace mediante un plan: el plan decide qué egg se usa y cuánto puede consumir el servidor, y un mismo plan puede vincularse a más de un panel.

Un nodo de WISP informa de sus núcleos, su memoria y su disco, pero no de cuánto de eso ya está repartido. Provibr lo suma a partir de los servidores del nodo, que es lo mismo que hace con un hipervisor.

Crear, iniciar, detener, reiniciar, forzar la parada, suspender, reactivar, reinstalar y eliminar funcionan todos. Un servidor suspendido se puede eliminar igualmente, y al eliminarlo su asignación de puerto vuelve a quedar libre.

La consola es un terminal en vivo sobre el daemon del nodo, en el mismo panel que el resto de la infraestructura, y los gráficos de uso vienen de las propias mediciones del panel. La CPU, la memoria, el disco y la red se leen en cada ronda de sondeo; WISP no informa del tiempo en marcha, así que un contenedor que se reinicia entre dos rondas no siempre se reconoce como un reinicio.

Provibr no gestiona el panel, sus nodos, archivos, copias de seguridad, bases de datos ni usuarios. Los añadidos propios de WISP tampoco forman parte de la integración: el splitter, los subdominios, los borrados programados, las tiendas de mods. Lo que Provibr aprovisiona, cuenta y cobra es un servidor de juego en el panel; los servidores que no se hayan creado con Provibr se dejan intactos.