Instalación de un servidor Openmeetings en Debian 6 Squeeze.

En un artículo anterior expliqué cómo instalar un servidor OpenMeetings en un PC con Windows, con el objetivo de disponer de una instalación que nos permitiera evaluar el producto y aprender su funcionamiento básico sin tener que complicarnos la vida con instalaciones en entornos linux, que para muchos, por desconocimiento del mismo, suponen un esfuerzo añadido.

Este artículo va dirigido a aquellos que finalmente han decido que el producto vale la pena y que desean instalar un servidor de videoconferencia en producción y que, como no podría ser de otra manera, van a hacerlo con linux.

Aunque en este blog se ha hablado en algunas ocasiones de este sistema operativo, quiero dejar claro que mi conocimiento y habilidad en el manejo del mismo es limitada y que cualquier operación un poco compleja requiere por mi parte de continuas y numerosas consultas a la documentación del distro utilizado y a los foros especializados donde gracias a usuarios más expertos que yo y que comparten sus conocimientos he podido salir a delante en este proyecto.

Dado el carácter divulgativo de este blog es posible que lo que en principio puede parecer un inconveniente (alguien que dice que no sabe lo suficiente de linux explicando cómo hacer la instalación de un producto complejo como Openmeetings) en realidad pueda ser una ventaja, ya que el punto de de vista de un “no experto” seguramente puede abordar el reto con un poco más de pragmatismo y con un espíritu más didáctico al no dar nada por hecho de antemano.

Para hacer la instalación de OpenMeetings en linux he elegido Debian 6 (Squeeze). 

Inicilamente he instalado el sistema operativo básico; esta instalación no tiene ningún secreto y hay documentación suficiente en la red para que no sea necesario que dedique tiempo a la misma.

Posteriormente he ido añadiendo los diferentes productos necesarios para la instalación de OpenMeetings; la lista de estos productos ya se comentaron en otro articulo anterior y recomendaría al lector que lo leyera previamente.

Para instalar cualquier producto en Debian 6 debemos hacerlo desde una consola de administrador, que podemos abrir desde la opción de menú:

Aplicaciones – Accesorios – Terminal de “Root”

El comando que permite instalar aplicaciones en Debian es

#aptitude install <aplicación1> <aplicación2> ….. <aplicaciónN>

Recordemos que en linux cada aplicación depende de una serie de paquetes que si no están instalados, el sistema los busca e instala de los repositorios externos que utiliza la distribución correspondiente

Sobre los repositorios a utilizar, además de los estándar que ya vienen configurados en Debian 6 debemos añadir algunos más que serán necesarios durante el proceso de instalación de algunos de los paquetes que necesitamos. Por lo tanto, modificaremos el archivo que mantiene la lista de repositorios.

# gedit /etc/apt/sources.list

de manera que quede así

deb http://ftp.es.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.es.debian.org/debian/ squeeze main contrib non-free

deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free

# squeeze-updates, previously known as 'volatile'
deb http://ftp.es.debian.org/debian/ squeeze-updates main
deb-src http://ftp.es.debian.org/debian/ squeeze-updates main

## Añadido Multimedia Estable
deb http://www.debian-multimedia.org squeeze main

Una vez hecha la modificación debemos ejecutar

# aptitude update

para actualizar la lista de paquetes disponibles.

También instalaremos los paquetes necesarios para poder instalar después aquellas aplicaciones que no están en los repositorios y que necesitan un proceso manual que utiliza la secuencia de instrucciones ./configure – make – make install

# aptitude install libncurses5 libncurses5-dev build-essential

Como último paso, elegiremos una carpeta de maniobra para la descarga y manipulación de estas aplicaciones, por ejemplo, la carpeta de usuario

/home/<usuario>

Empezaremos por mencionar las aplicaciones que no requieren instalación porque ya han sido instaladas inicialmente junto con el sistema operativo

