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

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.

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"><code>&quot;, $body);
  $body = str_replace(&quot;&lt;/code&gt;&quot;, &quot;</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.

¿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 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.

...
export SMBLOG=/usr/local/etc/smb.log
init_logger () {
date > $SMBLOG
}
logger () {
$@ >> $SMBLOG
}
enable_samba () {
sleep 20
cd /tmp/package/script
logger ./configsamba
logger ./samba start
logger date
}
init_logger
logger /sbin/udhcpc -i eth0 -n -s /etc/udhcpc.script -r 3
enable_samba &

Este script, deja el rastro de la salida de los comandos en el fichero /usr/local/etc/smb.log . De esta forma, sino funciona, podemos ver que ha ocurrido.
Dejo como adjunto mi fichero rcS con los cambios realizados.
Para copiar este fichero al hdp-r1 tendríamos que hacer lo siguiente:

1. Descomprimir el fichero rcS.tar.gz y copiar el fichero rcS en un pendrive
2. Enchufar el pendrive al hdp-r1 y asegurarnos de que no hay ninguna otra unidad conectada. Necesitamos la conexión de red.
3. Encender el aparato desde el mando, ir a Peliculas » Carpeta » Red . Con esto nos aseguramos que se conecte a la red.
4. Mirar la ip del aparato en la configuración, para ello, pulsamos en setup, Nos desplazamos hacia la izquierda hasta que llegemos a RED y podemos ver la ip
5. Ejecutamos telnet ip en nuestro pc con acceso a la red
6. Para acceder indicamos que somos root, no se nos pedirá contraseña
7. Una vez dentro comprobamos que se ha montado correctamente el pendrive ejecutando
   

   ls /mnt/usbmounts/sda1

8. Entonces, ejecutamos los siguientes comandos, uno a uno.
   

   cp /usr/local/etc/rcS /usr/local/etc/rcS.old
   cp /mnt/usbmounts/sda1/rcS /usr/local/etc/rcS
   reboot

9. Tras reiniciar, sobre unos 30 segundos después, el servicio de samba debe haber arrancado. Si exploramos la red, ya sea con windows o con linux con los paquetes de samba instalados, veremos la máquina Venus en el grupo de trabajo Workgroup.

Se ha comprobado que si no hay unidad usb, el servicio arranca, pero no comparte nada. Además, si no hay conexión de red, el servicio no arranca pero no entorpece el arranque del sistema de Asus.
La velocidad de transferencia, tanto copiando al asus como desde el asus me han parecido más que aceptables para una red a 100M, en torno a los 6-9MB/s y si copiamos algo vía wifi, entorno a los 2MB/s. Eso sí, si intentamos reproducir contenidos vía lan en el asus mientras estamos realizamos alguna transferencia, el rendimiento de la reproducción decae bastante.
NOTAS:

• He cambiado pirlo por pirlas tal y como me ha sugerido dicho usuario en el primer post.

{lang: 'es'}
]]> http://www.ant30.es/2010/06/asus-oplay-hdp-r1-como-servidor-nas/feed/ 20 http://www.ant30.es/2010/04/renovacion-del-software-del-blog/?utm_source=rss&utm_medium=rss&utm_campaign=renovacion-del-software-del-blog http://www.ant30.es/2010/04/renovacion-del-software-del-blog/#comments Sun, 18 Apr 2010 07:24:43 +0000 ant30 http://www.wordpress.ant30.es/?p=67 Continue reading →]]> Con los ataques de spam de la semana pasada y la lluvia del fin de semana, he tenido algo de tiempo que dedicar al mantenimiento del blog.
Además, del cambio de aspecto, hay otros cambios importantes.
Como solución al spam, he pasado de usar comentarios con autenticación con OpenID a dejar comentarios libres pero con un filtro antispam basado en Akismet. Con el módulo AntiSpam, se puede usar este filtro usando una WordPress API Key de forma gratuita. Además, permite seleccionar otros servicios de filtros antispam como TypePad AntiSpam y Defensio. De momento, ya ha marcado un comentario como spam de forma correcta. Creo que usar esta clase de filtros antispam en vez de usar el típico Captcha o requerir autenticación de algún tipo, puede ser bastante beneficioso para la usabilidad de cualquier sitio web. Con la misma idea he metido Facebook Connect, pero no me gusta demasiado el resultado.
Por otro lado, hemos incorporado un theme para que se pueda visualizar el blog en móviles. Esto daría para un pequeño artículo, pero básicamente se trata de usar el tema Nokia Mobile y un Selector de tema para móviles basado en Browscap.
Al cambio de aspecto, aún le falta un repaso, pero de entrada tengo que comentar que está basado en Fusion Themes que usa Skinr
También he incorporado el servicio AddToAny que permite a los visitantes publicar el Link en sus redes sociales.
Seguro que se me queda alguna cosa en el tintero, pero sí, ha sido un buen ejercicio de prácticas de administración de drupal.



