Blogia

cubacms

CMS distribuido, solucion multisitio.

Cuando escuche por primera vez lo de CMS distribuido no comprendí de inmediato a que se referían, no se quien haya acuñado el mismo, pero se lo escuche por primera vez a Carlos Manuel, luego entre Victor Ricardo y CM me hicieron entender el concepto que tenia en mente, un cms capaz de funcionar con el menor numero de aditamentos posibles y con la capacidad de adicionarles modularmente cualquier funcionalidad que se requiriera, tato del punto de vista de administración como de usuario, visto asi no dice mucho, pero cuando uno trabaja con herramientas como esta, sabe lo importante que es poder controlar el programa con el menor esfuerzo posible.

El cms en su concepción mas básica debe ser capaz de instalarse y ponerse a producir en pocos minutos, de hecho la gran mayoría de ellos, ya sea para sitios, blogs, wikis foros etc lo hace, uno lo instala y enseguida debería poder estar colocando contenido con una presentación mas o menos presentable desde el punto de vista de navegabilidad, presentación y funcionalidad, por eso es tan popular y una primera opción cuando el que utiliza la herramienta no posee conocimientos de informática. Para los sitios grandes también se esta convirtiendo en una buena opción pues ha alcanzado un nivel de madurez que lo colocan a la par de herramientas “profesionales”
La primera división que podemos hacer en los cms es si son propietarios o SL, el primero no entrega el código fuente por lo tanto no lo podemos ver es decir en si no sabemos exactamente que puede hacer o lo que es peor no podemos controlar cuando no queremos que haga algo o incluso realmente no hace eso que nos prometieron que no haria?? Además lo programan, mantiene/actualizan 10 o 50 programadores diseñadores, desarrolladores, es decir un sola vision una sola forma de pensar etc que conlleva un reducido grupo de personas a las cuales les pagan por hacer eso. No lo pueden poner a consideración de otros usuarios, programadores desarrolladores, otros puntos de vista, otros enfoques, la retroalimentación se traduce en la que puedan establecer ente desarrolladores clientes.

La segunda división podría ser la de si esta escrito en php o no. Porque php?? porque la inmensa mayoría de los cms esta escrito en este lenguaje de programación, sea o no el mejor lenguaje, es el mas popular para los servicios web. Existen cms desarrollados en otros lenguajes mucho mas potentes, robustos, elegantes etc, pero son la minoría, el lenguaje mas popular es y por algún tiempo (parece ser segun la tendencia en los cms) sera php. Esto garantiza que si el lenguaje es popular aunque no sea el mejor, que mas gente lo este probando agregando cosas, desarrollando aplicaciones, encontrando fallos, etc

La tercera división es si usa bases de datos dinámicas para guardar la información del sitio y su contenido facilitando su integralidad, seguridad, pequeño espacio de almacenamiento, rapidez y posibilidad de hacer múltiples consultas de muy diversas maneras o utiliza archivos estáticos de manera poco segura, lenta y ocupando mucho espacio.

La cuarta división posible es la orientación del cms, en este caso encontramos 2 grandes tendencias, una es la orientada a sitios pequeños, no extensibles, muy ligeros. Generalmente pensado para clubes, intranets, asociaciones etc.

La otra tendencia es a sitios “duros” que necesitan grandes portales y en muchos casos multisitios y con la idea de ganar un mercado compitiendo con los cms “profesionales” de pago.
Una subdivisión de esto seria que comparten estos multisitios; carpetas, bases de datos, temas, funcionalidades, o si el multisitio es modular (es una funcionalidad) que no requiere de tocar nade de código del core. La idea es tener un solo sistema base y que el resto de sitios use ese sistema, pero los temas, bases de datos y funcionalidades sean independientes de ese sistema base, esto lleva a que se pueda actualizar el sistema sin que se afecte al resto de sitios. Si no es modular, (osea requiere hacer adecuaciones al core, tocando su código) a la hora de actualizar hay que volver a tocar el código con la posibilidad de que esta adecuación que se usaba no funcione en la nueva versión, obligándonos a retrasar el upgrade hasta tanto no implementemos nuevamente la posibilidad de multisitio, con el consecuente peligro que esto entraña si la actualización es de seguridad ante problemas conocidos y publicados.

Otra división tiene que ver con el mantenimiento del sistema, un sistema con una comunidad estable y con muchos programadores detras puede estar mejorando el producto constantemente y esto se ve reflejado en que las actualizaciones y parches de seguridad asi como la optimización del sistema, para hacerlo mas rápido, potente, estable y bonito es constante, además que las funcionalidades y temas se estan actualizando constantemente a las nuevas versiones.

Los cms cuentan con 3 grandes partes, una el sistema base como tal, donde se define la estructura del sitio y su apariencia, la otra son las bases de datos que se relacionan con el sistema (aquí es donde esta la información) y la otra son las extensiones que facilitan el uso del sistema. cuando se upgradea el sistema base es el que se mejora, posteriormente los temas se adecuan a la nueva versión (si esta es importante e incompatible con la anterior) y también las funcionalidades.

Resumiendo, el cms debería tener las siguientes caracterizticas:

- Software Libre
- Escrito en lenguaje PHP
- Bases de Datos dinámicas (MySql, PostgreSql, Sql)
- Multisitio con un solo core con bases de datos independientes físicamente entre si
- Comunidad estable, con una buena calidad de código y periódicas actualizaciones, tanto en prestaciones como seguridad.

 

