Autor: diariolinux

Hackit’2012, solucionario. Level 1.

Para no perder las buenas costumbres y de paso aprender algo más por el camino, tengo la intención de ir comentando las soluciones a 6 de los niveles del HackIt 2012 que se celebró en la Euskal Encounter en Julio. El organizador del concurso, marcan, ha publicado en su web todas las pruebas, para que podamos salsear con ellas.

El nivel 1 es muy sencillo. Si nos fijamos en el código fuente de la página, veremos:

<script type="text/javascript">// <![CDATA[
function check() {var p=$('#password').val();var o=[42,96,21,102,18,85,48,68,48,89,55,80,3,119,22,100,16,117,17];if(p.length!=(o.length-1)){return false;}for(i=0;i<(o.length-1);i++){if(p.charCodeAt(i)!=(o[i+1]^o[i])){return false;}}return true;}
$(document).ready(function(){$('#password').keyup(function(e){$('#password').css({'background-color':(check()?'#8f8':'#f88')});});
});
// ]]></script>

Así pues, el código busca el password tecleado en el formulario y compara su longitud con la del array o (-1). Si son iguales, comienza una comparación letra a letra del password tecleado con el array o. En concreto, busca que la posición i del password sea igual a o[i+1]^o[i] (el operador ^ es un XOR). Esto lo podemos calcular fácilmente haciendo uso de la consola del navegador (en Chrome: pulsamos Shift+Ctrl+J):

[Vim] e365 failed to print postscript file

Nota rápida por si a alguien más le viene bien. La cuestión es que desde Vim no podía imprimir (desde LibreOffice lo hacía sin problemas). El error que arrojaba Vim era:

e365 failed to print postscript file

La cuestión es que el comando lpr (comando Linux para imprimir que Vim usa internamente) intentaba lanzar el trabajo a la impresora por defecto y ésta no estaba definida. En Ubuntu uso el sistema de impresión CUPS. Según el manual de CUPS, para conocer los nombres de impresoras disponibles podemos usar el comando lpstat:

$ lpstat -p -d

Y una vez conocido el nombre de las impresoras, puedes fijar una por defecto con lpoptions:

$ lpoptions -d hp_LaserJet_1300

¡Listo! Vim (GVim en mi caso) imprime ahora perfectamente 🙂

Buscar cadenas de texto dentro de ficheros ODT

Como sabéis, los ficheros ODT de LibreOffice son simples ficheros .zip . Dentro de ellos, encontramos distintos archivos xml, gráficos incrustados, etc. Un ejemplo:

$ unzip -l herramientas.odt 
Archive:  herramientas.odt
  Length      Date    Time    Name
---------  ---------- -----   ----
       39  2012-07-20 12:00   mimetype
      997  2012-07-20 12:00   meta.xml
     8798  2012-07-20 12:00   settings.xml
    12512  2012-07-20 12:00   content.xml
     7003  2012-07-20 12:00   Thumbnails/thumbnail.png
       22  2012-07-20 12:00   layout-cache
      899  2012-07-20 12:00   manifest.rdf
        0  2012-07-20 12:00   Configurations2/popupmenu/
        0  2012-07-20 12:00   Configurations2/images/Bitmaps/
        0  2012-07-20 12:00   Configurations2/toolpanel/
        0  2012-07-20 12:00   Configurations2/statusbar/
        0  2012-07-20 12:00   Configurations2/toolbar/
        0  2012-07-20 12:00   Configurations2/progressbar/
        0  2012-07-20 12:00   Configurations2/menubar/
        0  2012-07-20 12:00   Configurations2/floater/
        0  2012-07-20 12:00   Configurations2/accelerator/current.xml
    12033  2012-07-20 12:00   styles.xml
     1185  2012-07-20 12:00   META-INF/manifest.xml
---------                     -------
    43488                     18 files

El problema viene cuando tienes una carpeta llena de ficheros .ODT y quieres buscar un texto en concreto en todos ellos. Al tratarse de ficheros comprimidos, no vale con usar ni el comando strings ni el comando grep, porque no encontrará lo que buscas.

