Vendere hosting web con ISPConfig

La maggior parte dei pannelli di controllo gestisce un solo server. ISPConfig gestisce una flotta: un’unica installazione posta davanti a macchine web, di posta, DNS e database separate, con i siti e le caselle di posta distribuiti tra di esse e un’unica interfaccia sull’insieme. Lo fa da moltissimo tempo, è open source e non costa nulla.

È anche il pannello di questa categoria con l’idea più completa di cosa sia un cliente. ISPConfig ha clienti, rivenditori, limiti e template come oggetti di prima classe, il che è più di quanto possa dire la maggior parte dei suoi concorrenti. Ciò che non ha (ed è l’intero motivo per cui esiste una pagina come questa) è una qualsiasi nozione di un cliente che La paga.

Cosa offre già ISPConfig

Tre cose, e sono insolitamente buone.

Clienti, non solo account. Un cliente ISPConfig è una persona o un’azienda che possiede cose: siti web, caselle di posta, zone DNS, database. È la forma che un prodotto di hosting ha davvero, e non deve inventarla.

Limiti, e template per applicarli. Ogni cliente porta con sé dei limiti: quanti domini web, quante caselle di posta, quanti database, quanto spazio. I template dei clienti permettono di definire un insieme di limiti una volta e applicarlo a molti clienti, il che è esattamente un catalogo prodotti con un altro nome. Un limite di -1 significa illimitato, cosa che vale la pena sapere prima di leggere un template e concludere che qualcosa è rotto.

Rivenditori. ISPConfig capisce che un cliente può a sua volta avere clienti. Se vende ad agenzie che vendono ai propri clienti, quella gerarchia esiste nel pannello anziché in un foglio di calcolo che tiene a fianco.

Insieme, quei tre coprono le parti che la maggior parte dei pannelli La costringe a costruire da sé.

La parte insolita: un pannello, più macchine

È questo che distingue davvero ISPConfig da DirectAdmin, cPanel, CloudPanel e gli altri.

Un’unica installazione ISPConfig può pilotare server web dedicati, un server di posta separato, server DNS separati e un server di database separato, configurati come un’installazione multiserver, con il mirroring disponibile per le parti che hanno bisogno di ridondanza. Quando si aggiunge un sito web, ISPConfig lo scrive sulla macchina che deve ospitarlo.

Per un hoster ne seguono due conseguenze. Quella buona: crescere significa aggiungere una macchina dietro il pannello, non tirare su un secondo pannello e dividere i suoi clienti tra due sistemi che non si conoscono a vicenda. Quella da mettere in conto: la sua idea di «un server» e l’idea di «un server» di ISPConfig smettono di essere la stessa cosa. Un account non è più fissato a una macchina che si può indicare, il che va bene, ma qualsiasi inventario che tiene al di sopra di ISPConfig deve trovarsi a suo agio con un cliente il cui sito web sta su una macchina e le cui caselle di posta stanno su un’altra.

L’API remota, e le due cose da sapere

L’automazione di ISPConfig passa per la sua API remota, disponibile nelle varianti SOAP e JSON. Due proprietà danno forma a tutto ciò che vi si costruisce sopra.

È basata sulle sessioni, non sui token. Si chiama login con nome e password di un utente remoto, si ottiene un session_id e lo si passa a ogni chiamata successiva. La sessione è valida per un tempo limitato. È un ciclo di vita diverso dai token bearer che la maggior parte dei pannelli moderni rilascia: il suo client deve mantenere una sessione, accorgersi di quando è scaduta e rifare il login. E non dovrebbe farlo ritentando alla cieca, perché un ciclo di login su credenziali errate è il modo in cui si finisce bloccati fuori da qualcosa.

I permessi sono per funzione, e vengono controllati. Si crea un utente remoto nel pannello (Sistema, poi Aggiungi utente remoto) e si spuntano le categorie di chiamata che può effettuare. ISPConfig verifica quel permesso a ogni chiamata che riceve.

Quella seconda proprietà è davvero preziosa e vale la pena usarla per bene. Significa che la credenziale che sta nella sua automazione non deve poter fare tutto ciò che ISPConfig può fare. Le dia le funzioni che il suo provisioning chiama davvero e nient’altro, e un errore nel suo stesso codice non potrà raggiungere le parti del pannello che non ha mai avuto intenzione di toccare. Pochissimi pannelli di questa categoria permettono di tracciare quella linea.