• OpenOffice
• ImageMagick
• Ghostscript

Comprobar que tenemos instalado OpenOffice es sencillo, pero si queremos verificar que ImageMagick y Ghostscript lo están, podemos hacerlo con estos comandos que nos deben dar un resultado positivo (“Estado: Instalado”)

# aptitude show imagemagick | grep instal

# aptitude show ghostscript | grep instal

Comenzaremos por instalar Java JDK, paquete necesario para la ejecución de OpenMeetings. Debemos tener en cuenta diversos aspectos sobre Java aplicado a OpenMeetins

• Desde la compra de SUN por parte de Oracle, por políticas de licencias de esta compañía,  Java de Sun ya no está disponible en muchos de los repositorios de las diferentes versiones de linux y terminará por desaparecer de todos ellos.
• Existe una versión "open" de java denominada OpenJDK (openjdk-6-jdk) . Esta versión se puede instalar a partir de los repositorios de Debian mediante los mecanismo internos como el comando "aptitude install", pero a día de hoy, OpenMeetings no está preparado para trabajar con esta versión, lo que seguramente ocurrirá en un futuro cercano.

Tras diversas pruebas realizadas con las dos versiones de Java JDK la solución la hemos encontrado en la instalación manual del Java de Sun en su versión 6.

Para instalar debemos realizar los siguientes pasos 

• Descarga del archivo jdk-6u31-linux-i586.bin de la web de Oracle www.oracle.com/technetwork/java/javase/downloads

• Creación de un directorio para Java

# mkdir /usr/lib/java

• copia al directorio de  java, asignación de permisos de ejecución  y ejecución del archivo descargado

# cp /<directorio descarga>/jdk-6u31-linux-i586.bin /usr/lib/java

# chmod +x /usr/lib/java/jdk-6u31-linux-i586.bin

# ./jdk-6u31-linux-i586.bin

• añadir variables de entorno de Java en los archivos /roor/.bashhrc y /home/<usuario>/.bashrc

  # gedit /root/.bashrc y # gedit /home/<usuario>/.bashrc

Añadir las siguientes líneas a los archivos anteriores

export JAVA_HOME=/usr/lib/java/jdk1.6.0_31
export PATH=$JAVA_HOME/bin:$PATH

Arrancamos la máquina y comprobamos la correcta instalación de Java mediante el comando

# java -version

Una vez instalado Java ya podemos comenzar a instalar las aplicaciones que están en los repositorios de Debian                                    

# aptitude install flashplugin-nonfree                              (Adobe Flash)

# aptitude install ffmpeg                                                        (FFMpeg)

# aptitude install sox                                                               (SoX)

Seguidamente debemos instalar SWFTools, que por algún motivo que desconozco no está disponible en los repositorios de Debian 6 y que deberemos descargar y compilar manualmente

En primer lugar instalamos los paquetes de los que SWFTools depende y que deben estar instalados previamente

# aptitude install zlib1g-dev

# aptitude install libfreetype6-dev

# aptitude install libgif-dev

# aptitude install libjpeg62-dev

Descargamos el paquete de SWFTols en nuestra carpeta de maniobra, lo descomprimimos y lo instalamos.

#wget http://swftools.org/swftools-0.9.1.tar.gz

#tar -xf  swftools-0.9.1.tar.gz

# cd swftools-0.9.1

# ./configure

# make

# make install

Para comprobar que la instalación ha sido correcta podemos ejecutar el comando

# pdf2swf

que deberá dar la una salida válida mostrando las opciones del comando.

Una vez instalado el software previo, vamos instalar el gestor de base de datos, que en nuestro caso será MySQL.

# aptitude install mysql-server

En el proceso de instalación nos pedirá una contraseña para el usuario administrador (root) de MySQL.

Seguidamente crearemos una base de datos de nombre openmeetings con un usuario de nombre openmeetings y contraseña openmeetings. Utilizaremos los siguientes comandos.