{lang: 'es'}
]]> http://www.ant30.es/2010/04/renovacion-del-software-del-blog/feed/ 0 http://www.ant30.es/2010/04/prueba-de-conexion-a-twitter/?utm_source=rss&utm_medium=rss&utm_campaign=prueba-de-conexion-a-twitter http://www.ant30.es/2010/04/prueba-de-conexion-a-twitter/#comments Sat, 17 Apr 2010 16:59:35 +0000 admin http://www.wordpress.ant30.es/?p=66 Probando conexión de mi blog con twitter

{lang: 'es'}
]]> http://www.ant30.es/2010/04/prueba-de-conexion-a-twitter/feed/ 0 http://www.ant30.es/2010/01/android-al-final-me-quedo-con-super-d/?utm_source=rss&utm_medium=rss&utm_campaign=android-al-final-me-quedo-con-super-d http://www.ant30.es/2010/01/android-al-final-me-quedo-con-super-d/#comments Sun, 24 Jan 2010 12:16:32 +0000 ant30 http://www.wordpress.ant30.es/?p=65 Continue reading →]]> Este fin de semana ha sido un caos de tantas pruebas de roms que he hecho gracias a los amigos de los foros de xda-developers.
¿Porqué cambia uno de rom? La respuesta es fácil, hay ciertas necesidades que no se me cumplen con la rom que usaba mi dispositivo. Llevo usando los firms de cyanogen desde que dude y haykuro dejaron de aparecer. Sin embargo, en los últimos tiempos, sentía como la ROM iba a pedales. No es normal que al empezar a escribir con el teclado, tengas un lag de varios segundos y que la carga del sistema esté rondando entre 2 y 3 casi todo el día. Así como que la swap estuviese casi siempre saturada. Lógicamente, todo esto hace que la experiencia Android se convierta en un poco desagradable. Así que tocaba probar con los siguientes requisitos:
• El bluetooth debe de funcionar de forma completa, y la app del market, bluetooth file transfer funcione tanto para los ficheros como para los contactos. Y lo más importante de bluetooth en mi caso es que sea capaz de conectarse al manos libres del coche, un Parrot CK3100 Evolution con firm 5.11c
• Velocidad de respuesta y estabilidad. No me importa que no siempre valla a más de 25fps todas las animaciones, ni que estén activadas todas los efectos. Pero sí que quiero tener la sensación de que el terminal responde a mis dedos y no que lo hace unos cuantos segundos después.
• Conectividad wifi. La mayoría de firms tienen el mismo soporte de wifi, con que funcione es más que suficiente.
• Por supuesto, deben funcionar la localización y My Maps Editor, así HTC_IME como teclado virtual aunque sea instalándolo mediante adb. Este último debe funcionar con soltura.
• La home debe responder al acelerómetro para cambiar de vista horizontal a vertical y viceversa.

