Cómo vender alojamiento web con ISPConfig

La mayoría de los paneles de control gestiona un servidor. ISPConfig gestiona un parque: una sola instalación puesta delante de máquinas web, de correo, de DNS y de base de datos separadas, con los sitios y los buzones repartidos entre ellas y una única interfaz sobre el conjunto. Lleva haciéndolo muchísimo tiempo, es de código abierto, y no cuesta nada.

Es también el panel de esta categoría con la idea más completa de lo que es un cliente. ISPConfig tiene clientes, revendedores, límites y plantillas como objetos de primer nivel, lo cual es más de lo que puede decir la mayoría de sus competidores. Lo que no tiene (y esa es toda la razón de ser de una página como esta) es la más mínima noción de un cliente que paga.

Lo que ISPConfig ya ofrece

Tres cosas, y son inusualmente buenas.

Clientes, no solo cuentas. Un cliente ISPConfig es una persona o una empresa que posee cosas: sitios web, buzones, zonas DNS, bases de datos. Esa es la forma que un producto de alojamiento tiene en realidad, y no hay que inventarla.

Límites, y plantillas para aplicarlos. Cada cliente lleva límites: cuántos dominios web, cuántos buzones, cuántas bases de datos, cuánto espacio. Las plantillas de cliente permiten definir un conjunto de límites una vez y aplicarlo a muchos clientes, que es exactamente un catálogo de producto con otro nombre. Un límite de -1 significa ilimitado, algo que conviene saber antes de leer una plantilla y concluir que algo está roto.

Revendedores. ISPConfig entiende que un cliente puede tener a su vez clientes. Si se vende a agencias que venden a sus propios clientes, esa jerarquía existe en el panel en lugar de en una hoja de cálculo que se mantiene al lado.

Entre las tres, esas cosas cubren las partes que la mayoría de los paneles obligan a construir por cuenta propia.

La parte inusual: un panel, varias máquinas

Esto es lo que separa de verdad a ISPConfig de DirectAdmin, cPanel, CloudPanel y los demás.

Una sola instalación de ISPConfig puede pilotar servidores web dedicados, un servidor de correo aparte, servidores DNS aparte y un servidor de base de datos aparte, configurados en modo multiservidor, con réplica disponible para las partes que necesitan redundancia. Cuando se añade un sitio web, ISPConfig lo escribe en la máquina que se supone que debe llevarlo.

Para un proveedor de alojamiento se derivan dos consecuencias. La buena: crecer significa añadir una máquina detrás del panel, no montar un segundo panel y repartir los clientes entre dos sistemas que se ignoran mutuamente. La que hay que prever: la idea propia de «un servidor» y la idea de ISPConfig de «un servidor» dejan de ser lo mismo. Una cuenta ya no está fijada a una máquina que se pueda señalar con el dedo, y no pasa nada, pero cualquier inventario que se mantenga por encima de ISPConfig tiene que llevarse bien con un cliente cuyo sitio web está en una máquina y cuyos buzones están en otra.

La API remota, y las dos cosas que saber de ella

La automatización de ISPConfig pasa por su API remota, disponible en variantes SOAP y JSON. Dos propiedades dan forma a todo lo que se construya sobre ella.

Funciona por sesión, no por token. Se llama a login con el nombre y la contraseña de un usuario remoto, se recibe un session_id, y se pasa con cada llamada posterior. La sesión es válida por un tiempo limitado. Es un ciclo de vida distinto del de los tokens bearer que reparten la mayoría de los paneles modernos: el cliente tiene que mantener una sesión, darse cuenta de cuándo ha caducado, y volver a iniciar sesión. Y no debe hacerlo reintentando a ciegas, porque un bucle de inicio de sesión contra credenciales incorrectas es como se acaba encerrado fuera de algo.

Los permisos son por función, y se comprueban. Se crea un usuario remoto en el panel (System, luego Add Remote User) y se marcan las categorías de llamada que tiene permitido hacer. ISPConfig verifica ese permiso en cada llamada que recibe.

Esa segunda propiedad tiene un valor real y merece usarse bien. Significa que la credencial que reside en la automatización no necesita poder todo lo que ISPConfig sabe hacer. Basta con darle las funciones que el aprovisionamiento llama de verdad y nada más, y un error en el propio código no podrá alcanzar las partes del panel que nunca se pretendió tocar. Muy pocos paneles de esta categoría permiten siquiera trazar esa línea.