¿Solución? Convertir los .odt a texto con el comando odt2txt (funciona también para .odg y otros formatos):

for i in *.odt; 
do 
   echo $i; 
   echo "*************"; 
   odt2txt $i | grep -i cadena_de_texto_a_buscar; 
done

Ese bucle for recorre todos los ficheros con extensión .odt, los convierte a texto (no genera ficheros nuevos, la conversión se realiza hacia la salida estándar) y los pasa por un pipe a grep, que realiza la búsqueda. El echo $i con los *** sirve para remarcar el nombre del fichero en el que se encontró la cadena.

Tu propio servidor Moodle gratuito en la nube OpenShift

¿Recuerdas que ya hablamos en DiarioLinux sobre la plataforma OpenShift Express? Efectivamente, es el servicio en la nube de RedHat que te permite montar – por el momento  – tu propio servidor Linux online de forma gratuita. Pues bien, vengo con novedades. La primera es que, gracias a este reciente podcast de FLOSS Weekly, nos enteramos de que  OpenShift usa internamente instancias AWS (Elastic Cloud Computing, EC2) de Amazon. Así que RedHat está apostando muy fuerte por su servicio PaaS (Platform as a Service) cuando ofrece gratuitamente algo que a ellos les estará costando un buen puñado de dólares. Como bien comentan en el propio podcast, esto es temporal (lógico), hasta conseguir una masa crítica de usuarios.

Pero la novedad que da título a este post consiste en la posibilidad de montar tu propio servidor Moodle online usando OpenShift. Para ello seguiremos las instrucciones dadas por burningTyger, el autor original de la receta.