He probado varios firms Eclair tanto 2.0 como 2.1 y la mayoría de ellos me han dejado buen sabor de boca. Muchas de ellas ya sabía que no tenían algunos de los requisitos. Como el funcionamiento de bluetooth, el funcionamiento de la cámara, la no grabación de vídeo existente aún en las 2.x para el Dream y la falta de drivers 2D/3D para estas versiones. Sin embargo, la velocidad del termina era bastante aceptable. Incluso el paso de horizontal a vertical y viceversa tenían buena velocidad. Sin embargo, para la mayoría de firms de estas versiones, el soporte de bluetooth no parece estar completo.
Tras realizar pruebas con las 2.x estaba claro que tenía que pasar a firms 1.6 si quería estabilidad y entonces fue cuando usé la recomendación de @hugopvigo de usar Super D. Esta ROM tiene el hack de los 10M más de RAM, soporte de swap y en general es como una cyanogen pero los binarios han pasado por un zipalign. Lo que mejora sustancialmente el rendimiento del sistema, al estar los apk y compañía más optimizados para su ejecución.
Con esta firm desde cero, wipe + ext3 en sd formateada, me ha funcionado el bluetooth sin hacer nada, simplemente instalando la aplicación que he citado antes. He podido enviar unos cuantos contactos al Parrot y encima el móvil, se desenvuelve con normalidad aún ejecutando unos 12-14 servicios.
En concreto estoy usando la versión estable 1.6 de las publicadas en este hilo: http://forum.xda-developers.com/showthread.php?t=613809



{lang: 'es'}
]]> http://www.ant30.es/2010/01/android-al-final-me-quedo-con-super-d/feed/ 1 http://www.ant30.es/2010/01/trucos-android-apagado-de-emergencia/?utm_source=rss&utm_medium=rss&utm_campaign=trucos-android-apagado-de-emergencia http://www.ant30.es/2010/01/trucos-android-apagado-de-emergencia/#comments Sat, 23 Jan 2010 12:29:16 +0000 ant30 http://www.wordpress.ant30.es/?p=64 Continue reading →]]> No es la primera vez que tras instalar un nuevo firmware, mi maltrecho HTC Dream no termina de arrancar. Al principio de mis tiempos con android, lo primero que se me ocurría era quitar la batería. Desde luego es la solución más drástica y que seguro que funciona. Pero claro, si desmontas unas diez o veinte veces la parte trasera del móvil simplemente para sacar la batería, la tapa cogerá holgura.
En el arranque, tras haber pasado ya la fase de inicio en la que vemos el logo de la compañía, en mi caso Movistar, el terminal ya es capaz de recibir comandos vía adb. Esto nos permite hacer ciertas operaciones mientras el móvil arranca, y en el caso que ahora nos interesa podemos realizar dos importantes acciones que son apagar o reiniciar el móvil.
Para ejecutar estas acciones desde el pc conectado por usb al móvil y sabiendo de antemano que tenemos adb funcionando tendríamos que lanzar los siguientes comandos:

Reiniciar:

$ adb shell reboot

Apagar:

$ adb shell reboot -p

Un ejemplo para el que necesitamos el comando de apagado es cuando una rom no termina de arrancar para poder llegar a la pantalla de restauración o recovery. A esa que llegamos si arrancamos el androide dejando pulsado el botón de la casita y a su vez el de encendido.


{lang: 'es'}
]]> http://www.ant30.es/2010/01/trucos-android-apagado-de-emergencia/feed/ 0 http://www.ant30.es/2010/01/y-que-hago-yo-con-el-blog/?utm_source=rss&utm_medium=rss&utm_campaign=y-que-hago-yo-con-el-blog http://www.ant30.es/2010/01/y-que-hago-yo-con-el-blog/#comments Wed, 20 Jan 2010 13:17:01 +0000 ant30 http://www.wordpress.ant30.es/?p=63 Continue reading →]]> Solo con ver la última entrada, que era una prueba, y su fecha, está claro que tengo abandonado este blog. Sin embargo, me resisto a deshacerme de él.
Digamos que perdí el hábito de la escritura de textos de más de 140 caracteres hace bastante tiempo. Y sin embargo, durante estos meses de abandono sí que he sentido la necesidad de publicar cosas. De ahí que haya algunas en la lista de salida como borrador, pero no saldrán por estar ya más que desfasadas.
Una posible opción para fuente de contenidos sería hablar de las aplicaciones de Android que suelo ir probando. Algunas más útiles que otras, algunas las descubro en el market mientras viajo en el autobús, otra son recomendaciones de amigos y conocidos y otras, de webs. Pero lo cierto es que rara es la semana que no pruebo unas cuantas aplicaciones.
Concluyendo ya, espero poder tener la fuerza de voluntad necesaria como para ir poniendo los reportes de las aplicaciones que vaya probando a partir de ahora. Por lo menos así recordaré lo bueno y lo malo de las aplicaciones que he usado.


