El blog de Javier Aranda

Desde hace unas cuantas semanas he notado que en mi Ubuntu 9.10 no se inician algunos scripts situados en /etc/init.d pese a estar bien configurados (pues anteriormente funcionaban sin problemas) y los enlaces simbólicos en /etc/rc?.d también estaban correctamente creados. En mi caso, no se iniciaban servicios que tengo yo configurados (como lighttp, mongodb, etc) pero tampoco algunos “importantes” como cups (lo cual me hacía que cada vez que quería imprimir algo tuviera que iniciarlo manualmente con sudo /etc/init.d/cups start). Hoy me he puesto a ver que podía pasarle y me he topado con que se trata de un bug ya reportado, así que leyendo los comentarios hallamos la solución al menos por ahora: tenemos que instalar una versión anterior del paquete upstart, ejecutando para ello el comando:

sudo apt-get install upstart=0.6.3-10

Reiniciamos y ya se inician los servicios en el arranque del sistema.

Si queremos evitar que las actualizaciones automáticas o el uso del comando apt-get upgrade nos actualice el paquete upstart a la versión más reciente (lo que haría que volviésemos a tener problemas), podemos bloquear el paquete para que no sea actualizado. Para ello:

sudo apt-get install wajig
sudo wajig hold upstart

Nota: si quisiéramos desbloquearlo, basta con ejecutar:

sudo wajig unhold upstart

¿Qué es dllight?

dllight es un pequeño script escrito en php que permite explorar mediante una interfaz web el contenido de una carpeta situada en el servidor y descargar sus archivos, aunque esta carpeta no se encuentre visible en la ruta pública del servidor. Además permite proteger archivos por contraseña, de tal forma que para poder descargarlos hay que introducir la palabra de paso correcta. Y por último, permite insertar publicidad de Google AdSense en las páginas e insertar el código de seguimiento de Google Analytics.

Capturas del script en acción:

dllight listado del contenido del directorio

dllight descarga de un archivo protegida por contraseña

Descargar dllight

Para descargar este script pulse sobre el siguiente enlace: dllight-1.0.0

Instalación y configuración del script

1. Descomprimir el zip descargado y copiar los archivos que se encuentran dentro de la carpeta dllight en la raíz del servidor o en la carpeta desde donde se quiera que sea accesible el script.
2. Renombrar el archivo example.htaccess a .htaccess para que funcione la reescritura de la URL. Esto requiere obligatoriamente tener activado el mod_rewrite.
3. Editar el archivo index.php para establecer una serie de variables de configuración que a continuación se detallan.

• $description: texto que aparece bajo la URL de la página.
• $footer: texto que aparece en la parte inferior de la página.
• $basepath: ruta al directorio el cual queremos mostrar su contenido. Puede estar oculto al servidor web.
• $passfile: archivo donde se especifican las contraseñas. El script buscará en cada directorio si existe este archivo y lo procesa.
• $cookiename: nombre de la cookie usada para conocer si se ha visitado la página previamente a la descarga del archivo. Si no se ha hecho, no se puede descargar.
• $offset: diferencia en segundos de la hora del servidor con la hora que se quiere mostrar en las páginas.
• $google_analytics: código de la cuenta de Google Analytics para controlar las visitas.

El archivo de contraseñas permite establecer una contraseña a cada archivo del directorio en el cual se encuentre ese archivo. Su estructura es:

nombre-del-archivo.extension = mi_contraseña-123
proyecto.zip = 123abc

Como puede observarse, a la izquierda del igual va el nombre del archivo tal cual se encuentra en el sistema de archivos, y a la derecha la contraseña que queremos ponerle.

Miscelánea

Si tienes cualquier duda sobre dllight, tienes los comentarios de esta entrada a tu disposición.

Si te ha gustado mucho, te es muy útil o le obtienes algún beneficio económico, tal vez quieras agradecérmelo con una donación. Si este es tu caso, por favor visita la sección de Donaciones, gracias

¿Qué es mongoDB?