ademásdebe responder a estos parámetros:

Curva de aprendizaje:
se podría interpretar de tres maneras; una para el usuario otra para el administrador y la ultima para el desarrollador. La curva de aprendizaje del sistema debe ser baja, y si no fuera asi, debería de poder ser “bajada” por el administrador y desarrollador con un mínimo de recursos y relativa facilidad, ya que en ultimas son ellos los que tiene que llevar la mayor carga de trabajo en la usabilidad del sitio y el acceso a la información.

Calidad del código:
El código debe ser bien estructurado, ampliamente documentado, fácil de entender, logico y seguro. Debe tener una estructura tal que cualquiera pueda modificarlo y extenderlo de acuerdo a las necesidades del sitio, que las extensiones (módulos, mambots, plugins etc) deben de estar separadas del core (corazón del sistema) permitiendo que un extensión no afecte al sistema ya sea por incompatibilidad, mal funcionamiento etc.

Extensibilidad
Debería ser alta, es decir que el sistema mínimo básico para que funcione (core) debería ser lo mas pequeño posible y que todo el resto de funcionalidades (módulos, plugins, etc) para agregar información y presentarla, sea independiente, garantizando con ello estabilidad en el sistema.

Cohesividad:
La unión de las partes nos debe dar un todo coherente y estable. Tiene que ser funcional el sistema a pesar de quitarle o agregarle funciones, además se deben usar los mismos términos y conceptos sin importar que estemos en una pagina, un tema o una funcion especifica, estandarizar las forma de hacer las cosas, temas, plantillas, módulos, paginas, etc le permite al usuario o al administrador sentirse cómodo y en el mismo ambiente en todo momento.

Funcionalidades extras:
La determinan la popularidad del CMS ya que los grandes contribuyentes de funcionalidades son terceros (comunidad). En la medida que la comunidad de usuarios del cms crece también crece el numero de demandas de mas funcionalidades y también el numero de aportes de funcionalidades extras. Además la orientacion del cms determina la calidad de dichas funcionalidades, asi un cms muy popular pero orientado a sitios muy “ligeros” y pequeños sin grandes pretensiones y carga de información, nos devolverá baja calidad de la funcionalidad, tanto como en pretensiones como seguridad y calidad de la programación, redundando en mayores problemas a la hora de implementarlas en nuestros sitios.

Temas:
Que posea temas estructurados y lo mas estándares posibles, permitiendo su reutilización y acomodo a nuestras posibilidades. También es deseable una buena cantidad de ellos disponibles para su uso.

En cuanto a las funcionalidades y los temas, lo mejor seria que respondieran a una lógica y estructura única, una forma estándar de hacerlos, con ello se garantiza que cualquier desarrollador en pocas horas podría crear uno de cero o adecuarlo a sus necesidades.

Sin importar cual sea la aplicación que se elija debería enmararse dentro de estos parámetros, pues nos garantizaría un producto fácil

Instalar Drupal multisitio en Debian Etch

Primero que nada nos bajamos drupal.

-crear una carpeta dentro de /sites/ ejemplo: /sites/cardiologia.com es importante que la carpeta tenga un nombre significativo al sitio, porque drupal prioriza y busca esto, es decir poner www.sitio.com o lago asi. Dentro de esta carpeta colocar un settings.php copiado de la carpeta /sites/default/settings.php y ahi ccambiar la siguiente linea:
$db_url = 'mysql://usuario:password@servidor(localhost generalmente)/BD_nombre';
y poner los parametros de tu servidor mysql y el nombre de la base de datos.
'mysql://root:password@localhost/cardiologia';

-crear una base de datos vacia con el nombre que pusiste en la la line anterior

-añadir tu url al host para que sea visible en tu equipo.

127.0.0.1 localhost rodrigof
127.0.1.1 rodrigof

#locales maquina rodrigo
127.0.0.1 www.cardiologia.sld.cu -->aqui es donde esta definido el virtualhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

- crear un virtualhost que tenga la carpeta root apuntando a la instalación de drupal no a la carpeta que acabas de crear, ya que esta carpeta tan solo tienen el settings.php. Esto es importante porque cuando pongas la url ej www.cardiologia.com/install.php te dara pagina no encontrada Guardarlo en la carpeta /etc/apache2/sites-available con un nombre significativo, ej cardiologia.com


ServerAdmin rodrigof@infomed.sld.cu
ServerName www.cardiologia.sld.cu
DocumentRoot /var/www/drupal1/ -->nombre de la carpeta donde esta la instalacion de drupal

Options FollowSymLinks
AllowOverride None


Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
#RedirectMatch ^/$ /apache2-default/


ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all


ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access.log combined
ServerSignature On

Alias /doc/ "/usr/share/doc/"

Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128




este es una copia funcional del default con todo lo que trae, tan slo se ha cambiado los parametros para que busque en tu nuevo sitio, deberias editarlo para quitar cosas que crees que sobren.

-desde la consola de comandos: a2ensite cardiologia.com con esto estas habilitando tu sitio, o lo que es lo mismo creando un enlace directo dentro de la carpeta sites-enabled que es donde estan todos los sitios habilitados dentro del apache

-No olvides recargar el apache poniendo en la consola: /etc/init.d/apache2 reload para que los cambio sean efectivos

- en el navegador web pon la direccion de tu sitio virtual ej: www.cardiologia.com/install.php debería aparecer el instalador de drupal como un sitio nuevo, si es asi todo ha funcionado perfectamente.