Oct 282013
 

Existe una primera fase en el desarrollo de esta segunda versión de GNUPanel que es la más importante, porque implica la producción de un código totalmente nuevo, diseñado para ser flexible y adaptable.

En el proyecto de financiación propuesto se prevé la creación de un paquete DEB compatible con el sistema Debian. En la práctica esto se traduce como un conjunto de paquetes que se instalan según las necesidades.

Un ejemplo práctico

Resulta esclarecedor dar un ejemplo práctico de un posible uso del programa para entender su funcionamiento.
Una instalación básica del panel de control requiere la instalación mínima de dos paquetes: gnupanel-master y gnupanel-slave (estos nombres pueden modificarse y no deben considerarse definitivos).

Un escenario posible sería contar con dos servidores. Podrían ser dos servidores virtuales de buenas prestaciones, un escenario muy favorecedor por la redundancia, economía, escalabilidad y beneficios a la hora de enfrentar migraciones o recuperaciones.

En el ejemplo del diagrama existe un servidor que podemos llamar master o principal que aloja en forma segura la base de datos, el servicio de DNS y las interfaces ADMIN y USER.
En otro servidor al que podemos llamar slave se alojarán las distintas cuentas de hosting de los distintos usuarios o clientes.

GNUPanel_2_arch

Desde la interfaz ADMIN se podrán definir los planes de hosting que ofrecerá el sistema. Puede haber planes que permitan alojar un solo dominio o planes que permitan alojar decenas o cientos, el menú de variantes se define con absoluta libertad!

Cada usuario o cliente tiene acceso inmediato a la interfaz USER del sistema de hosting al registrarse con una dirección de email. De este modo puede loguearse, elegir entre todos los planes ofrecidos cuál es el que mejor se ajusta a sus necesidades y adquirirlo. Tan pronto realiza el pago puede comenzar alojando uno o varios dominios, todo el proceso es rápido y automático.

Se hace evidente que este modo de funcionamiento permite la creación de planes muy flexibles pero no contempla la existencia de una interfaz tan típica como la que normalmente se denomina RESELLER.

El agregado de esta interfaz se realizará en una segunda fase y se ha planificado asi para acortar el tiempo de desarrollo de una primera versión funcional e instalable. Una empresa que desarrolla sitios web y aloja y mantiene toda su producción puede utilizar el panel de control al culminar la primera fase del desarrollo sin esperar a que se agregue la interfaz reseller.

  6 Responses to “GNUPanel 2.0 – Diagrama de funcionamiento básico”

  1. Me gustaría felicitarles por el trabajo que ustedes están realizando en GNUPanel. Es realmente maravilloso eso de tener un panel de control verdaderamente libre.

    Espero no sonar engreído con esta propuesta. No es mi intención serlo. Es mas, estaría incluso dispuesto a ayudar bajo sus órdenes.

    Lo que si me gustaría apuntar es que dicha estructura no significa en realidad un sistema multiservidor. Mas bien, representa una colección donde tenemos mas de un busybox, donde posiblemente cada busybox sirva a mas de un cliente.

    Aquí pueden ver como sería una arquitectura multiservidor que yo les propongo: Dibujo de OpenDoc | PDF.

    En cada recuadro con sombra, puede ser provisto por uno o más servidores a elección del cliente.

    Espero que puedan ver claramente las ventajas que esta arquitectura tendría, sobre la que propusieron ustedes. Pero primero las desventajas.

    La única desventaja que se me ocurre es facilidad de instalación. El panel terminaría con unos paquetes con nombres como gnupanel-admin, gnupanel-user, gnupanel-postgres, etc. Pensandolo bien, esto se podría solucionar con dos metapaquetes, gnupanel-server y gnupanel-busybox.

    Si se me ocurren varias ventajas del sistema:

    * El uso de LDAP significa que los servidores tendrán sus cuentas sincronizadas a través de todos los servidores.

    * Ya existen algunos módulos que están diseñados de fábrica ha operar en un sistema multiservidor, como lo son: PostgreSQL, MySQL, Apache y el OpenLDAP. Posiblemente, también lo estén el Postfix y el ProFTPd.

    * Generará robustez al sistema, añadiendo resistencia contra fallos será pan comido (digerido y defecado 😉 ),

    * Añadirá flexibilidad al sistema… Junto con un sistema de plugins (programado) será posible, por ejemplo, cometer agregarle servidores para otros tipos de bases de datos, correo, servidores web, etc.

    * Como parte de esta flexibilidad, será posible agregar servidores Microsoft a la mezcla y habilitar cualquiera de sus tecnologías (IIS, .NET, etc). Claro que esto debería figurar como la segunda y mas grande desventaja. ¿No volvería esto a GNUPanel mas agradable a los ojos de los usuarios?

    Esto es lo que pude pensar rápidamente. Tal vez haya mas, ventajas y desventajas.

  2. Entiendo.

    No estoy deacuerdo con lo del exceso del presupuesto…Ya que la mayoría de los módulos ya básicos ya son multiservidor: PostgreSQL, MySQL, Apache, OpenLDAP, y Postfix, los que no sé a ciencia cierta son el CLAMAV, SPAMd, y el ProFTPd… Pero se podría encargar de cuanto máximo uno de estos servidores por dominio fácilmente.

    Solo tendrían que tocar un poco sus archivos de configuración con un interface web.

    Pero lo entiendo. Muchas gracias. Tal vez para GNUPanel 3.0.