Notas de ant30

Mi primera aplicación en Google Play, eldiario.es para android

Sun, 24 Feb 2013 09:03:58 +0000

Es una aplicación para leer los contenidos de eldiario.es en tu móvil o tablet.

Se trata básicamente de un lector de RSS, pero en vez de leer la fuente RSS directamente del medio en cuestión, pasa a través de un backend que es capaz de ir almacenando las noticias de cada sección y redimensionar las imágenes para que estén optimizadas en tamaño para móviles y tabletas. Dependiendo del tamaño de la pantalla, ofrece vista a una o dos columnas, así como imágenes de diferentes tamaños.

El backend está compuesto por Pyramid, MongoDB e ImageMagick.

En el cliente móvil tenemos phonegap, jQuery, backbonejs, underscore, iScroll, … Toda una fauna de librerías típicas que acompañan a una aplicación web.

Desde hace unos meses, andaba jugueteando con conceptos de aplicaciones móviles a modo de entretenimiento con algunos compañeros del trabajo, así que un día de estas navidades, comencé otra prueba de concepto enfocado a realizar una aplicación móvil de un periódico. Entonces seleccioné a por publicar sus contenidos con licencia [Creative Commons](http://www.eldiario.es/licencia/) y empecé a jugar con sus fuentes RSS.

Para ir a la página de la aplicación en el market de android puedes pulsar en este enlace:

Enlace a la aplicación eldiario.es para android

Red Hat, Virtualización y Fail-Over de servicios

Mon, 09 Apr 2012 10:32:18 +0000

He publicado un post en el blog de Yaco sobre el despliegue que hemos realizado para el cluster del portal web del Patronato de la Alhambra.

Implantación de Alta Disponibilidad con Red Hat y Virtualización

Cómo conseguir la IP de una máquina virtual de libvirt / kvm

Fri, 09 Mar 2012 20:58:05 +0000

Una de esas pequeñas cosas que molestan de libvirt en su combinación por virsh es que no tiene un método para obtener la IP de una máquina virtual. Y sin la IP ¿cómo conectamos por ssh a la máquina?

En los últimos cambios incorporados en libvirt, se permite controlar parte del gestor dhcp/dns que viene incorporado, dnsmasq y que seguro que en un futuro nos permitirá obtener la IP sin hacer trucos. Se puede ver en la documentación de Addressing de libvirt

La forma trivial de obtener la IP es bastante fácil. A través de virt-manager, accedes a la pantalla de la máquina mediante VNC. Haces login con tu usuario y contraseña, y bastaría con ejecutar ifconfig o ip a para ver la IP entre toda la información de la red.

Este método es un poco tedioso, y además, si el servidor se encuentra en una red lejana con mucho lag en la terminal, el efecto sobre la consola VNC puede ser temible. Por tanto, hay que buscar alternativas más cómodas. Cómo mediante la información arp.

Hasta ahora, mi método solía ser mirar la mac de máquina obtenida del XML de la máquina con:

$ virsh dumpxml nombrevm

Y luego buscarla en la tabla arp, fácilmente accesible mediante:

$ arp -n

Para refrescar la memoria de algún rezagado, con el comando arp se obtiene la información de la tabla de caché del sistema que vincula “macs” vecinas con sus respectivas IPs, de forma que se evite tener que estar continuamente haciendo peticiones de descubrimiento de asociaciones mac-ip en la red en cada envío de paquete tcp/ip. Si quieres más información sobre el protocolo ARP siempre puedes consultar su página en la Wikipedia. Como inconveniente tenemos que solo es válida su ejecución en el host de virtualización donde esté corriendo la máquina virtual. De otra forma, al no llegarnos la petición de IP de DHCP mediante broadcast, no podremos obtener esta IP.

Este método es muy manual, pero es bastante fácil meterlo todo en un comando de una sola línea combinando esos comandos que tanto nos gusta usar en la shell como cut y grep:

env NOMBREVM=nombrevm arp -n | grep $(virsh dumpxml $NOMBREVM | grep mac\ address | cut -d \' -f 2 ) | cut -d \  -f 1

Y si ya tenemos todo en una línea ¿porqué no incorporarlo como comando del sistema?

Como adjunto, he incorporado el script que uso para obtener la IP de una máquina virtual indicándole el nombre de la máquina. El comando lo llamo virt-ip y lo suelo colocar bajo la ruta /usr/local/bin/virt-ip

virt-ip

Clonando máquinas virtuales con virt-clone

Tue, 31 Jan 2012 19:47:20 +0000

En el post anterior, Creando una imagen plantilla de Debian y derivados para kvm, ya vimos lo fácil que era crear imágenes de sistemas virtualizados a través de imágenes skels o plantillas y concluíamos creando la máquina mediante virt-install. También comenté que era posible realizarlo con virt-clone.

Virt-clone aún no soporta el tratamiento de snapshots o backing image directamente. De momento, lo que sí que podemos hacer si ya tenemos la imagen creada y el dominio virtualizado disponible en libvirt es invocar al clonado, indicando que queremos preservar los datos de la imagen destino. En nuestro caso, la imagen destino la indicaremos nosotros y se correspondeerá con la imagen del sistema nuevo.

Como ventajas tenemos que copiaremos los datos de ram, cpu, tarjetas de red, contexto selinux/apparmor y el resto de configuraciones del dominio xml asociado a la máquina virtual. Por tanto, resulta interesante principalmente para máquinas con muchos añadidos de configuración.

Recordamos el proceso de clonación de usando plantillas:

Dirigiéndonos a nuestro almacen de imágenes. Congelamos la imagen plantilla quitando permisos de escritura.
```
chmod -r ubuntu1110-master.img
```
Indicamos que queremos crear una nueva imagen de disco basándonos en la plantilla
```
qemu-img create -f qcow2 -b ubuntu1110-master.img ubuntu1110-clon.img
```
Usamos virt-clone para crear la nueva réplica. Con características similares a la máquina original, en este caso, cambian la mac de la máquina y el UUID del dominio.
```
virt-clone -n ubuntu1110-clon -o ubuntu1110 -f ubuntu1110-clon.img --preserve-data
```

En algunos casos puede ser que tengamos que forzar a que se conecte con el libvirt local, en este caso, lo ejecutamos de esta forma:

virt-clone --connect qemu:///system -n ubuntu1110-clon -o ubuntu1110 -f ubuntu1110-clon.img --preserve-data

En nuestro caso, como queremos lanzar un clon de forma rápida, ha sido necesario el comando --preserve-data. Sin embargo, si queremos que la imagen sea independiente, se puede hacer sin la opción --preserve-data. La operación durará varios minutos porque revisará todos los mapas de bloques vacíos para resumir el espacio de la nueva imagen de disco.

virt-clone --connect qemu:///system -o ubuntu1110 -n ubuntu1110-clon2 -f ubuntu1110-clon2.img

El comando nos muestra el progreso de la ejecución en la salida incluyendo un tiempo estimado de finalización y el porcentaje.

Virt-clone pertenece al grupo de utilidades de gestión de virtualización virt-manager que funcionan haciendo uso de la api libvirt

Creando una imagen plantilla de Debian y derivados para kvm

Thu, 29 Dec 2011 21:48:40 +0000

¿Qué es una imagen plantilla?

Imagen Skel, plantilla, Imagen Gold, template, Appliance, base, .. todo estos términos se acaban refiriendo a lo mismo. En los sistemas de virtualización más habituales, tenemos la posibilidad de guardar el disco duro del sistema virtualizado en nuestro propio disco duro en una imagen que habitualmente contiene unos metadatos de información como por ejemplo el tamaño del disco y además contiene lo que sería equivalente al disco duro físico de la máquina virtual. Existen múltiples formatos de imagen de disco como vmdk, vdi, raw, qcow2 o qed. En nuestro caso, vamos a usar qcow2 y porque es el formato más estable para el sistema de virtualización que vamos a usar, libvirt con kvm.

Si solemos trabajar con sistemas virtualizados, es bastante habitual tener múltiples máquinas con una misma versión de debian, aunque luego tengan software diferente. También puede resultar que tengamos todo el sistema y una aplicación desplegada en muchas máquinas, de forma que luego solo hacemos algunas personalizaciones sobre la aplicación. Es decir, que realmente estas máquinas comparten mucha información como sistema operativo y aplicaciones. Intentar evitar la repetición de información compartida es el objetivo de las imágenes gold o plantillas. Pero no solo por evitar la duplicidad de información, sino para conseguir ahorrar tiempo en la creación de nuevas máquinas virtuales de características similares.

A continuación veremos una forma de reducir drásticamente el tiempo de creación de nuevas máquinas virtuales a través de imágenes plantilla.

Un ejemplo

Imagina que te necesitas 10 máquinas virtuales con debian squeeze, y por tanto, tuvieras que instalar debian 10 veces. Qué pérdida de tiempo ¿no?

Una posible solución, y suele ser la primera solución que hemos hecho alguna vez todos, es tras acabar de instalar debian en esa imagen, copiarla 9 veces. Con un disco duro medianamente rápido conseguimos una tasa de copia en un mismo disco de 40MB/s, te puedes ir a tomar un café mientras se termina la copia y quizás cuando vuelvas aún no haya terminado.

Tras arrancar cada una de las nuevas 9 máquinas es posible que nos encontremos sin red, porque se nos habrá creado una nueva interfaz de red que no está contemplada en la configuración (/etc/network/interfaces) para que se active durante el arranque. Esto ocurre porque la MAC de la tarjeta de red de la nueva máquina virtual es diferente a la que se generó primero. Para solucionar esto, basta con borrar el fichero /etc/udev/rules.d/70-persistent-net.rules y reiniciar.

Bien, ya tenemos las 10 máquinas arrancadas y con red, si hacemos un ssh y nos fijamos tenemos un nuevo problema. Todos los servidores tienen la misma key. Por tanto toca regenerarlas para cada servidor y reiniciar servicio ssh.

También puede resultar problemático que todas las máquinas tengan el mismo hostname y por tanto, al hacer ssh, todas tengan el mismo prompt, lo cual puede resultar confuso.

Por tanto, seguimos teniendo varios problemas. Larga espera para la copia de las imágenes y modificaciones manuales máquina a máquina. Necesitamos algo más práctico.

Mejora 1: Reduciendo modificaciones manuales del primer arranque

Una vez tenemos nuestra imagen preparada, recién instalada, antes de empezar a usarla como imagen plantilla, deberíamos intentar simplificar al máximo las tareas manuales a realizar durante el primer arranque. Además de limpiar de datos que no sean útiles para los futuros clones.

Eliminar persistencia de nombres de dispositivos de red de udev

Si estamos usando una imagen con una distribución debian o basada en debian como ubuntu, tendremos el problema de udev, así que lo ideal es siempre borrar el fichero /etc/udev/rules.d/70-persistent-net.rules para que cuando se arranque una copia de la máquina, se cree un nuevo fichero de nuevo. En VMware y XEN este problema no ocurre, pero sí con KVM. El problema radica en que el identificador del dispositivo en KVM es como el de un dispositivo real, ya sea Realtek o Intel, y con esto, udev, no puede distinguir cuando se está usando una interfaz virtual o no.

Actualmente, las reglas para inhibir la creación del fichero de persistencia para redes de KVM están en el fichero /lib/udev/rules.d/75-persistent-net-generator.rules pero también se puede apreciar como existen reglas para Realtek que entran en colisión. Por tanto, también puedes anular la regla de Realtek para se haga efectiva, pero entonces estarás modificando ficheros del paquete udev, práctica nada recomendable para futuras actualizaciones.

Eliminar historial

Dependiendo de nuestras necesidades o de quien pueda usar después la imagen que estamos preparando, lo ideal es borrar rastros como por ejemplo el fichero .bash_history de todos los usuarios.

Hay quien incluso limpiaría logs y otros restos.

Preparar tareas para el primer arranque

No existe o no conozco una forma elegante de programar una tarea que se ejecute solo en el próximo arranque. Así que lo que vamos a preparar es una forma poco intrusiva para llevarlo a cabo.

Creamos en /root un script llamado firstboot.sh con el siguiente contenido:

#!/bin/bash
rm /etc/ssh/ssh\_host\_*
/usr/sbin/dpkg-reconfigure openssh-server

En nuestro caso, solo vamos a regenerar las claves del servicio ssh.

Ahora, creamos un nuevo fichero en cron.d para que invoque a nuestro script al completar el arranque, por tanto creamos el fichero /etc/cron.d/firstboot con el siguiente contenido:

@reboot root bash /root/firstboot.sh && rm -f /etc/cron.d/firstboot /root/firstboot.sh

Primero se ejecutará firstboot.sh y luego se borrará la entrada del cron y el script del primer arranque para que no se vuelvan a ejecutar.

Ya avisé que no era una forma muy elegante de hacerlo.

El script firstboot.sh descrito es lo mínimo, pero sería interesante recoger el hostname desde el DNS y aplicar el cambio, realizar las tareas para inicializar un sistema de gestión de configuración centralizada o cualquier otra tarea.

Prepara tu entorno

Una vez finalizada la instalación de debian, tenemos vi, pero no vim, basta con instalar el paquete, pero aprovechando que estamos haciendo nuestra template, deberíamos instalar esas cosas que siempre acabamos usando, y aquí va una lista de las cosas que suelo tener en mis imágenes plantillas independientemente de para qué se usen:

El metapaquete vim-nox, o vim
Mi configuración de vim, .vimrc
Mis claves públicas ssh en /root/.ssh/authorized_keys para no tener que estar metiendo contraseñas en cada ssh
Un .bashrc con los alias que suelo usar
Screen y su configuración
¿Está instalado ssh server y aptitude? ¿Necesito sudo?
htop, un top mucho más cómodo
Algunos alias en el fichero /etc/hosts

Mejora 2: técnica alternativa al copiado de imágenes, backing images

Estamos usando libvirt con kvm, que en definitiva se trata de qemu y por tanto, para la creación de imágenes, usamos qemu-img. Para crear una imagen nueva basada en nuestra plantilla es tan fácil como ir al directorio de imágenes y suponiendo que la imagen creada se llame debian6.img creamos un clon, debian6-clon.img, con el comando qemu-img como sigue:

qemu-img create -f qcow2 -b debian6.img debian6-clon.img

Tendremos la nueva imagen en segundos y el nuevo fichero debian6-clon.img ocupará solo unos kbytes. Esta nueva imagen irá almacenando bloques que se creen que no estén o hayan sido modificados respecto a la imagen base.

Como inconveniente, tenemos una bajada en el rendimiento de IO por los múltiples accesos a disco por cada petición. Este problema se puede solventar en gran medida si las plantillas las alojamos en discos SSD. Aún así, sino vamos a realizar pruebas de rendimiento, no debería suponer mucho problema.

Si vas a usar la propia imagen como backing image para el resto, recuerda quitar los permisos de escritura para que nunca se vuelva a arrancar, y si puede ser posible, deberías desvincularla de cualquier dominio libvirt. En caso de arranque, el resto de imágenes clonadas que se basen en tu backing image, perderán consistencia y dejarán de funcionar. Casi mejor, por tanto, tener cuidado con la imagen plantilla.

Por otro lado, si queremos convertir la imagen de este clon en imagen plantilla, deberíamos aplanarla, es decir, separarla de la imagen debian6.img fusionando sus datos en una nueva imagen que sea independiente. Esta nueva imagen independiente la podremos mover a otra ruta o incluso a otro servidor. Esto se consigue mediante el comando:

qemu-img convert -f qcow2 -O qcow2 debian6-clone.img debian6-plana.img

Que además, evitará poner en la nueva imagen bloques vacíos y por tanto puede ocupar menos de lo que uno espera.

Creando una máquina virtual con virt-install usando la plantilla

Entre las utilidades que solemos encontrar con libvirt, tenemos virt-install, que nos permite crear una máquina virtual desde bash, también podríamos crearla desde virt-manager de forma gráfica, pero en nuestro caso la vamos a crear mediante virt-install.

Suponiendo que tengamos la imagein debian6-clon.img creada en el punto anterior, en el directorio /var/lib/libvirt/images/ y teniendo en cuenta que este es el almacenamiento por defecto para las imágenes, para crear un sistema con 512MB de RAM y especificando que está basado en Debian Squeeze (debian 6), ejecutaríamos lo siguiente:

sudo virt-install --name debian-clone --ram 512 --os-variant=debiansqueeze --disk /var/lib/libvirt/images/debian6-clone.img --import

Se nos abrirá un visor vnc con virt-viewer para que podamos acceder, por ejemplo para ver si el script de primer arranque se ha ejecutado correctamente, o para conocer la IP de la máquina y poder acceder por ssh de un modo más cómodo.

Por tanto las nuevas réplicas, tanto por la clonación del disco, como del esquema XML de la máquina en libvirt se obtienen en segundos y las tendremos disponibles en nuestro Virt-Manager.

También podríamos usar virt-clone para la generación del XML, pero eso ya lo dejamos para otro día.

Este blog ya está migrado de Drupal 6 a WordPress 3

Wed, 28 Dec 2011 14:43:27 +0000

Tras 3 años con Drupal, ahora he migrado a WordPress. Teniendo en cuenta que solo se trata de un blog, necesito algo que sea más fácil de gestionar, actualizar, utilizar y creo que en eso WordPress gana de sobra a Drupal. Me encantan las Views y los CCK de Drupal, pero es que realmente, para este tipo de blog no los estaba usando.

Existen unas cuantas formas de migrar de Drupal a WordPress, pero no todas contemplan todas las opciones. Lógicamente, migrar funcionalidades de los módulos principales es una tarea que acaba siendo manual.

En mi caso, tenía algunos requisitos mínimos sin los cuales, no podría considerar hacer la migración:

Conservar todos los nodos de Drupal. En Drupal, las páginas, libros y entradas de blogs son nodos.
Conservar las taxonomías, pero no en categorías, sino transformándolas a tags.
Resaltado de sintáxis de código. Tengo varios posts con bloques de código, así que es imprescindible que sigan apareciendo con resaltado de sintaxis.
Migración de adjuntos, y en el caso de las imágenes, que por lo menos, sean visibles. No siempre están como html en el contenido, porque mediante el módulo img_filter, se visualizaban de forma automática en los posts.
Conservar los comentarios, aunque cambien un poco el formato. En drupal hay asunto del comentario y en WordPress no.
Solo hay un usuario, así que esto no debería suponer un problema.
Debe haber pocos 404 tras la migración.

Esta no iba a ser mi primera migración entre diferentes softwares de servicios web, he realizado diferentes migraciones tanto a nivel profesional, en Yaco Sistemas, como para diferentes proyectos personales u otros fines sin ánimos de lucro. En este caso, quiero un resultado no necesariamente profesional, pero sí que esos requisitos mínimos especificados arriba queden satisfechos. Así que como indica el sentido común para realizar migraciones en un sistema de producción, lo ideal es prepararse un entorno de desarrollo con una copia de los datos de producción. En este caso, preparé un chroot con un sistema operativo a donde está hosteado el blog y luego desplegué un clon de Drupal con un dump de la base de datos, y una base de WordPress para comenzar a realizar pruebas.

Las primeras pruebas que hice, eran pruebas de migración realizando modificaciones sobre el SQL siguiendo algunas guías que existen:

Post de Lincoln Hawks en Socialcmsbuzz.com
Migration from Drupal 6.x to WordPress 2.9x

El problema con estos procesos de migración, son los adjuntos. En estos posts, se propone reemplazar las rutas de los tags img en el body, pero es que en mi caso hay tags para img_filters de tipo [img:01 yy:left] o sin ni siquiera tag, indicando en el adjunto como se debe publicar.

Al final, entre diversas pruebas, he optado por pasar por un formato intermedio, MovableTypes Viendo este post de Andrew Sterling parece bastante fácil manipular el body, los tags y el resto de información creando un nodo con contenido php en Drupal.

finalmente, mi código de exportación de Drupal, basándome en el publicado por Andrew Sterling, ha quedado como en el siguiente bloque. No es que sea bonito, pero es funcional:

header('Content-type: text/plain');
$nids = db_query("select distinct n.nid from {node} n inner join {term_node} t on t.nid = n.nid");
while ($node = node_load(db_fetch_object($nids)->nid, NULL, TRUE)) {
  print "AUTHOR: ".$node->name."\n";
  print "TITLE: ".$node->title."\n";
  print "STATUS: ".($node->status?"Publish":"Draft")."\n";
  print "ALLOW COMMENTS: ".($node->comment>0)."\n";
  print "CONVERT BREAKS: 1\n";
  print "ALLOW PINGS: ".($node->comment>0)."\n";
  print "DATE: ".strftime("%m/%d/%Y %I:%M:%S %p", $node->created)."\n";
  print "CATEGORY: blog \n";
  print "KEYWORDS: \n";
  foreach ($node->taxonomy as $vid => $term) {
    print $term->name.",";
  }
  foreach ($node->category as $category) {
    print $category->title.",";
  }
  print "\n";
  print "-----\n";
  print "BODY:\n";

  $body = str_replace("<python>", "[py]", $node->body);
  $body = str_replace("</python>", "[/py]", $body);

  $body = str_replace("<bash>", "[sh]", $body);
  $body = str_replace("</bash>", "[/sh]", $body);

  $body = str_replace("<code>", "<pre class="crayon-plain-tag">", $body);
  $body = str_replace("</code>", "</pre>", $body);

  $body = str_replace("/files/", "/wp-content/uploads/", $body);

  $media_base = "/wp-content/uploads/";

  $patterns = array("/\[img:01 align:left\]/s",
                    "/\[img:vista-navegacion.png yy:float_left\]/s",
                    "/<\!-- break -->/s",
                    "/<\!--break-->/s",
                    "/<h3>/s",
                    "/<\/h3>/s"
                     );

  $replace = array('<img src="'.$media_base.'01_antes_de_comenzar.jpg"/>',
                   '<img src="'.$media_base.'vista-navegacion.png"/>',
                   "<!--more-->",
                   "<!--more-->",
                    "<h2>",
                    "</h2>"
                   );

  $body = preg_replace($patterns, $replace, $body);

  print $body."\n";

  $uploads = db_query("select * from {upload} u where u.nid= %d and list = 1", $node->nid);
  while ($upload = db_fetch_object($uploads)) {
      $file_query = db_query("select * from {files} f where f.fid = %d", $upload->fid);
      $file = db_fetch_object($file_query);
      $file_url = str_replace("files/", "/wp-content/uploads/", $file->filepath);
      $pos = stripos($body, $file_url);
      if ($pos === false){
        $pos_mime = stripos($file->filemime, "image/");
        if ($pos_mime === false){
            print '<a href="'.$file_url.'">'.$file->name.'</a>';
        }
        else {
            print '<img alt="'.$file->filename.'" src="'.$file_url.'"/>';
        }
        print "\n";
      }
  }

  print "-----\n";
  $comments = db_query("select * from {comments} c where c.nid = %d", $node->nid);
  while ($comment = db_fetch_object($comments)) {
    print "-----\n";
    print "COMMENT:\n";
    print "AUTHOR: ".$comment->name."\n";
    print "EMAIL: ".$comment->mail."\n";
    print "IP: ".$comment->hostname."\n";
    print "URL: ".$comment->homepage."\n";
    print "DATE: ".strftime("%m/%d/%Y %I:%M:%S %p", $comment->timestamp)."\n";
    print $comment->subject."\n";
    print $comment->comment."\n";
  }
  print "--------\n";
}
exit;
?>

Con este código, las imágenes adjuntas que no estaban insertadas con tags img ya sea de image_filter o html img, se añaden al final. En el caso de que el adjunto no sea una imagen, se incorpora un enlace. Es importante mover las imágenes del directorio drupal files, al de wordpress, /wp-content/uploads/

En los comentarios, el asunto de muestra en la primera línea, y luego se incorpora el body. También hay ciertas personalizaciones como la conversión del break de drupal al more de wordpress y otras conversiones caseras.

El único problema a resolver ahora está en las URL. En el script de Andrew, se incorporaban como categorías, de forma, que luego mediante un redirect a una búsqueda de wordpress, fuera fácil localizar el post. Sin embargo, esto acaba creando muchas categorías que no son útiles, y aunque se puedan usar módulos para ocultarlas, a la hora de publicar contenidos, estas categorías siguen apareciendo. En mi caso tengo 70 posts, así que si tenemos 2 tipos de urls, el permalink y la pretty url, tendríamos 140 categorías inválidas, demasiadas.

Como opción, finalmente, he escrito un pequeño script en php que haga un redirect a la url de búsqueda de wordpress si se detecta en apache una url con el formato de drupal. Este script sí que no lo publico, son 5 líneas que dan vergüenza.

También he tenido en cuenta en la migración la antigua url del feed de Drupal, que se cambia al nuevo formato de WordPress mediante un Redirect en Apache.

He cambiado el color de la cabecera a blanco y negro, en escala de grises, añadido los botones de twitter y google+ y Akismet y poco más. Esta es la historia de una migración de Drupal a WordPress.

TCOS ha entrado en Debian

Tue, 13 Dec 2011 01:43:37 +0000

He escrito una entrada sobre TCOS y su entrada en Debian en el Blog de Yaco En la que he colaborado poniendo en contacto a Mario, desarrollador de TCOS con desarrolladores de Debian como GheRivero TCOS ya forma parte de Debian en el blog de Yaco

Enhorabuena Mario.

Puppet, gestión de configuración centralizada.

Wed, 23 Nov 2011 14:48:39 +0000

Puppet es una herramienta gestión de configuraciones centralizada que nos ayudará en la laboriosa gestión de servidores cuando el número de estos empieza a crecer.

Recientemente ha cambiado de licencia, de GPL a Apache a partir de la versión 2.7.0. Está basado en Ruby, pero las descripciones de configuraciones se escriben en modo declarativo. Existen paquetes construidos que ya vienen en el sistema de paquetería para las principales distribuciones Linux, en nuestro caso usaremos Debian Squeeze y los paquetes a los que tenemos acceso en su repositorio. También tienen soporte para otros sistemas UNIX como Solaris, *BSD o Mac OS X. Y en desarrollo tienen un soporte básico de sistemas Windows.

El desarrollo es público desde 2006 y destaca por su estabilidad y facilidad de manejo, aunque como todo este tipo de herramientas, la curva de aprendizaje, no es muy liviana. Entre los principales clientes de la solución enterprise para empresas destacan empresas como Nokia, RackSpace, Zynga, Twitter, Digg, …

En este post, veremos como configurar Puppet en Debian Squeeze y podremos ver dos ejemplos de aplicación de configuraciones.

¿Porqué escribir sobre puppet?

Nunca he profundizado en el uso puppet, nunca más allá que algunas de pruebas de concepto o funcionalidad y es por esta razón quiero escribir esta serie de posts, obligarme a conocer mucho mejor esta herramienta. En nuestro caso queremos usar puppet para controlar un entorno virtualizado con libvirt. Nuestro objetivo es controlar solo a Guests, es decir, máquinas virtuales, debido a que este es el entorno más heterogéneo y difícil de mantener, entre nuestros componentes Hosts/Guests. Se supone, que en un sistema de virtualización relativamente grande, todo está controlado mediante una herramienta de orquestado, ya seas herramientas basadas en VMWare como vCenter o vSphere o del tipo RedHat RHEV / Ovirt, Proxmox, Eucalyptus, OpenStack … Por tanto, los nodos de virtualización deberían estar bastante controlados.

Para la siguiente prueba usaremos tres máquinas procedentes de una misma plantilla de kvm con una instalación de debian6 básica. En otro artículo hablaré sobre como crear templates de kvm, pero para nuestro caso, imagínate que son 3 máquinas virtuales recién instaladas usando virt-manager. En una de las máquinas instalaremos lo que se denomina Master, que será el servidor encargado de gestionar la configuraciones del resto.

El objetivo de la prueba enviar un par de ficheros a los clientes, cliente1 y cliente2 a partir de ahora. Uno de estos ficheros tendrá un contenido diferente según sea el receptor del fichero cliente1 o cliente2.

En la segunda prueba, instalaremos un par de paquetes y al igual que en la prueba anterior, nos aseguraremos de que el paquete 1 se instale en las dos máquinas, y que además, en el cliente1 se instale el paquete 2 y el paquete 3.

Tras bucear un poco en la red, no he encontrado ninguna guía actualizada para debian 6 (squeeze), pero sí que he podido localizar muchas guías de introducción, con las que he ido recomponiendo este post.

En mi caso, me ha ayudado bastante tanto la documentación de puppet como esta Introducción a Puppet de la Universidad de Florida. Aunque en este último caso, los ejemplos hablan de debian lenny, es decir, una versión de debian anterior. Realmente, como veremos en los ejemplos, no hay mucha diferencia entre la configuración de Lenny y Squeeze, lo que nos permite confiar en la estabilidad del código.

Antes de empezar

Antes de empezar, nos debemos asegurar de que los nombres de las máquinas resuelven correctamente entre ellas. Esto nos permitirá olvidarnos de problemas con certificados y similares, que son difíciles de depurar después.

En mi caso, las dos máquinas clientes, tienen en el /etc/hosts una línea que hace referencia al master, de forma que tiene un nombre del tipo master.cluster. Además, en la máquina master.cluster tengo registrado los nombres de los clientes como client1 y client2.

Por tanto, para verificar que todo está correctamente en cuanto a DNS debemos asegurarnos que tenemos valores de este tipo para el comando hostname

root@master:~# hostname
master
root@master:~# hostname -f
master.cluster

Es un error muy habitual, que por ejemplo hostname -f nos de localhost o localhost.localdomain. Esto es debido a que la línea donde debemos especificar el alias hacia nuestra máquina, debe ser la primera del fichero /etc/hosts

Preparando el master

Instalamos el paquete puppetmaster.

apt-get install puppetmaster

Una vez la instalación haya finalizado, hay que configurar el directorio donde se compartiran los ficheros, así que rango de IPs tendrá acceso al directorio de ficheros y plugins.

Abrimos el fichero fileserver.conf

editor /etc/puppet/fileserver.conf

Si estás usando libvirt para gestionar la máquina y usas la configuración de red que viene por defecto, tus máquinas virtuales tendrán una IP dentro del rango 192.168.122.0/24 . Por tanto, para nuestro ejemplo, usaremos este rango. Con esto, el fichero fileserver.conf quedaría de esta forma:

[files]
path /etc/puppet/files
allow 192.168.122.0/24
[plugins]
allow 192.168.122.0/24

También puedes usar nombres DNS, o directamente, permitir a todo el mundo con una regla del tipo allow *. Puedes ver más información en la doc de puppetlab sobre este fichero de configuración.

Ahora vamos a crear los ficheros básicos de manifest casi vacíos.

Primero creamos el fichero /etc/puppet/manifests/nodes.pp

node pruebanode {}
node 'client1.cluster' inherits pruebanode {}
node 'client2.cluster' inherits pruebanode {}

Para que este fichero sea tomado en cuenta, hay que crear el fichero /etc/puppet/manifests/site.pp e incluir el fichero nodes.pp que hemos comentado antes. En las reglas de estilo de puppet indican que además habría que crear en este directorio un fichero modules.pp e importarlo desde site.pp, pero en nuestro caso no va a ser necesario porque los modulos que crearemos se importarán automáticamente.

Este es el contenido del fichero /etc/puppet/manifests/site.pp

import "nodes"

También es conveniente saber que el nombre del servicio en el servidor es puppetmaster. Por tanto, para reiniciarlo, ejecutaríamos algo como:

service puppetmaster restart

Preparando los clientes

Este proceso lo repetiremos en cada uno de las máquinas que queremos controlar.

Instalamos el paquete puppet

apt-get install puppet

Revisamos el fichero de configuración del cliente, que debería lucir así:

root@client1:~# cat /etc/puppet/puppet.conf
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
[agent]
server=master.cluster

Para que pueda funcionar puppetd, el demonio que funciona en los clientes, es necesario habilitarlo. Hay que editar el fichero /etc/default/puppet

editor /etc/default/puppet

Y debemos asegurarnos que START está confirado como yes

Arrancamos el servicio puppet con service

service puppet start

Una vez realizado esto, nos debemos fijar en el syslog del cliente, si vemos líneas con información como esta:

Could not request certificate: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key

Está claro que algo no está funcionando. Verifica la configuración de DNS antes de instalar como comenté en la sección de Antes de empezar

Ahora procedemos a verificar desde el master que se han registrado correctamente los identificadores de las firmas de los clientes:

root@master:~# puppet cert --list --all
client1.cluster (00:00:ssl_fingerprint:00:00)
client2.cluster (00:00:ssl_fingerprint:00:00)
+ master.cluster (00:00:ssl_fingerprint:00:00)

Tenemos que firmar los certificados de los clientes

root@master:~# puppet cert --list
client2.cluster
client1.cluster
root@master:~# puppet cert --sign client1.cluster
notice: Signed certificate request for client1.cluster
notice: Removing file Puppet::SSL::CertificateRequest client1.cluster at '/var/lib/puppet/ssl/ca/requests/client1.cluster.pem'
root@master:~# puppet cert --sign client2.cluster
notice: Signed certificate request for client2.cluster
notice: Removing file Puppet::SSL::CertificateRequest client2.cluster at '/var/lib/puppet/ssl/ca/requests/client2.cluster.pem'

Creación de un módulo básico y asignación de clientes al módulo

Podemos tener varios módulos. En un módulo es donde definiremos todas las configuraciones y ficheros de un perfil de máquinas. También se puede tener una configuración determinada. Como ejemplo, podríamos tener un módulo para configurar un LAMP y luego otro para poder desplegar Drupal en el LAMP. Puedes ver más información en La doc de puppet

Creamos la estructura básica:

mkdir -p /etc/puppet/modules/prueba/{manifests,files,templates}

Creamos un fichero vacío donde pondremos luego la receta de puppet

touch /etc/puppet/modules/prueba/manifests/init.pp

Ahora editamos el fichero de configuración de nodos. Este fichero lo tendremos en la ruta /etc/puppet/manifests/nodes.pp y deberá tener este aspecto:

node pruebanode {
    include prueba
}
node 'client1.cluster' inherits pruebanode {}
node 'client2.cluster' inherits pruebanode {}

Con esto, tendremos el modulo prueba aplicado a client1 y client2.

Prueba 1: Distribución de ficheros

La primera prueba que realizaremos será colocar un fichero en una ruta en concreto de las dos máquinas.

En el directorio /etc/puppet/prueba/files creamos un fichero llamado ficherodeprueba que contiene solo la siguiente frase:

esto es un fichero de prueba

Ahora nos dirigimos al init.pp del módulo prueba en /etc/puppet/modules/prueba/manifests/init.pp y ponemos el siguiente contenido

class prueba {
    file { "/root/ficherodeprueba":
        owner   => root,
        group   => root,
        mode    => 400,
        source  => "puppet:///modules/prueba/ficherodeprueba",
    }
}

Normalmente, la configuración puede tardar bastante tiempo en aplicarse, para forzarla vamos a ejecutar el siguiente puppetrun en el master.

Además, si queremos verificar si funciona, puede ser de utilidad ejecutar el proceso de actualización de forma manual y en modo de depuración, para esto ejecutaríamos en el cliente:

root@client1:~# puppetd -vt && ls
info: Caching catalog for client1.cluster
info: Applying configuration version '1322082679'
notice: Finished catalog run in 0.05 seconds
ficherodeprueba

Prueba 2: Instalación de software procedente de paquetería

En esta prueba, vamos a instalar un paquete diferente en cada máquina. En client1 instalaremos nginx y en client2 instalaremos el paquete memcached.

Comenzamos con la creación del módulo para instalar nginx. Lo vamos a llamar httpd y empezamos creando la estructura de directorios en el master:

mkdir -p /etc/puppet/modules/httpd/{manifests,files,templates}

Ahora en files crearemos un fichero estático para ser servido por nginx. Creamos el fichero en /etc/puppet/modules/httpd/wp-content/uploads/texto y añadimos unas cuantas líneas de texto plano.

Hay que crear el manifiest en /etc/puppet/modules/httpd/manifests/init.pp con el siguiente contenido:

class httpd {
    package { "nginx":
         ensure => latest,
    }
    file { "/var/www/texto":
        owner => "www-data",
        group => "www-data",
        mode => 640,
        ensure => present,
        source => "puppet:///httpd/texto"
    }
    service { "nginx::server":
        name => nginx,
        ensure => running,
        enable => true
    }
}

En este manifest, tenemos tres pasos. Primero instalamos el paquete nginx, después incorporamos un fichero en un ruta de servicio y después arrancamos el servicio nginx y nos aseguramos de que esté arrancado.

Para que se aplique esta ejecución en el servidor client1, tenemos que incorporar la asignación en el fichero /etc/puppet/manifests/nodes.pp con lo que el fichero quedaría como sigue:

node pruebanode {
    include prueba
}

node 'client1.cluster' inherits pruebanode {
    include httpd
}

node 'client2.cluster' inherits pruebanode {}

Esta vez solo lo hemos incorporado en client1.cluster para que solo se instale en este servidor.

Una vez salvemos este fichero, cuando toque actualizar, o si forzamos simplemente reiniciando el agente en el cliente con service puppet restart, podremos ver si se ha instalado el paquete nginx, si está funcionando y si además, se puede acceder al fichero de texto que hemos enviado.

Ahora vamos con la instalación memcached, creamos los directorios necesarios:

mkdir -p /etc/puppet/modules/memcached/{manifests,files,templates}

Hay que crear el manifiest en /etc/puppet/modules/memcached/manifests/init.pp con el siguiente contenido:

class memcached {
    package { "memcached":
        ensure => latest
    }

    service { "memcached::server":
        name => memcached,
        ensure => running,
        enable => true,
    }
}

Tras guardar, añadimos tal y como hicimos con nginx (httpd) en site.pp, este módulo en la parte de client2, con una línea que contenga include memcached . Una vez hecho esto, es cuestión de esperar a que se apliquen los cambios, o forzar a que se apliquen reiniciando el agente en el cliente.

Pues sí que quedó largo al final.

Mis impresiones sobre la Apache Barcamp 2011 celebrada en Sevilla

Fri, 14 Oct 2011 04:16:25 +0000

He publicado un post en el blog de Yaco sobre la Apache Barcamp celebrada este fin de semana en Sevilla.Yaco en la Apache Barcamp España 2011 en Sevilla

Hay que seguir de cerca al proyecto ownCloud

Tue, 11 Oct 2011 17:15:42 +0000

Monta un owncloud y tendrás un sistema web para compartir ficheros. Bueno, eso era antes, ya se ha publicado la versión 2.0 y ahora es algo más que compartir ficheros. Tienes la posibilidad de escuchar tu música almacenada en el servidor, tener un listado de marcadores web o bookmarks, un calendario y una agenda. Lo tienes en tu servidor y funciona incluso en sharing hostings baratos tipo DreamHost. Con licencia AGPL

Lo que me gusta es su simpleza, si tienes disponible un servidor web con php5, conseguir que funcione es muy fácil. Descomprimir y acceder a la url correcta. Al acceder la primera vez nos pide el nombre del usuario administrador y crea la base de datos en sqlite. Y ya queda listo para usar.

Soporta webdav para poder exportar los contenidos. De esta forma, si el servidor donde lo tenemos desplegando lo permite, podremos disponer de acceso desde un navegador de ficheros, ya sea usando davfs2 para montarlo o accediendo desde gnome o kde. No he conseguido que me funcione correctamente el uso de webdav y nginx, pero es que realmente, el soporte de webdav en nginx está aún muy verde.

En esta base de datos se controlan los usuarios y las quotas de disco de cada uno. También se pueden tener grupos y compartir ficheros entre usuarios, entre grupos o publicarlos mediante un enlace con un hash.

Una vez hemos subido algunos ficheros, nos podemos centrar en la parte del almacenado de ficheros. Se crea un directorio por usuario creado y dentro de este otro directorio files que es donde residen los ficheros subidos. La ventaja es que si subes un fichero sin pasar por la web, este sí que se verá en la web. De este modo, sería fácil incorporarlo a un sistema con homes UNIX desplegados mapeando los usuarios correctamente. Se le puede indicar donde reside la raíz de los datos.

Se pueden tomar usuarios desde un ldap, y también ofrece la posibilidad de servir de fuente de autenticación OpenID, aunque no he visto como hacer el camino inverso, es decir, autenticare en ownCloud mediante un id OpenID externo.

En la versión de desarrollo tienen incorporadas una app de galería de imágenes y otra para editar ficheros de texto plano en el servidor. Por otro lado, Rekonq, el navegador de KDE4, permite sincronizar los bookmarks con ownCloud. Sería interesante que se pudieran sincronizar con Firefox y Chrome.

La creación de aplicaciones no parece muy complicada y además tienen ya planteado un repositorio de aplicaciones en la web del proyecto.

¿Qué cosas faltan para que pueda ser un reemplazo de dropbox y similares? Lógicamente, aún queda mucho trabajo por hacer, entre otras cosas, aplicaciones locales que faciliten la integración con el escritorio, aún así, accediendo a los contenidos mediante webdav/https, nos quitaríamos el problema de muchas redes corporativas donde resulta complicado abrir nuevos puertos y en otros entornos menos hostiles, se podría incorporar acceso ftp/smb/sshfs a las carpetas de usuario, dando así más posibilidades de integración sin llegar a tener aplicaciones.