Es una base de datos orientada a documentos de código abierto escrita en C++. A diferencia de otros sistemas de gestión de bases de datos, mongoDB no sigue el modelo relacional. La base de datos gestiona colecciones de documentos en objetos JSON. Está orientada a la web 2.0, la nube y las configuraciones de varios servidores de bases de datos. En la entrada Más allá de las bases de datos relacionales hablamos de la utilidad de este tipo de bases de datos.

Más información:

• http://en.wikipedia.org/wiki/MongoDB
• http://en.wikipedia.org/wiki/Document-oriented_database
• http://www.mongodb.org

Descargando e instalando mongoDB

Existen dos formas de realizar este proceso: podemos descargar el código fuente y compilarlo o bajar directamente los binarios. En este artículo optaremos por lo segundo por la facilidad y comodidad.

En la sección de descargas de la web de mongodb tenemos varias opciones, aunque las que nos interesa es la correspondiente a la versión 1.0.0 para Linux 32 bits (el que use 64 bits deberá escoger su opción). Tras la descarga, tendremos un archivo tar.gz que descomprimiremos con los comandos habituales:

cd Escritorio
tar -zxvf mongodb-linux-i686-1.0.0.tgz
cd mongodb-linux-i686-1.0.0

Si observamos el contenido del directorio vemos que se organiza en los subdirectorios bin, include y lib. En principio ya podríamos ejecutar mongodb desde ese directorio, pero por cuestiones de orden y claridad, copiaremos el contenido de esas subcarpetas en los directorios de igual nombre bajo /usr/local, operación para la que necesitamos adquirir permisos de root.