Le funzioni stesse si leggono come si spererebbe. I clienti si creano con client_add. I siti web sono sites_web_domain_add, sites_web_domain_update, sites_web_domain_get e sites_web_domain_delete. E, cosa fondamentale per qualsiasi cosa commerciale, c’è sites_web_domain_set_status, un modo reale e supportato per accendere e spegnere un sito web, che è l’unico comando attorno a cui ruota la fatturazione dell’hosting e che diversi pannelli concorrenti semplicemente non hanno.

Cosa comunque non fa

Tutto ciò che precede è infrastruttura. Nulla di ciò è commercio.

ISPConfig non prenderà un ordine, non incasserà un pagamento, non produrrà una fattura, non ne solleciterà una, e non deciderà al trentunesimo giorno che questo cliente ha smesso di pagare e va disattivato. Ha la leva (set_status), ma niente che decida quando tirarla. Non c’è un catalogo con i prezzi, non c’è un flusso di registrazione, non c’è un calendario di solleciti, e non c’è una vista che Le dica quanto le sta costando la sua flotta rispetto a quanto sta rendendo.

Non è una critica. Un pannello di controllo che cercasse anche di essere un sistema di fatturazione sarebbe peggiore in entrambe le cose. Ma significa che il lavoro interessante nel vendere hosting ISPConfig sta interamente nello strato al di sopra, e quello strato è lo stesso che servirebbe per qualsiasi altro pannello:

• Un modulo d’ordine e un catalogo, con piani che corrispondono ai template dei clienti.
• Un pagamento che avvia il provisioning in pochi secondi.
• Un percorso di sollecito (scaduto, avvisato, sospeso, ripristinato), collegato a set_status al passo giusto.
• Una capacità che si può vedere, così da sapere quanti account si portano su tutte quelle macchine e quanto costano.
• Un registro di controllo, così che «chi ha cambiato quel limite» abbia una risposta.
• Un modello di permessi per il suo personale, così che l’assistenza possa agire senza poter eliminare un cliente.

Dove si colloca Provibr

Il supporto per ISPConfig è in produzione. Un agente all’interno della sua rete parla con l’API remota del pannello, così che nulla del suo pannello debba affacciarsi su internet e non serva aprire porte. Creare un cliente con un sito e un piano, sospenderlo, riattivarlo, cambiargli piano e rimuoverlo funziona, gli account già presenti si possono importare, e disco e traffico compaiono nei grafici. Attorno a questo sta lo strato descritto sopra: piani e capacità con un prezzo unitario, un modello di permessi per il suo team, una traccia di attività, e un’API REST e un modulo WHMCS in modo che la piattaforma con cui già fattura possa pilotarlo.

La credenziale custodita nella cassaforte dell’agente può essere molto più stretta di un amministratore, perché ISPConfig concede i suoi permessi remoti funzione per funzione: l’utente remoto si può limitare esattamente alle chiamate che fa Provibr e a nulla di più. Su quale delle sue macchine ISPConfig collochi un sito resta una decisione di ISPConfig, le azioni sull’account sono comunque le stesse, e ogni account conta come un server web nella sua capacità, qualunque macchina finisca per eseguirlo.

Ciò che l’integrazione non fa è toccare gli account che non ha creato lei stessa: quelli restano intatti finché non li importa, ed è lei a scegliere quali. Una nota pratica sulla connessione stessa: un’installazione nuova di ISPConfig è autofirmata, quindi conviene fissarne l’impronta TLS al momento di aggiungere l’integrazione.

Cosa non fa

Gestire gli account non è gestire il pannello. Installare ISPConfig, aggiornarlo, aggiungere server dietro di esso, configurare l’instradamento della posta e occuparsi del DNS: tutto questo resta dalla sua parte, in ISPConfig, dove è giusto che stia. Un cliente che modifica la propria casella di posta lo fa senza che nulla al di sopra del pannello lo sappia o se ne curi.

Non deve standardizzarsi su un solo pannello per mantenere un’unica visione d’insieme. Provibr fa girare oggi i suoi pannelli di controllo, i suoi hypervisor e i suoi pannelli di gioco fianco a fianco, in un solo inventario, con un solo modello di permessi e un solo registro delle attività. Un pannello aperto multiserver per i clienti che vogliono posta e DNS inclusi, qualcos’altro per chi chiede cPanel per nome, e un unico posto da cui vedere entrambi.