WISP

WISP si acquista come servizio ospitato: wisp.gg fa girare il pannello, mentre il nodo che ospita i suoi server di gioco gira sul suo hardware. L’agente dialoga con il pannello attraverso la sua API e con il daemon del nodo per la console. Sono entrambe connessioni in uscita, quindi non c’è nulla da aprire verso internet.

WISP mantiene la separazione di Pterodactyl fra due superfici API, e nessuna chiave singola le raggiunge entrambe. Le crei su un account amministratore e le incolli entrambe, insieme all’indirizzo del pannello.

• Indirizzo del pannello: l’URL completo, ad esempio https://panel.example.com. Aggiunga una porta solo se il pannello gira davvero su una; un pannello dietro a un reverse proxy risponde sulla porta predefinita del suo schema.
• Chiave API applicazione: serve a creare, sospendere, reinstallare ed eliminare i server.
• Chiave API client: trasporta i comandi di accensione e spegnimento, le statistiche in tempo reale e la console.
• Impronta TLS (facoltativa): la lasci vuota su un pannello WISP ospitato; il suo certificato proviene da un’autorità pubblica e non c’è nulla da fissare.

Un pannello WISP ospitato è raggiungibile via https con un certificato attendibile pubblicamente, quindi il campo dell’impronta resta vuoto. Lo compili solo se fa girare WISP in proprio dietro a un certificato autofirmato; l’agente si fida allora di quel singolo certificato invece di disattivare la verifica. La legga con:

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

Lasci il campo vuoto per un certificato di un’autorità pubblica, e lo stesso quando il pannello è raggiungibile solo tramite http: un’impronta accanto a un indirizzo http viene rifiutata, perché non c’è alcun certificato da fissare. Un pannello in http in chiaro funziona, ma entrambe le chiavi viaggiano allora senza cifratura.

Un server è costruito a partire da un egg, esattamente come su Pterodactyl. WISP elenca tutti i suoi egg con le relative variabili in un’unica chiamata, così l’elenco di selezione si riempie da sé e un piano può sovrascrivere qualsiasi variabile che l’egg segna come modificabile.

Un piano di gioco porta l’egg, i limiti di risorse ed eventuali sovrascritture delle variabili. L’ordine passa da un piano: è il piano a decidere quale egg viene usato e quanto il server può consumare, e uno stesso piano può essere collegato a più pannelli.

Un nodo WISP comunica i suoi core, la memoria e il disco, ma non quanta parte ne sia già stata distribuita. Provibr la somma a partire dai server presenti sul nodo, esattamente come fa per un hypervisor.

Creare, avviare, arrestare, riavviare, forzare l’arresto, sospendere, riattivare, reinstallare ed eliminare funzionano tutti. Un server sospeso si può comunque eliminare, e l’eliminazione libera di nuovo la sua assegnazione di porta.

La console è un terminale dal vivo sul daemon del nodo, nello stesso pannello del resto della sua infrastruttura, e i grafici di utilizzo provengono dalle misurazioni del pannello stesso. CPU, memoria, disco e rete vengono letti a ogni giro di polling; WISP non riporta l’uptime, quindi un container che si riavvia fra due giri non viene sempre riconosciuto come riavvio.

Provibr non gestisce il pannello, i suoi nodi, i file, i backup, i database o gli utenti. Nemmeno gli extra propri di WISP fanno parte dell’integrazione: lo splitter, i sottodomini, le pianificazioni di wipe, gli store di mod. Ciò che Provibr crea, conteggia e tariffa è un server di gioco sul pannello; i server non creati tramite Provibr vengono lasciati intatti.