{lang: 'es'}
]]> http://www.ant30.es/2010/01/y-que-hago-yo-con-el-blog/feed/ 0 http://www.ant30.es/2009/09/cambiando-de-hosting/?utm_source=rss&utm_medium=rss&utm_campaign=cambiando-de-hosting http://www.ant30.es/2009/09/cambiando-de-hosting/#comments Fri, 18 Sep 2009 11:58:48 +0000 ant30 http://www.wordpress.ant30.es/?p=62 Continue reading →]]> Tras dos años teniendo como hosting a 1and1.es , he decidido cambiar de hosting hacia DreamHost. En un principio, seguiré usando como registrador de dominio a 1and1.es. Por 5€ al año el dominio “.es” es un precio bastante asequible.
Y respecto al espacio, teniendo en cuenta que en dreamhost dan un poco más de holgura respecto a 1and1 y ya tengo varias web alojadas en esa cuenta, pues he acabado decidiéndome por el cambio.
Este post se ha escrito bajo un dominio de prueba en dreamhost con la intención de comprobar el cambio correcto de dns.

{lang: 'es'}
]]> http://www.ant30.es/2009/09/cambiando-de-hosting/feed/ 0 http://www.ant30.es/2009/08/capturas-y-marcador-para-firefox-dashboard/?utm_source=rss&utm_medium=rss&utm_campaign=capturas-y-marcador-para-firefox-dashboard http://www.ant30.es/2009/08/capturas-y-marcador-para-firefox-dashboard/#comments Wed, 19 Aug 2009 11:46:10 +0000 ant30 http://www.wordpress.ant30.es/?p=61 Continue reading →]]> Buscando si existía un plugin para capturar zonas de una ventana de firefox y que además incorporase un marcador o algo para resaltar una zona de esa captura, me he encontrado con este plugin: DashBlog.
Permite capturar tanto una imagen, como un vídeo de una página (ideal para efectos js/ajax). Y además, permite escribir, poner flechas o dibujar a mano alzada. Pero es que además de esto, permite publicar esta captura directamente en WordPress, Blogger/Blogspot, Tumblr, aunque esto último no he conseguido que me fucione.
Lo bueno es que te salva de tener que abrir GIMP para remarcar una zona, o incluso recortar una zona de la pantalla sino quieres tener instalado/activo el plugin ScreenGrab.
Puedes ver los resultados en la captura de ejemplo, en la zona inferior derecha.
Una lástima que el plugin aún no funcione para Firefox 3.5


{lang: 'es'}
]]> http://www.ant30.es/2009/08/capturas-y-marcador-para-firefox-dashboard/feed/ 1 http://www.ant30.es/2009/08/terminales-ligeros-la-solucion-para-las-aulas-de-formacion/?utm_source=rss&utm_medium=rss&utm_campaign=terminales-ligeros-la-solucion-para-las-aulas-de-formacion http://www.ant30.es/2009/08/terminales-ligeros-la-solucion-para-las-aulas-de-formacion/#comments Tue, 11 Aug 2009 12:13:23 +0000 ant30 http://www.wordpress.ant30.es/?p=60 Continue reading →]]> Tras llevar bastante tiempo ligado a los servicios web, tanto en el desarrollo como en el despliegue y mantenimiento de esta clase de sistemas, ahora tengo la oportunidad de trabajar en un proyecto mucho más relacionado con Sistemas directamente y el comúnmente llamado “cacharreo”.
Se trata de incorporar a una serie de aulas de formación, un sistema basado en clientes ligeros y servidor, usando para ello Tcos.
El hecho de incorporar este tipo de arquitectura a las aulas es beneficioso por varios motivos:
• Fácil administración de todos los equipos del aula. Ahora todos los puestos usarán el mismo sistema, que será servidor y procesado por el servidor
• Ahorro en máquinas. Los clientes ligeros tienen un tiempo de vida muy superior al de un equipo normal. En un aula con equipos normales, hay que renovar equipos cada 3 o 5 años, porque se han quedado obsoletos. En un aula con clientes ligeros. Pasado este tiempo, solo habría que cambiar el servidor si se necesita más rendimiento.
• Consumo energético. En el caso de usar clientes ligeros, tenemos terminales con consumos desde 5w, y máximo de 20w. El PC de un puesto normal, con estar encendido ya viene a consumir 60-80w como mínimo.
• Reutilización de equipos viejos. Se pueden usar equipos antiguos con poca ram (a partir de 64MB, o un incluso menos), sin disco duro, ni disquettes. Solo necesitan una tarjeta de red que soporte arranque con PXE o una disquetera para emular el arranque PXE con etherboot
• Además, si decidimos usar Linux y la alternativa fuese windows, nos ahorramos el precio de licencia por puesto.