sudo -s
mv bin/* /usr/local/bin
mv include/* /usr/local/include
mv lib/* /usr/local/lib

De aquí en adelante asumiremos que estamos logueados en la terminal como root. Como ya tenemos los archivos donde nos interesan, podemos eliminar la carpeta descomprimida y el archivo descargado:

cd ../
rm -fr mongodb-linux-i686-1.0.0 mongodb-linux-i686-1.0.0.tgz

Configuración inicial

Antes de iniciar el demonio de mongodb es necesario crear una serie de directorios de trabajo, ya que al no instalarse, estos directorios no se crean. El más fundamental será el directorio donde el gestor almacenará las estructuras necesarias para almacenar en el disco duro los datos. Por defecto la carpeta es /data/db pero en este tutorial guardaremos los datos bajo /var/lib/mongodb (mysql por ejemplo también guarda los datos bajo /var/lib). Para ello creamos el directorio:

mkdir /var/lib/mongodb

Este directorio es propiedad de root. En este tutorial el demonio mongod se ejecutará bajo el usuario root. Podríamos ejecutarlo bajo otro usuario existente o crear uno específico para ello, tras lo que podríamos cambiar la propiedad del directorio de los datos por la del usuario usado por mongod.

El demonio puede configurarse mediante una serie de parámetros (ejecutar mongod –help para una lista) pasados al ejecutable del demonio, pero esta forma es un poco sucia y puede exponer ciertas configuraciones a la vista de cualquier usuario del sistema que explore la lista de procesos. Por ello, mongodb permite ser llamado especificándole la ruta a un archivo de configuración (de tipo conf). Ya que existe esa posibilidad, nosotros la vamos a hacer de esa forma. Para ello creamos un directorio bajo /etc llamado mongodb:

mkdir /etc/mongodb

Y con cualquier editor creamos el archivo mongodb.conf y le asignamos el contenido:

nano /etc/mongodb/mongodb.conf

# Config file for MongoDB

dbpath = /var/lib/mongodb

Como puede observarse, la directiva de configuración dbpath (que podía fijarse como parámetro del demonio) se usa de forma análoga en el archivo de configuración, especificándole a la aplicación dónde se encuentra el directorio con los datos. Existen directivas que no reciben argumentos, por ejemplo –auth no requiere nada a continuación. En estos casos, en el archivo de configuración deberemos igualarlo a true. Continuando con el ejemplo, –auth quedaría como auth = true. Por el momento no usaremos más directivas. En la web oficial existe un apartado dedicado a cada parámetro que podemos usar para configurar mongodb.

Iniciando el demonio

Para ejecutar el demonio escribiremos (le indicamos la ruta al archivo de configuración con -f):

mongod -f /etc/mongodb/mongodb.conf

Y si todo va bien, obtendremos algo como esto:

Tue Oct 13 21:47:02 Mongo DB : starting : pid = 16139 port = 27017 dbpath = /var/lib/mongodb master = 0 slave = 0  32-bit 

** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
**       see http://blog.mongodb.org/post/137788967/32-bit-limitations for more

Tue Oct 13 21:47:02 db version v1.0.0, pdfile version 4.4
Tue Oct 13 21:47:02 git version: afe21e02c11f9a923ab1c95edf6fdd95b9a4a51e
Tue Oct 13 21:47:02 sys info: Linux domU-12-31-39-01-70-B4 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686
Tue Oct 13 21:47:02 waiting for connections on port 27017
Tue Oct 13 21:47:02 web admin interface listening on port 28017

Tras esta operación ya tenemos al demonio listo para atender nuestras peticiones.

Instalar el driver para PHP

Para poder instalar el driver de mongodb para php debemos tener instalado el paquete PEAR y la versión de desarrollo de php. Si no lo tenemos instalado, sólo tenemos que ejecutar:

apt-get install php-pear php5-dev

Y para instalar el driver:

pecl install mongo

Configurar PHP

El siguiente paso y último de la instalación y configuración consiste en indicarle a php que debe cargar la nueva extensión que contiene el driver en sí. Para ello creamos el siguiente archivo:

nano /etc/php5/conf.d/mongodb.ini

Y le asignamos la carga del módulo y sus directivas de configuración:

extension=mongo.so

[mongo]
; If the driver should reconnect to mongo
mongo.auto_reconnect = true

; Whether to allow persistent connections
mongo.allow_persistent = On

; Maximum number of persistent connections (-1 means unlimited)
mongo.max_persistent = -1

; Maximum number of links (persistent and non-persistent, -1 means unlimited)
mongo.max_connections = -1

; Default host for mongo connection
mongo.default_host = www.example.com

; Default port for mongo database
mongo.default_port = 42

; When saving files to the database, size of chunks to split them into
mongo.chunk_size = 1024

; Specify an alternate character to $ to use for special db functions ($set, $push, $exists, etc.)
mongo.cmd = "$"

Tras esta operación debemos reiniciar Apache para que PHP cargue de nuevo la configuración y los módulos (sólo si trabajamos con mod_php).

/etc/init.d/apache2 restart

Si ejecutamos un phpinfo() observamos que la extensión se ha cargado perfectamente.

Para completar los archivos necesarios dentro del directorio db, en esta entrada aprenderemos a especificar las capacidades del módulo y el archivo de actualización por si el módulo que instalamos fuese una versión superior a una que ya existiese.

Definiendo las capacidades

Moodle posee un sistema de capacidades, una especie de sistema de permisos que nos permitirán definir acciones y decidir qué usuarios pueden ejecutarlas. Esto nos resultará especialmente útil para definir acciones de administración o que sólo deban ser ejecutadas por un role de usuario (alumno, profesor, administrador, etc). Estas accionen deben definirse en un archivo llamado access.php que se encuentra bajo el directorio db. Cuando instalamos el módulo, moodle lee este archivo y copia su información en la base de datos, por lo que si lo modificamos, tendremos que aumentar el valor de la versión del módulo (esto lo veremos más adelante) para que moodle vuelva a leerlo y almacenar sus nuevos valores. Veamos su estructura:

access.php

$mod_modsms_capabilities = array(

    //capacidad de enviar mensajes en el tablon
    'mod/modsms:participate' => array(

        'riskbitmask' => RISK_SPAM,

        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'student' => CAP_ALLOW
        )
    ),

    //capacidad de administrar el tablón
    'mod/modsms:manage' => array(

        'riskbitmask' => RISK_SPAM,

        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'teacher' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'admin' => CAP_ALLOW
        )
    )
);

Como podemos observar en el código anterior, la variable ($mod_modsms_capabilities) incluye el nombre del módulo para diferenciarla de la que pueda existir en otros módulos. Internamente, está formada por un array de tantos elementos como capacidades queramos definir, en la forma nombre_de_la_capacidad => array_de_configuración_de_esa_capacidad. Entre esas configuraciones, caben destacar:

captype: tipo de la capacidad. El valor write indica que la capacidad será usada para la entrada de datos o el cambio de cosas. El valor read por contra se usa para la salida de datos, para mostrar cosas.

legacy: este elemento es a su vez un array que permite indicar que tipo de role posee autorización para realizar la acción indicada en la capacidad.

Para más información sobre las capacidades se puede consultar la documentación oficial en inglés:

• http://docs.moodle.org/en/Development:NEWMODULE_Adding_capabilities
• http://docs.moodle.org/en/Development:Roles
• http://docs.moodle.org/en/Development:Hardening_new_Roles_system

Viendo el código podemos observar que se han definido dos capacidades: la de enviar mensajes al tablón y la de administrarlo. Para la primera, que es de tipo escritura (ya que el usuario envía datos), sólo autorizamos a que sea el usuario cuyo rol es estudiante a que pueda escribir mensajes. En la segunda, de tipo escritura, los roles que pueden hacer uso de esta capacidad son los de profesor (ambos tipos) y administrador. Se podría haber definido un tercer rol de tipo lectura con la capacidad de leer los mensajes, pero como los mensajes pueden ser vistos por cualquier tipo de usuario, no se ha considerado.

Actualizando versiones anteriores del módulo

Si nuestro módulo no es de nueva creación sino que se trata de una versión posterior, es posible que necesitemos realizar actualizaciones en la base de datos existente (ya que al existir una en el sistema no se sobreescriben los datos con el contenido del archivo install.xml visto en entradas anteriores) al necesitar esta nueva versión de campos adicionales por ejemplo. La forma de realizar esto es mediante el archivo upgrade.php que se encuentra también bajo el directorio db. Este archivo contiene en su interior una función llamada xmldb_nombremodulo_upgrade, la cual será invocada por moodle en la instalación del módulo y pasándole como parámetro la versión del módulo instalado actualmente.

upgrade.php

function xmldb_modsms_upgrade($oldversion=0)
{
    global $CFG, $THEME, $db;

    $result = true;

    /*
    And upgrade begins here. For each one, you'll need one
    block of code similar to the next one. Please, delete
    this comment lines once this file start handling proper
    upgrade code.

    if ($result && $oldversion < YYYYMMDD00) { //New version in version.php
        $result = result of "/lib/ddllib.php" function calls
    }
    */

    return $result;
}