# mysql -p -u root

mysql> CREATE DATABASE openmeetings DEFAULT CHARACTER SET 'utf8';

mysql> GRANT ALL PRIVILEGES ON openmeetings.* TO 'openmeetings'@'localhost' IDENTIFIED BY 'openmeetings' WITH GRANT OPTION;

mysql> exit

Con toda la infraestructura lista, ya podemos descargar, descomprimir y colocar la aplicación Openmeetings (y el servidor red5) en la carpeta adecuada.

# wget http://openmeetings.googlecode.com/files/openmeetings_1_9_1_r4707.zip

# unzip openmeetings_1_9_1_r4707.zip

# mv red5 /usr/lib

Quitamos permisos innecesarios y damos permisos de ejecución al script principal de red5 y al script de conversión de documentos OpenOffice

# chown -R nobody /usr/lib/red5

# chmod +x /usr/lib/red5/red5.sh

# chmod +x /usr/lib/red5/webapps/openmeetings/jod/jodconverter2.sh

El siguiente paso es configurar OpenMeetings para que trabaje con la base de datos MySQL que creamos anteriormente. Para ello es necesario cambiar el archivo de configuración del arranque de OpenMeetings

/usr/lib/red5/webapps/openmeetings/WEB-INF/classes/META-INF/persistence.xml

Originalmente este archivo está configurado para trabajar con la base de datos Apache Derby que viene en el paquete red5+openmmetings

Dado que Openmmeetings nos proporciona modelos de configuración para cada tipo de base de datos soportada, renombramos el archivo original y copiamos el archivo de configuración correspondiente a MySQL

# cd /usr/lib/red5/webapps/openmeetings/WEB-INF/classes/META-INF

# mv persistence.xml apachederby_persistence.xml

# cp mysql_persistence.xml persistence.xml

Editamos el fichero de configuración

# gedit persistence.xml

y modificamos las líneas donde figuran los datos de conexión del usuario que asignamos a la base de datos cuando la creamos

, Username=openmeetings

, Password=openmeetings “/>

Solo nos queda arrancar el servidor. Para hacerlo manualmente deberíamos ejecutar el script

/usr/lib/red5/red5.sh

y lanzar OpenOffice como servicio, mediante el comando

soffice -headless -nologo -nofirststartwizard -accept="socket, host=127.0.0.1, port=8100;urp"

Ahora bien, lo que necesitamos es que estos procesos arranquen automáticamente cada vez que arrancamos la máquina. Para ello, deberemos crear un script de autoarranque para cada servicio; en la red podemos encontrar numeros scritps, pero muchos de ellos no funcionan correctamente, por lo que hemos preferido crearlos por nosotros mismos basándonos en los ya exitentes y simplificándolos al máximo


Al script de arranque de red5 le hemos llamado red5 y tiene el siguiente contenido

# !/bin/sh
# /etc/init.d/red5

case "$1" in
  start)
    cd /usr/lib/red5
    sudo sh red5.sh
    ;;
  stop)
    cd /usr/lib/red5
    sudo killall java
    ;;
  esac

Al script de arranque de OpenOffice le hemos llamado openoffice y tiene el siguiente contenido

#!/bin/bash
# /etc/init.d/openoffice

case "$1" in
  start)
    cd /usr/lib/openoffice/program
    sudo soffice -headless -nologo -nofirststartwizard -accept="socket,host=127.0.0.1,port=8100;urp" & > /dev/null
    ;;
  stop)
    sudo killall soffice
    ;;
  esac

Debemos guardar los scripts en la carpeta /etc/init.d, que es donde Debian guarda los scripts que se ejecutan durante el arranque de la máquina,  darles permisos de ejecución y añadirlos al proceso de arranque

# cd /etc/init.d

# chmod +x /etc/init.d/red5

# update-rc.d red5 defaults

# chmod +x /etc/init.d/openoffice

# update-rc.d openoffice defaults