Dejo pendiente para otros días analizar alguno de los principales sistemas que tenemos para ofrecer este tipo de servicio, como son LTSP, Tcos, PXEs, …



{lang: 'es'}
]]> http://www.ant30.es/2009/08/terminales-ligeros-la-solucion-para-las-aulas-de-formacion/feed/ 0 http://www.ant30.es/2009/05/pasandome-a-android/?utm_source=rss&utm_medium=rss&utm_campaign=pasandome-a-android http://www.ant30.es/2009/05/pasandome-a-android/#comments Sun, 17 May 2009 09:43:17 +0000 ant30 http://www.wordpress.ant30.es/?p=59 Continue reading →]]> Tras unos meses de espera, ya puedo decir que tengo un móvil con Android. En concreto una HTC Dream de Movistar, pero que ya corre su cupcake gracias un post en el foro de and.roid.es. Va a la perfección, se nota mucho la evolución de la 1.1 a la 1.5, con el teclado virtual entre otras cosasl
¿Abandono Symbian? la verdad es que el n70 no me ha dejado muy buen sabor de boca, la inestabilidad le hacía bastante deprimente. Ciertos problemas con bluetooth y la asociación con otros dispositivos hacía que la batería se esfumase en unas pocas horas y solo de vez en cuando. Sin embargo, para mí llevar activado bluetooth era casi obligado, por el tema del manos libres del coche o durante aquella época de desarrollos con esta tecnología inalámbrica.
No, no voy a abandonar a Symbian, estoy buscando un móvil pequeño, espero que con symbian, que haga buen reemplazo del n70 y complemente al dream. Hay veces que se necesita llevar un móvil pequeño y la verdad es que la HTC es ladrillo al lado de un 6600 slide, sin symbian o el mismo 6210 navigator, con symbian. A ver si logro encontrar algún stock del 6120 classic.
Por cierto, que tengo esto del blog casi abandonado, a ver si ahora voy sacando cosas para escribir. Alguna sobre algún que otro proyecto hay pendiente.


{lang: 'es'}
]]> http://www.ant30.es/2009/05/pasandome-a-android/feed/ 0 http://www.ant30.es/2009/03/plugin-jquery-jquery-flickrutils-js/?utm_source=rss&utm_medium=rss&utm_campaign=plugin-jquery-jquery-flickrutils-js http://www.ant30.es/2009/03/plugin-jquery-jquery-flickrutils-js/#comments Sun, 01 Mar 2009 12:54:00 +0000 ant30 http://www.wordpress.ant30.es/?p=58 Continue reading →]]> Hace unos meses comencé a mirar la api pública de flickr, entre otras cosas por la necesidad de facilitarme el enlace desde este mismo blog a fotos de flickr.
En primer lugar, quería hacer una especie de selector en que el se me permitiese realizar búsquedas por tags y nombres, quizás por fechas, incluso fotos de otros usuarios. En un principio, pensando solo en que fuese compatible con Drupal.
Al final, ayer sábado por la mañana, decidí retomar lo que tenía hecho de aquel día y además de intentar aprender un poco de jQuery, conseguir algo que sea fácilmente portable a cualquier sistema web donde se pueda usar jQuery.
Entre alguna de las funciones que ya podemos encontrar son:
• Buscador de fotos permite devolver lo obtenido a una función “callback” donde se pasa una lista de id de fotos. El callback que viene por defecto mete estos ids en un input. Aún le queda mucho por maquetar y mucho por revisar en la funcionalidad, pero parece funcionar.
• Carga de fotos Ya tenemos una lista de ids, ahora queremos poder cargarla en algún div. Para esto teníamos varias opciones. y al final he ido implementando casi una por una.
  • Imágenes en un link a la vista pública de la imagen en flickr.
  • Imágenes en un link a la misma imagen pero en otro tamaño.
  • Buscar un formato en todo el documento y reemplazarlo por imágenes