Es en esta función donde deberemos implementar las diferentes consultas a la base de datos para transformar los datos antiguos al nuevo formato. En nuestro caso, al ser la primera versión del módulo, no la necesitamos, por lo que devolvemos true indicando que todo ha salido correctamente.

La versión del módulo y otros datos de interés

En los apartados anteriores vimos que resulta necesario para ciertas operaciones conocer el número de versión del módulo instalado actualmente. La forma que tiene moodle de saberlo es mediante el contenido del archivo version.php situado en la raíz del módulo. El contenido del archivo es el siguiente:

version.php

//versión del módulo
$module->version  = 2009101200;

//versión de moodle mínima para instalarse
$module->requires = 2007101509;

//tiempo cada cual debe ser llamada la función de cron del módulo
$module->cron     = 0;

La primera de ellas le indica a moodle la versión de este módulo. La segunda indica la versión mínima de moodle sobre la que corre este módulo. Las versiones siguen la forma AAAAMMDDXY.YY siendo YYYYMMDD la fecha de lanzamiento de la rama (1.9 en el caso de la versión de moodle), X número de release 1.9.[0,1,2,3...] e Y.YY pequeños incrementos de las versiones entre releases. El último parámetro nos permite establecer cada cuanto tiempo moodle debe llamar a la función de cron que se encuentra dentro de lib.php como veremos en futuras entregas de este tutorial. Si se pone a cero nunca se llamará a la función (por que no nos haga falta en nuestro módulo).