Ahora debemos reiniciar el sistema con el fin de comprobar que todo el proceso funciona adecuadamente.

Desde el navegador ejecutamos el proceso de instalación inicial de la aplicación.

http://localhost:5080/openmeetings/install

Debemos cumplimentar un formulario donde debemos indicar los datos del usuario administrador de OpenMeetings, la zona horaria y un nombre para nuestra organización. También podemos definir el idioma por omisión; en el caso del español, veremos que la aplicación está parcialmente traducida y que faltan muchas cadenas por traducir. El resto de las opciones las podemos dejar para más adelante.

Hasta aquí esta guía que espero sea de utilidad, sobre todo a aquellos que no están familiarizados con el sistema operativo linux.

Le puedo asegurar que el procedimiento aquí explicado ha sido testeado cuidadosamente y que funciona, pero he de decir que OpenMeetings es un programa complejo de instalar y que cualquier cambio de versión de cualquiera de los productos implicados puede generar problemas o modificar algún aspecto de este procedimiento; seguro que en algún momento le surgirá alguna dificultad; le sugiero que para resolverla haga como yo, recurra a la documentación existente en internet y los foros de la comunidad. He aquí la dirección del foro en español.

http://groups.google.com/group/openmeetings-en-espanol

Aspectos a tener en cuenta a la hora de seleccionar hosting para alojar Moodle.

Una de las preguntas recurrentes en los foros de Moodle es ¿qué alojamiento web me aconsejan?. Es la pregunta normal de aquellos formadores que deciden abordar la instalación de una plataforma propia para la impartición de sus cursos, de aquellas empresas de formación que deciden implementar una plataforma e-learning como un elemento más de su negocio o incluso de aquellas empresas que deciden implementar esta herramienta para gestionar a nivel interno la formación de sus empleados.

En estos mismos foros las respuestas, con la mejor de las voluntades, se basan normalmente en la experiencia personal de quien ha contratado anteriormente a un proveedor de hosting (o a varios diferentes); así, si alguien ha quedado insatisfecho con cualquiera de los aspectos del servicio prestado por una determinada compañía o considera que el rendimiento de su sitio es inadecuado o si tiene más problemas de tipo técnico que los que está dispuesto a asumir, no recomendará de ninguna de las maneras los servicios de esta, y si por el contrario, no tiene problemas con su hosting actual y las cosas le funcionan razonablemente bien, dirá maravillas de si proveedor actual y lo recomendará sin ninguna duda.

Desde mi punto de vista este tipo de opiniones deben ser atendidas con muchas reservas ya que no tienen en la mayoría de las ocasiones argumentaciones objetivas y sobre todo, no se apoyan en información suficiente que me permita comparar la situación que describen con las condiciones del servicio de la persona que pide consejo.

Por poner un ejemplo en otro ámbito de la vida cotidiana, es como si alguien dijera en un foro que quiere comprarse un coche y pide que le aconsejen sin dar más información. Así, alguien le contesta con la mejor voluntad del mundo, que el modelo XXX no se lo recomienda porque consume mucho a 200km/h, otro le dice que el está muy contento con su pequeño YYY porque aparca en cualquier sitio, un tercero le comenta que está harto del modelo ZZZ que compró a buen precio a un fabricante ucraniano porque no tiene servicio técnico cerca de su domicilio, un cuarto no le recomienda un deportivo porque tiene el maletero pequeño, para que finalmente el último en entrar en el foro sentencie que lo mejor es ir en moto y que a él le va muy bien sin tener coche.

En muchas ocasiones me han pedido mi opinión al respecto y la verdad sea dicha, nunca he dado una respuesta directa, que es lo que esperaba mi interlocutor, sino que siempre le he preguntado para qué necesita el el coche (léase hosting), por donde conduce habitualmente, si le importa el consumo y si necesita o no maletero para ir a la playa con la familia.