En resumidas cuentas, lo primero es instalar las herramientas rhc para conseguir controlar OpenShift desde la línea de comandos (o ¿debería decir «de órdenes», para no pecar de indocumentado? 😉 Este paso lo dejamos bien descrito en el artículo anterior de DiarioLinux, por lo que vuelvo a remitirte a su lectura. Lo siguiente es clonar el repositorio de Moodle que burningTyger tiene en GitHub.

  git clone git://github.com/burningTyger/os_moodle.git

Esto nos creará en el directorio os_moodle una copia del servidor Moodle especialmente preparado para ser ejecutado en OpenShift.  Situados en os_moodle, lanzamos los siguientes comandos:

rhc-ctl-app -a moodle -e add-mysql-5.1 -l tu_login
git remote add openshift tu_url_git_openshift

La primera línea indica que queremos montar una nueva aplicación sobre OpenShift, a la que daremos e nombre de moodle y, a continuación, añadirle un servidor mysql-5.1. «tu_login» es el identificador de usuario que diste en OpenShift (normalmente tu dirección email). La segunda línea indica que al repositorio moodle que acabas de crear en tu disco, quieres añadirle una referencia al repositorio que tienes en OpenShift. La dirección de este último es lo que tienes que poner en el campo «tu_url_git_openshift». Esta url la puedes obtener listando tus aplicaciones desde la línea de comandos (ops… otra vez 😉

$ rhc-domain-info -l tu_login_openshift -p tu_password

Verás algo así:

 Git URL: ssh://xxxxxxabc123def456xxxxx789abcxxx@moodle-tudominio.rhcloud.com/~/git/moodle.git

Ya está todo en orden. Ahora sólo hace falta «subir» a OpenShift (hacer un push) lo que tienes en tu disco duro:

   git push -f openshift master

¡Fin! Tu instancia Moodle estará lista para ser configurada (nombre, cursos, alumnos…) desde la URL de tu aplicación (la que se ve en la Git URL)

http://moodle-tudominio.rhcloud.com

Probablemente te interese activar el soporte cron de OpenShift para lanzar el proceso cron de Moodle periodicamente. Para ello, debes especificar que quieres hacer uso de cron:

$ rhc-ctl-app -a moodle -e add-cron-1.4

A continuación, crea el directorio moodle/.openshift/cron/hourly y dentro, crea un script llamado reloj.sh con el siguiente contenido:

#!/bin/bash
/usr/bin/php  ${OPENSHIFT_HOMEDIR}/app-root/repo/php/admin/cli/cron.php >/dev/null

No te olvides de asignarle permisos de ejecución (chmod +x ./reloj.sh). A continuación, nos situamos nuevamente en moodle/ y añadimos el script recién creado al conjunto de ficheros gestionados por git (add+commit) y subimos los cambios a OpenShift (deploy).

$ git add .openshift/cron/hourly/
$ git commit -a -m "add reloj.sh hourly cron script"
$ git push

Un detalle final: dado que Moodle suele publicar actualizaciones periódicas, es recomendable descargarlas y mantener actualizado tu servidor. Este punto también está pensado. Basta con que descargues los updates del repo Git original y los subas a tu servidor en OpenShift:

$ git pull origin master
$ git push openshift master

En mi grupo de investigación estamos usando OpenShift como alojamiento para la demo del plugin Babelium para Moodle https://moodle-babelium.rhcloud.com . Como ves, OpenShift admite también direcciones https. Anímate a publicar ahí tu vídeo-respuesta 🙂

Incubando huevos al estilo Apache

Me gusta aplicar herramientas y técnicas que aprendo en la ingeniería de grandes proyectos de software opensource en la gestión y trabajo diario de los Proyectos Fin de Carrera que dirijo (ahora, Trabajos Fin de Grado). Realmente creo que estas técnicas se pueden reutilizar tamb ién y de forma bastante directa en el ámbito empresarial, pero eso lo dejo como tema de discusión para otro día. Ahora quiero centrarme en exponer brevemente, de forma muy resumida, cómo funciona la incubadora de proyectos de Apache.

Apache ofrece cobertura técnica (infraestructura, servidores, listas de correo, espacio en disco…) y legal a los nuevos proyectos que acoge, aparte de permitir asociar su marca, Apache (muy reconocida en el mundo tecnológico) al nuevo proyecto. Éste, a cambio de pasar a formar parte de la incubadora de la fundación (a ser un podling), debe empezar a cumplir ciertos requisitos.

No es fácil llegar a formar parte de la incubadora, hay un largo camino que recorrer, pero una vez que lo consigues y tu proyecto obtiene una dirección en la incubadora Apache, entras, como hemos dicho, en la zona de Podling. Aquí tendrás resposabilidades y mucho trabajo por hacer. Entre otras cosas:

* generar un informe de seguimiento. Uno al mes durante los primeros 3 meses y uno cada 3 meses a partir de ahí.
Puedes ver esta planificación de informes general, o uno en particular (mes de Marzo de 2012)

* mantener actualizada una página con un resumen del estado del proyecto. Por ejemplo, ésta de OpenMeetings.

* atender las listas de correo

* generar novedades en el proyecto. Estas novedades serán recogidas y documentadas de forma automática. Si cada proyecto de la incubadora es visto como un huevo, el nido de huevos sería el clutch de Apache. Y las novedades en el clutch están monitorizadas.

¿Qué se monitoriza? Entre otros datos, los días de incubación, la última fecha de commit en SVN, la última fecha de actualización de la página de estado, el número de nuevos commiters,

Como todo huevo bien cuidado por sus progenitores, eclosionará en algún momento, pasando a ser un potencial proyecto Top Level de Apache (digo potencial porque deberá ser aprobado por votación)

Como ves, la política de incubación es interesante y puede ser aplicada fuera del entorno Apache (en empresas de desarrollo software, en proyectos fin de carrera, trabajos fin de grado…). Lo que está claro es que requiere mucha dedicación y esfuerzo a los responsables del proyecto, así que ahora entenderás mejor porqué algunos proyectos no se deciden a dar el paso de entrar en la incubadora (aparte de que algunos proyectos no quieran usar ni los servicios ni la licencia Apache).