WISP

WISP est vendu comme un service hébergé : wisp.gg fait tourner le panneau, et le nœud qui porte vos serveurs de jeu tourne sur votre propre matériel. L’agent dialogue avec le panneau via son API et avec le démon du nœud pour la console. Ces deux liaisons sont sortantes, si bien que rien n’a besoin d’être ouvert sur internet.

WISP conserve la séparation de Pterodactyl entre deux API, et aucune clé unique ne couvre les deux. Créez-les sur un compte administrateur et collez-les toutes les deux, avec l’adresse du panneau.

• Adresse du panneau : l’URL complète, par exemple https://panel.example.com. N’ajoutez un port que si le panneau y tourne réellement ; derrière un proxy inverse, il répond sur le port par défaut de son schéma.
• Clé d’API application : sert à créer, suspendre, réinstaller et supprimer des serveurs.
• Clé d’API client : sert à la marche/arrêt, aux statistiques en direct et à la console.
• Empreinte TLS (facultatif) : laissez-la vide sur un panneau WISP hébergé ; son certificat provient d’une autorité publique et il n’y a rien à épingler.

Un panneau WISP hébergé est joignable en https avec un certificat approuvé publiquement, si bien que le champ d’empreinte reste vide. Ne le renseignez que si vous faites tourner WISP vous-même derrière un certificat auto-signé ; l’agent fait alors confiance à ce seul certificat au lieu de désactiver la vérification. Lisez-la avec :

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

Laissez le champ vide pour un certificat émis par une autorité publique, ainsi que lorsque le panneau n’est joignable qu’en http. Une empreinte à côté d’une adresse http est refusée, car il n’y a aucun certificat à épingler. Un panneau en http simple fonctionne, mais les deux clés circulent alors en clair.

Un serveur est construit à partir d’un egg, exactement comme sur Pterodactyl. WISP liste tous ses eggs avec leurs variables en un seul appel, si bien que le sélecteur se remplit tout seul et qu’un plan peut redéfinir toute variable que l’egg marque comme modifiable.

Un plan de jeu porte l’egg, les limites de ressources et les redéfinitions de variables. La commande passe par un plan : le plan décide quel egg est utilisé et ce que le serveur peut consommer, et un même plan peut être relié à plusieurs panneaux.

Un nœud WISP indique ses cœurs, sa mémoire et son disque, mais pas la part qui en est déjà distribuée. Provibr l’additionne à partir des serveurs présents sur le nœud, exactement comme il le fait pour un hyperviseur.

Créer, démarrer, arrêter, redémarrer, tuer, suspendre, réactiver, réinstaller et supprimer fonctionnent tous. Un serveur suspendu peut malgré tout être supprimé, et le supprimer libère de nouveau son allocation de port.

La console est un terminal en direct sur le démon du nœud, dans le même panneau que le reste de votre infrastructure, et les graphiques d’utilisation proviennent des mesures du panneau lui-même. Le processeur, la mémoire, le disque et le réseau sont lus à chaque tour d’interrogation ; WISP ne remonte pas la durée de fonctionnement, si bien qu’un conteneur qui redémarre entre deux tours n’est pas toujours reconnu comme un redémarrage.

Provibr ne gère ni le panneau, ni ses nœuds, ses fichiers, ses sauvegardes, ses bases de données ou ses utilisateurs. Les suppléments propres à WISP ne font pas non plus partie de l’intégration : le splitter, les sous-domaines, les planifications de wipe, les boutiques de mods. Ce que Provibr provisionne, compte et facture, c’est un serveur de jeu sur le panneau ; les serveurs que vous n’avez pas créés via Provibr sont laissés tels quels.