Dicho esto, creo que se entiende que para poder establecer qué hosting necesito para alojar mi Moodle, he de establecer primero las necesidades reales que debo cubrir y abrir un proceso de selección con un poco de método, que intentaré explicar aquí.

Lo primero que hemos de hacer es elaborar una lista de proveedores de hosting de los que tenga alguna referencia, bien porque los conozca de otros proyectos, bien porque me los hayan recomendado, bien porque tengan una cierta cuota de mercado y un cierto renombre (un buscador de internet puede ayudar). Y así, empezaremos un proceso de filtraje.

En primer lugar deberé tener claro qué versión de Moodle voy a instalar y cuales son sus requisitos previos de infraestructura, algo que cada versión de Moodle refleja en su documentación técnica. En este aspecto, deberemos tener en cuenta que nuestro proveedor de hosting soporte las versiones de PHP, Apache y MySQL mínimas requeridas por la versión de Moodle a implementar. El mayor problema actual es que aún hay proveedores de hosting que no han migrado la versión de PHP 5.3.2 o superior requerida por Moodle 2.x .

• Quedan por lo tanto descartados aquellos proveedores que no tengan LAMP como uno de los estándar de su infraestructura (Linux, Apache, MySQL y PHP). Es posible instalar Moodle sobre Windows, (en este blog se ha hablado mucho de ello) pero el rendimiento, a igualdad de condiciones, es siempre superior en Linux.
• Quedan descartados aquellos proveedores que no garanticen las versiones correctas de LAMP y que no se comprometan a actualizar razonablemente estas según progresen los requerimientos de Moodle en el futuro.

Otro aspecto a tener en cuenta es que Moodle necesita una configuración determinada de PHP, lo que muchos proveedores de hosting no facilitan argumentando problemas de seguridad. Mencionaremos varios aspectos a tener en cuenta

• La carpeta de archivos moodledata, por requerimiento de Moodle, no debe estar ubicada en la carpeta pública web, sino fuera de esta. Si el proveedor no nos permite hacerlo, no podremos instalar Moodle en nuestro hosting. (Puede darse el caso de que nos permita la excepción pero a cambio de no responsabilizarse de futuros problemas, con lo que quedaremos un tanto desasistidos).
• Moodle necesita tener activadas una serie de librerías PHP. La activación de estas librerías es muy sencilla ya que se realiza modificando el archivo php.ini, al que normalmente no tenemos acceso en un hosting. Esto significa que tenemos que verificar antes de contratarlo que nuestro proveedor va a facilitarnos las modificaciones pertinentes en la configuración de PHP.
• Lo mismo sucede con otros parámetros que se configuran en PHP o incluso en Apache, como son la memoria límite de PHP (más adelnate lo comentamos con más detalle)  o el tamaño máximo de archivos a subir al servidor.

Ya tenemos otro filtro a aplicar.

• Quedan descartados aquellos proveedores que no garanticen flexibilidad en la configuración de Apache, MySQL y PHP para que esta se adapte a los requerimientos de nuestra versión de Moodle. En resumen, debemos eliminar de nuestra lista de posibles proveedores a aquellos que no estén focalizados en proporcionar hosting en entorno PHP, y dentro de lo que lo estén, primaremos siempre a aquellos que estén especializados.

El siguiente paso es analizar que tipo de pack (conjunto de servicios) vamos a contratar. Cada proveedor tiene sus ofertas y no todas son adecuadas para nuestro objetivo y es posible que los datos y valores aportados nos lleven a confusión. En esta fase le recomendamos que no se fije en el precio; preguntese para qué quiere un hosting barato en el que sus alumnos se desesperan porque es lento y pesado y acaban abandonando sus cursos. El tema del precio ya llegará.

Debemos saber qué necesitamos para descartar aquellos packs, sean del proveedor que sean, que no cubran estas necesidades. Debe determinar cuántos cursos va a alojar y sobre todo, cuántos alumnos van a trabajar sobre la plataforma, y algo importante, cuántos van a hacerlo previsiblemente de forma concurrente, lo que condicionará los requerimientos hardware necesarios.