El enlace al proyecto en Google Code:

jquery-flickr-utils

Enlace a una demo con lo que hay a fecha de publicación de este post:

Demo

Para obtener la información necesaria uso la API rest de la que tenemos disponible una esplendida documentación a través de flickr. Y recalco lo de espléndida documentación porqué sin ella, no sirve de nada tener una API.
A ver si termino de ponerlo un poco bonito y lo empaqueto como plugin para drupal.



{lang: 'es'}
]]> http://www.ant30.es/2009/03/plugin-jquery-jquery-flickrutils-js/feed/ 3 http://www.ant30.es/2009/02/plugin-de-gedit-geditchecker-asistente-para-anlizadores-de-codigo-pyflakes-y-pep8-incluidos/?utm_source=rss&utm_medium=rss&utm_campaign=plugin-de-gedit-geditchecker-asistente-para-anlizadores-de-codigo-pyflakes-y-pep8-incluidos http://www.ant30.es/2009/02/plugin-de-gedit-geditchecker-asistente-para-anlizadores-de-codigo-pyflakes-y-pep8-incluidos/#comments Tue, 24 Feb 2009 12:05:12 +0000 ant30 http://www.wordpress.ant30.es/?p=57 Continue reading →]]> Si el último post fue sobre un plugin de gedit, aquí va otro plugin. Un ayudante para que nuestro gedit pueda comprobar nuestro código, cuando salvamos el fichero. Lo que hay realizado, está hecho durante el tiempo sobrante después del almuerzo, y con esto, lo que quiero remarcar es la velocidad de desarrollo que aporta python y tener una api de plugins en este lenguaje como la que tiene Gedit, mi editor habitual cuando ando por escritorios.
En este caso se trata de un plugin para revisar la sintaxis del fichero que estamos editando al salvar. Para ello, en el caso de python, se ayuda para utilidades externas como pyflakes y pep8.py . Vuelva la salida de estos en un panel inferior, pero además, la funcionalidad extra que añade es que analiza las líneas de salida de los analizadores externos para que al clickearlas nos sitúe en la línea que se ha producido el error o warning.
Un compañero de trabajo también está realizando una utilidad para comprobar código css, haciendo uso de w3c, y también está incorporado. De esta forma, ha surgido la idea de hacer esto configurable mediante un panel de configuración en el que poder añadir nuevas “herramientas externas”, como las de gedit, o usar esas mismas, y poder asociarlas a extensiones de ficheros para que se asocien al evento de salvado de documentos. También estaría bien poder asignar parámetros extras a estos otros analizadores.
El enlace al proyecto en google code:

GeditChecker

El código del panel GeditChecker se publica bajo GPL, como se indica en el directorio. Las utilidades de testeo, tienen cada una su respectiva licencia.
De momento solo se ha probado en Intrepid Ibex que usa Gnome 2.24
Esto me ha recordado algo que se suele decir mucho en Software Libre, y era algo así como que si hay algo que falta en un programa, por qué no lo haces tú.



{lang: 'es'}
]]> http://www.ant30.es/2009/02/plugin-de-gedit-geditchecker-asistente-para-anlizadores-de-codigo-pyflakes-y-pep8-incluidos/feed/ 0