Las funciones en sí se leen como cabría esperar. Los clientes se crean con client_add. Los sitios web son sites_web_domain_add, sites_web_domain_update, sites_web_domain_get y sites_web_domain_delete. Y, algo decisivo para cualquier uso comercial, está sites_web_domain_set_status: una manera real y compatible de encender y apagar un sitio web, que es el verbo único en torno al cual gira la facturación de alojamiento y del que varios paneles competidores simplemente carecen.

Lo que sigue sin hacer

Todo lo anterior es infraestructura. Nada de ello es comercio.

ISPConfig no tomará un pedido, no tomará un pago, no producirá una factura, no reclamará ninguna, y no decidirá el día treinta y uno que este cliente dejó de pagar y hay que cortarlo. Tiene la palanca (set_status), pero nada que decida cuándo accionarla. No hay catálogo con precios, ni flujo de alta, ni calendario de reclamación, ni una vista que diga cuánto cuesta el parque frente a lo que ingresa.

No es un reproche. Un panel de control que además intentara ser un sistema de facturación sería peor en ambas cosas. Pero sí significa que el trabajo interesante, al vender alojamiento ISPConfig, está enteramente en la capa de arriba, y esa capa es la misma que haría falta para cualquier otro panel:

• Un formulario de pedido y un catálogo, con planes que encajan con las plantillas de cliente.
• Un pago que dispara el aprovisionamiento en segundos.
• Un proceso de reclamación de impagos (vencido, avisado, suspendido, restablecido) conectado a set_status en el paso correcto.
• Una capacidad visible, para saber cuántas cuentas se llevan a través de todas esas máquinas y lo que cuestan.
• Un registro de auditoría, para que «quién cambió ese límite» tenga respuesta.
• Un modelo de permisos para el propio equipo, para que el soporte pueda actuar sin poder eliminar a un cliente.

Dónde encaja Provibr

La compatibilidad con ISPConfig está en producción. Un agente dentro de la propia red habla con la API remota del panel, de modo que nada del panel tiene que dar la cara a internet y no hay que abrir ningún puerto. Crear un cliente con un sitio web y un paquete, suspenderlo, reanudarlo, cambiarle el paquete y eliminarlo funciona, las cuentas que ya estaban se pueden importar, y el disco y el tráfico aparecen en las gráficas. Alrededor de eso está la capa de arriba: planes y capacidad con un precio por unidad, un modelo de permisos para el equipo, un registro de actividad, y una API REST y un módulo WHMCS para que la plataforma con la que ya se factura pueda pilotarlo.

Las credenciales que guarda la caja fuerte del agente pueden ser mucho más estrechas que un administrador, porque ISPConfig concede sus permisos remotos por función: el usuario remoto se puede limitar exactamente a las llamadas que hace Provibr y a nada más. En qué máquina coloca ISPConfig un sitio sigue siendo decisión de ISPConfig, las acciones sobre la cuenta son las mismas en cualquier caso, y cada cuenta suma un servidor web en la capacidad, sea cual sea la máquina que acabe ejecutándola.

Lo que la integración no hace es tocar cuentas que no se hayan creado con ella: esas se dejan en paz hasta que se importan, y se elige cuáles. Una nota práctica sobre la conexión en sí: una instalación nueva de ISPConfig va autofirmada, así que conviene fijar su huella TLS al añadir la integración.

Lo que no hará

Gestionar cuentas no es gestionar el panel. Instalar ISPConfig, actualizarlo, añadir servidores detrás de él, configurar el enrutamiento del correo y ocuparse del DNS: eso se queda del lado de uno, en ISPConfig, donde le corresponde. Un cliente que edita su propio buzón lo hace sin que nada por encima del panel lo sepa ni le importe.

No hace falta estandarizarse en un solo panel para mantener una única vista de conjunto. Provibr hace funcionar hoy sus paneles de control, sus hipervisores y sus paneles de juego en paralelo, bajo un solo inventario, un solo modelo de permisos y un solo registro de actividad. Un panel abierto multiservidor para los clientes que quieren correo y DNS incluidos, otra cosa para los que piden cPanel por su nombre, y un solo lugar donde ver ambos.