En Moodle no hay una referencia clara para establecer requerimientos de capacidad de procesamiento, espacio en disco y sobre todo de memoria, que se ha demostrado que es un elemento limitante en lo que a rendimiento se refiere. Todo va a depender del tipo de carga que le demos al servidor; por ejemplo:

• Si nuestra política es subir todos los archivos (documentos, vídeos, imágenes,...) al servidor en vez de colgarlos en repositorios externos y acceder a ellos mediante enlaces, los requerimientos de espacio disco se incrementarán según el volumen de datos que vayamos a subir.
• Si los archivos a servir desde el servidor consumen muchos recursos, como es el caso de los vídeos,  necesitaremos más capacidad de proceso y más memoria, y aumentaremos el tráfico de red (Transferencia).
• Si tenemos 200 usuario concurrentes necesitamos un servidor más potente, sobre todo en memoria, que si tenemos 500 pero que solo concurren en el tiempo 50.

Por lo tanto, a la hora de seleccionar un pack de servicios, en el tema del espacio hemos de contemplar aspectos como el volumen de archivos que tenemos previsto subir al sitio, la política de backups, ya que los archivos de backup almacenados también cuentan y mucho, y el tamaño esperado para la base de datos, algo que no es siempre fácil de calcular ya que la experiencia dice que la base de datos de Moodle crece de forma exponencial.

Respecto a la tasa de transferéncia, deberemos evaluar el volumen de datos transferidos desde o hasta el sitio Moodle, según el núemro de usuarios previstos y el tipo de actividad que esperamos que desarrollen, algo que no siempre es fácil de hacer.

Si nos psamos tanto en el espacio de disco utilizado o en la transferencia de datos tenemos que saber cómo actuará nuestro provedor, con cuanto tiempo nos avisará, si sufriremos penalización económica (en algunos proveedores la penalización supera el coste del hosting, lo que si no es ilegal, al menos creo que es inmoral) o en qué condiciones podremos pasar a un pack superior (a veces los packs más económicos sirven de promoción del proveedor, con el fin de qe el cliente pase tarde o temprano a un pack superior cuyo precio ya no es tan competitivo)

 
A la hora de elegir y debido a la tecnología que subyace bajo Moode, lo más importante a la hora de seleccionar un pack de servicios de hosting es la disponibilidad de memoria RAM; cuanta más mejor. De todas maneras, un punto de referencia lo encontramos en la documentación de Moodle

http://docs.moodle.org/20/en/User_site_capacities

donde viene a decir que la media a considerar es que 50 usuarios concurrentes necesitan 1Gb de memoria, si bien esto variará según otros parámetros como el tipo de operaciones que realicen la velocidad de proceso o los límites de accesos a la base de datos.

Pero el tema de la memoria en un hosting no acaba aquí. Los scripts que se ejecutan en PHP consumen memoria y el consumo máximo permitido para cada script se define en un parámentro del archivo de configuración php.ini. Cada versión de PHP tiene unos requerimientos o recomendaciones a seguir, que pueden variar según el tipo de aplicaciones que se esté ejecutando. Para PHP 5.3, la versión requerida por Moodle 2.x, el valor recomendado es de 128 Mb y la mayoría de los proveedores lo tienen configurado así, aunque se dan casos en que los valores son más bajos y aparecen problemas con determinadas operaciones que consumen mucha memoria como es el caso de los backups.Valores más altos, por norma general, tampoco garantizan un mejor rendimiento, aunque no existe mucha documentación al respecto.

A la hora de negociar con un provvedor, si le pedimos que nos garantice determinados niveles de servicio, como la capacidad de proceso o la memoria,  no siempre es posible que lo pueda hacer, ya que dependerá del tipo de servidor o máquina que queramos contratar. Debemos hablar de tres tipos de servidores de hosting:

• Una Máquina compartida es un servidor físico pero que se comparte entre varios clientes. En este tipo de hosting los usuarios comparten los recursos del servidor, pudiendo alojarse desde unos pocos sitios web hasta cientos de ellos. En esta situación es difícil que el proveedor pueda garantizar unos mínimos en cuanto al uso de recursos, ya que el rendimiento no solo depende de nuestra actividad sino de lo que hagan los otros huéspedes de nuestra máquina, lo cual desconoceremos siempre. Es en este tipo de alojamiento en el que los proveedores serán más insensibles a nuestras peticiones de cambios de configuración, ya que, por un lado, no todos los cambios pueden aplicarse de forma diferenciada a un determinado cliente, y por otro, dar más recursos a uno puede ir en detrimento de los otros. Es uno de los más utilizados actualmente, sobre todo porque permite precios muy bajos.
• Una Máquina virtual (VPS) es otra manera de compartir los recursos de un servidor entre varios clientes, pero garantizando unos mínimos recursos a cada uno. La máquina virtual simula un servidor propio con su propio dimensionamiento hardaware, su propio sistema operativo y su propio software.
• Una Máquina dedicada: es una máquina física de unas determinadas características donde todos los recursos de la misma están a nuestra entera disposición; se trata de una solución adecuada para servidores corporativos con mucha carga de trabajo. Es la solución más cara, pero también la más fiable.

Ahora se trata de decidir qué sistema de los tres anteriores es el adecuado para nuestras necesidades. Está claro que si queremos seguridad, disponibilidad y autonomía máxima debemos ir a un hosting dedicado, pero también está claro que esto tiene un precio y suele ser alto.

Si nuestras necesidades son más modestas o nuestras posibilidades económicas son limitadas, siempre será mejor contratar una VPS bien dimensionada que un hosting compartido, sean cual sean los valores nominales que nos den en este último caso.

Existen ofertas de hosting compartido en el que te ofrecen espacio en disco ilimitado, transferencia ilimitada, cuentas de correo ilimitadas, 10 bases de datos y 10 dominios, y no se sabe cuántas cosas más. La realidad es que quien necesita 10 bases de datos y cuentas de correo ilimitadas es porque tiene un gran proyecto y no estará pensando en contratar un servidor compartido; usted lo que necesita es que su Moodle funcione adecuadamente y que la única base de datos que utilizará esté bien configurada.

Entonces, en qué casos se puede contratar un hosting compartido. En mi opinión solo para aprender a gestionar Moodle, para disponer de una demo para sus clientes, para evaluar los cursos...., en definitiva, para todo aquello en que no se la juegue delante de un aula repleta de estudiantes, aunque esta aula sea virtual.

Claro, siempre habrá un proveedor que le ofrezca un hosting compartido a buen precio y le garantice un buen servicio,  pero piense que tipo de servicio espera recibir por 10€ o 12€ al mes; piense cuánto se gasta usted mensualmente, por ejemplo, en telefonía móvil o en su proveedor de internet y analice si su sitio Moodle merece una inversión inferior.

Si finalmente, evalua solo el precio y se decide por esta opción, al menos hágalo en un proveedor especializado en Moodle, fundamentalmente porque la configuración general del entorno estará adaptada a las caracterísiticas de este y porque la competencia por los recursos del servidor se realizará entre iguales; en el caso de un provedor generalista su Moodle puede estar compitiendo por los recurso de la máquina con aplicaciones de streeming de vídeo, servicos de videoconferencia o catálogos de fotografía, que deborarán los recursos del servidor y no dejaran que su Moodle cumpla adecuadamente su función.

Espero que este largo artículo haya puesto un poco de luz a un tema tan importante y tan definitorio a la hora de abordar un proyecto e-learning, como es la publicación en Internet de nuestro sitio Moodle.