Como tomar screenshots automáticamente y convertirlos en video

Primer paso: crear la secuencia de screenshots, usando la utilidad "scrot":

• s=1; while /bin/true ; do scrot -q 80 "${s}.png" -e "convert -crop 800x600+0+24 ${s}.png ${s}.jpg" ; let s=s+1 ; sleep 1 ; done

Atención! Este comando sobrescribirá cualquier archivo preexistente! Para continuar una secuencia pre-existente, se puede cambiar el valor inicial de "s". Por ejemplo, si ya tenemos desde el archivo 1.png hasta el 71.png, podemos usar s=72:

• s=72; while /bin/true ; do scrot -q 80 "${s}.png" -e "convert -crop 800x600+0+24 ${s}.png ${s}.jpg" ; let s=s+1 ; sleep 1 ; done

Segundo paso: generar un video con dicha secuencia de archivos, usando "ffmpeg":

• ffmpeg -r 4 -b 512k -i %d.jpg OUTPUT.avi

Actualización: para que ffmpeg funcione, los nombres de los archivos deben ser secuenciales, y sin ningún archivo faltante. Por lo tanto, si antes de generar el video queremos borrar algunos archivos, vamos a tener problemas. Pero hay una forma muy fácil de crear una secuencia de archivos, arreglando los 'faltantes':

• max=1000 ; ren=1 ;  for f in `seq 1 $max` ; do [ -e $f.jpg ] && { [ $f -ne $ren ] && { echo mv -i $f.jpg $ren.jpg ; } ; let ren=ren+1 ; } ; done

Ese pequeño script generará por pantalla todos los 'mv' que hace falta ejecutar para arreglar la secuencia. Si quitamos el 'echo', el script ejecutará directamente el comando 'mv'. Ajustar 'max' al número más grande dentro de la secuencia.

os.path.normpath() de Python y las //

No es la primera vez que me sucede! Otra vez caí en el extraño funcionamiento  de os.path.normpath()!

os.path.normpath('/esto') = '/esto'
os.path.normpath('/esto/') = '/esto'
os.path.normpath('//esto') = '//esto'
os.path.normpath('//esto/') = '//esto'
os.path.normpath('///esto') = '/esto'
os.path.normpath('///esto/') = '/esto'

Quizá las 2 barras se mantienen al suponer que es un path referenciando algún recurso como se hace en las redes Windows, al estilo //equipo/recurso_compartido.

Solución: usar strip('/') y concatenar un '/' al inicio (suponiendo que siempre trabajamos con path absolutos).


'/' + os.path.normpath('/esto').strip('/') = '/esto'
'/' + os.path.normpath('/esto/').strip('/') = '/esto'
'/' + os.path.normpath('//esto').strip('/') = '/esto'
'/' + os.path.normpath('//esto/').strip('/') = '/esto'
'/' + os.path.normpath('///esto').strip('/') = '/esto'
'/' + os.path.normpath('///esto/').strip('/') = '/esto'

Para acceder Arduino desde Python y scripts shell

He creado una aplicación para acceder a Arduino desde Python. También incluyo unos ejempos para poder accederlos desde el shell. El proyecto está en https://github.com/hgdeoro/py-arduino-proxy

Utilizando un LM35 para medir la temperatura. Necesita 3 cables, 5V, masa, y la "señal".

En el Arduino, conecto los respectivos cables, y el de señal al puerto analógico 0.

El sensor lo dejo afuera, a pleno rayo de sol, y por ahora bajo la protección de un simple fondo de botella.

Agregar plugin de Munin

Sólo hacer un link del script al directorio de plugins:

root@eeepc:~# cd /etc/munin/plugins/
root@eeepc:/etc/munin/plugins# ln -s \
/usr/local/py-arduino-proxy/src/arduino_proxy/tests/analog_read_lm35_munin.py \
analog_read_lm35_munin_
root@eeepc:/etc/munin/plugins# mcedit ../plugin-conf.d/munin-node
## AGREGAR ESTO AL FINAL DEL ARCHIVO
[analog_read_lm35_munin]
user root
env.TTY_DEVICE /dev/ttyACM0
env.ANALOG_PORT 0

Y ahora sólo resta reiniciar munin-node.

root@eeepc:/etc/munin/plugins# service munin-node restart
munin-node start/running, process 22555
root@eeepc:/etc/munin/plugins# 

Y testear que todo haya quedado funcionando correctamente:

root@eeepc:/etc/munin/plugins# munin-run analog_read_lm35_munin
temp.value 10.11

Luego de dos días:

El circuito al que se conecta el LM35 sería así:

Para zafar del problema con Arduino + Ubuntu

He armado un sketch para "zafar" de los problemas que hay con los Arduinos cuando queremos accederlos desde Ubuntu. Sucede que por un bug, tendremos problemas al intententar subir sketchs desde Ubuntu, si en ese momento el Arduino envía información por puerto serial (por ejemlpo usando usando Serial.println()).

La solución definitiva es actualizar el firmware. Otra (la que implementé) es "pausar" la ejecución del programa, hasta que se detecta un "LOW" en el pin 12.

El programa es:





Y la forma de generar le "LOW" en el pin 12 sería:

Lo que hago es dejar la resistencia conectada, así el Arduino funciona con normalidad. Cuando necesito subir un programa nuevo, le saco la resistencia y lo reinicio, y puedo comunicarme sin problemas.

(Injusta) comparación de OpenStack Object Storage y MongoDB

Aclaración: antes que nada, quiero aclarar que no es justo para MongoDB compararlo con Object Storage. Mi intención es sólo comentar mi experiencia.

Ante la necesidad de guardar una gran cantidad de archivos en una aplicación web (más de 80GB), realicé pruebas con MongoDB (versiones 1.6.5 y 1.7.3), ya que entre las bases de datos NoSql, es la única que encontré que provee el API necesario para guardar y obtener  archivos almacenados (GridFS) (además permite ser configurado muy fácilmente para que los datos almacenados se repliquen entre distintas instancias de MongoDB). Pero me encontré con 2 problemas:

1. Poca eficiencia en la utilización del espacio en disco: en las pruebas realizadas, al insertar archivos por un total de 12GB, en disco se utilizó 21GB.
2. Dificultad para recuperar el espacio ocupado de archivos borrados: el borrado de los archivos es un "borrado lógico", y para recuperar el espacio que utilizan, hace falta ejecutar "repairdb()", que básicamente, hace una copia de la BD, de todos los datos no-borrados... esto es un problema si la base de datos es más grande que el espacio libre de la partición.

Este tipo de problemas los pude superar usando OpenStack Object Storage (versión 1.2.0):

1. Utilización de espacio en disco: al insertar archivos por 4202MB, en disco se utilizó 4281MB.
2. Recuperación de espacio en disco: el espacio es liberado al borrar los archivos.

En cuanto a las pruebas de stress:

• MongoDB en ningún caso dió error
• al realizar pruebas con Object Storage, he obtenido algunos "Read timed out" al momento de subir los archivos.

Cabe aclarar que MongoDB lo corria directamente en mi computadora, en cambio, Object Storage estaba instalado en una guest KVM.

En cuanto a la instalación:

• la instalación de MongoDB me llevó muy poco tiempo y es muy fácil
• la de Object Storage me costó más, sobre todo la utilización desde Java, ya que el cliente de Java necesita validar correctamente los certificados SSL con los que se configuró el servidor (algo que no pasa con el cliente Python).

Funciones privadas para unittest.assertRaises()

Para facilitar el uso de unittest.assertRaises() podemos usar funciones privadas. Esto al menos con python < 2.7 (ya que en python 2.7 assertRaises() permite ser usado como "context manager").

OpenStack Object Storage - Ejemplo con Python

Adjunto un pequeño ejemplo en Python.


----- Inicio del ejemplo -----

----- Fin del ejemplo -----

Probando OpenStack Object Storage

Luego de unas horas, pude tener andando mi instancia de OpenStack Object Storage. El servidor lo instalé en un Ubuntu 10.04.2 LTS (Lucid), siguiendo las instrucciones de Installing OpenStack Object Storage on Ubuntu.

Algunas cuestiones a tener en cuenta:

• En la página de "Configuring OpenStack Object Storage", al crear los "self-signed certs" utilizando el comando "openssl req -new -x509 -nodes -out cert.crt -keyout cert.key", en un momento solicita "Common Name (eg, YOUR name) []:"; aquí hay que ingresar el nombre del host que se utilizará para conectarse, o el IP con el que se accederá al Object Storage desde la red. Por ejemplo, en mi caso, utilicé "192.168.122.233". Al conectarnos desde Python, no parece influir el "Comon Name" elegido, pero sí influye al conectarnos desde Java.
• En vez de usar "swift-ring-builder account.builder create 18 3 1", utilicé "swift-ring-builder account.builder create 18 1 1", ya que sólo hay 1 servidor. Quizá se pueda usar 3, y de esa manera, al agregar servidores, los datos se distribuyan automáticamente...
• Al ejecutar los comandos "swift-ring-builder account.builder add ...." hay que especificar "DEVICE"... Bueno, aunque el parámetro se llama "device", esto NO se refiere a la partición! Sino al nombre del directorio donde está montada la partición donde se guardarán los datos. El servicio supone que las particiones donde se guardarán los datos están montadas en "/srv/node/DEVICE". Por ejemplo, si los datos los vamos a guardar en la partición /dev/sdb1, y montamos esa partición en "/srv/node/sdb1", entonces DEVICE = sdb1. NO hay que tomar a DEVICE como /dev/sdb1, esto es un error. Por ejemplo, en mi caso, utilice "sdb1" como DEVICE (para seguir la nomenclatura de la documentación), pero en realidad utilizo la partición "/dev/vdb1", ya que es un instancia de KVM y utilizo virtio para mapear los discos. Por lo tanto, en el fstab tengo: "/dev/vdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0".

Los fuentes del servidor (Swift) pueden bajarse de http://www.openstack.org/projects/storage/. El cliente para Python, puede bajarse de https://github.com/rackspace/python-cloudfiles. El de Java, desde https://github.com/rackspace/java-cloudfiles. Desarrollar un pequeño test en Python fue sencillo. En Java fue bastante más complicado, porque  al utilizar certificados firmados por mí mismo (al instalar el servidor genere los certificados con openssl, y por lo tanto no fueron firmados por una entidad de confianza), y por lo tanto Java generaba errores al intentar crear la conexión https a un servidor con certificados no confiables... Más información de esto en un próximo post :-)

Monitoreo de servicios "filtrados" con Icinga e iptables

Con iptables se pueden permitir conexiones a un puerto TCP (como para ser monitoreado con Icinga o Nagios) y a la vez evitar que se utilice el puerto para acceder al servicio.

# Icinga
iptables -A INPUT -s $IP_ICINGA -p tcp --dport 139 --syn -j ACCEPT
iptables -A INPUT -s $IP_ICINGA -p tcp --dport 139 -j DROP

# Mantenerlo al utlimo, para q' funque filtrado de conexiones de Icinga
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Con el ejemplo anterior, monitoreo el servicio de Samba, pero no permito que se reciba nada más que los paquetes TCP que crean la conexion. Los paquetes siguientes son eliminados.

Es importante que "ESTABLISHED,RELATED", si se utiliza, se haga al último.

Ejecutar programa en tty

Luego de investigar bastante, encontré la forma! Necesitaba ejecutar en la consola de texto un programa que monitorea el estado del servidor, pero necesitaba que esto esté funcionando desde que arranca el servidor, y sin necesidad que nadie se loguee. Esto lo logré con la ayuda de rungetty.

Por ejemplo, para que se ejecute en tty6, modifiqué "/etc/init/tty6.conf" en un Ubuntu 10.04, reemplazando la última línea:
exec /sbin/getty -8 38400 tty6
por:
exec rungetty tty6 -u root -- /usr/bin/env python /path/a/script/python.py

Para realizar pruebas, la ejecución directa de rungetty me ha dado problemas (básicamente al ejecutar rungetty no pasaba nada, ni mostraba ningún mensaje de error, aunque el exit status era 1). Esto se soluciona ejecutando rungetty con setsid:

setsid rungetty tty8 -u root -- /path/a/programa

Luego de esto, con Ctrl+Alt+F8 podremos cambiarnos a tty8 y utilizar el programa...

Deshabilitación de pad en Acer Aspire 5542

Para que funcione este botón, hace falta bootear linux con un parámetro adicional. Esto se logra modificando la configuración de grub.

1) abrir "/etc/default/grub" para editar:

acer| ~$ sudo mcedit /etc/default/grub

2) agregar "i8042.nomux" en la linea que dice "GRUB_CMDLINE_LINUX_DEFAULT", por ejemplo, en mi caso queda así:

GRUB_CMDLINE_LINUX_DEFAULT="i8042.nomux"

3) luego hay que ejecutar la herramienta de actualización de grub:

acer| ~$ sudo update-grub2

Luego de reiniciar, el botón debería funcionar...

Microfono en Acer Aspire 5542-5241

Luego de renegar bastante, parece que encontré la solución para hacer funcionar el microfono de la Acer Aspire 5542-5241 en Ubuntu Lucid.

Para esto, hay que agregar la siguiente línea en el archivo "/etc/modprobe.d/alsa-base.conf":

options snd-hda-intel position_fix=1


Lo encontré en https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/523953

OpenOffice: como embeber imagenes linkeadas

Me sucedió varias veces que luego de copiar y pegar contenidos en un documento OpenOffice recuerdo que las imágenes quedan "linkeadas" y no embebidas.

Para embeber estas imágenes linkeadas no encontré ningún macro ni forma automatizada, pero es posible hacerlo con un procedimiento bastante sencillo, seleccionando la opción "Links" en el menú "Edit". Aparecerá una ventana con todas las imágenes linkeadas, y para embeber las imágenes listadas hay que seleccionarlas y presionar el boton "Break Link" (una por una).

Encontré esta información en www.taming-openoffice-org.com

Diff de docs. OpenOffice en GIT

1) Instalar odt2txt (convierte docs. OpenOffice a texto plano)

aptitude install odt2txt

2) Configurar GIT
2.a) Agregar a .gitconfig:

[diff "odf"]
   textconv=odt2txt

2.b) Agregar a .gitattributes

*.ods diff=odf
*.odt diff=odf
*.odp diff=odf

Con estos 2 pasos realizados, git ya puede mostrar diferencias entre documentos OpenOffice (por ejemplo, al realizar modificaciones locales).

Artículo completo en http://www-verimag.imag.fr/~moy/opendocument/

Pro GIT

Hace tiempo está disponible el libro Pro GIT para ser bajado (clonando el repositorio git) o navegado.
Ya se está trabajando en la traducción al español: accedan a:

http://github.com/progit/progit/tree/master

y vean el directorio "es-ni" (por ahora es la única traducción al español, en el futuro puede haber otras).

"ip addr" en vez de alias

Luego de renegar un poco con Ubuntu 9.04 al configurar un alias de la eth0 (me usaba el IP del alias para realizar las conexiones salientes!), encontré que hay otras maneras de armar los alias, usando el comando ip.

ip addr add 192.168.5.101/24 brd + dev eth0 label "eth0:2"

Y para que se configure automáticamente, se puede agregar en /etc/network/interfaces:

post-up /sbin/ip addr add 192.168.5.101/24 brd + dev eth0 label "eth0:2" || true

Más información aquí.

Alternativa a lomount

Parece que lomount no está en Ubuntu (al menos Ubuntu 9.04 p/AMD64), pero existe un truco para montar particiones "internas" de una imagen de un disco.

Yo necesité montar la 1er partición de la imagen de un disco de un dominio virtualizado. Aunque el disco (para el dominio virtualizado) en realidad estaba provisto por un volumen lógico (LVM) todo funcionó perfectamente.

Pasos a seguir (en ingles): http://community.livejournal.com/debian/340887.html

Migrar repositorio "privado" de git a repositorio público

Necesité crear repositorios "públicos" (donde se puedan hacer pull/push desde distintas PCs) tomando los datos de repositorios locales/privados (donde realizo el desarrollo diario) y resultó ser bastante fácil:

1. Crear repositorio "publico"
a) crear un directorio - mkdir /var/git/proyecto.git
b) posicionarse en ese directorio - cd /var/git/proyecto.git
c) inicializar el directorio - git init --bare

2. Hacer push de repositorio local/privado a público
a) nos posicionamos en directorio - cd /path/a/repo/privado
b) creamos "remote" - git remote add origin ssh://pc/var/git/proyecto.git
c) configuramos repositorio - git config --bool remote.origin.mirror true
d) hacemos push - git push origin

El paso 2.c es opcional, pero a mí me resultó muy útil. Al ajustar la variable "remote.origin.mirror" a true, git subirá todos los branches y tags automáticamente cuando ejecutemos el push. Si no se realiza esta configuración, el en paso 2.d hará falta especificar los branches a subir.

Tig: text-mode interface for git

Estaba disponible al menos desde Ubuntu 8.10 pero recién lo descubro! Es una interface en modo texto para git, con varias funciones. Home. Screenshots.

#~ sudo aptitude install tig

Ubuntu 9.04 como dominio virtual usando virt-install + kvm

Se puede instalar Ubuntu 9.04 usando virt-install con un comando como el siguiente:

virt-install -d --connect qemu:///system \
-n ubuntu904virtual -r 1024 --vcpus=4  \
-f /dev/vg_virt/root \
-f /dev/vg_virt/tmp \
-f /dev/vg_virt/pv0 \
-c /tmp/ubuntu-9.04-server-amd64.iso \
--accelerate --vnc -v \
--os-type=linux --os-variant=generic26

-d para que muestre por consola información adicional mientras se crea la maquina virtual
-n es el nombre del dominio virtual
-f es para especificar discos, en este caso el dominio virtual vera 3 discos, el 1ro lo usaré para /, el segudo para /tmp y el 3ro como un "volumen fisico" para configurar LVM.
-c para especificar el path al iso

En el caso de usar LVM hay que tener cuidado porque en el servidor host se verán todos los "volume groups" y los "logical volumes" del dominio virtual. Para evitar esto se puede configurar LVM para que IGNORE totalmente ciertos "physical volumes" editando el archivo /etc/lvm/lvm.conf, y agregando:

filter = [ "r|^/dev/vg_virt/pv.*|" ]

Esto le dice a LVM que ignore cualquier "physical volume" que esté referenciado por algún dispositivo cuyo nombre comience con "/dev/vg_virt/pv". Para chequear que esto haya funcionado correctamente, ejecutamos:

pvscan -v

Los siguientes pasos a seguir podrían ser:
- instalar git y crear repo en /etc para tener historial de modificaciones
- configurar approx
- configurar serial console
- configurar virtio para discos/red
- configurar red usando bridge
- configurar autostart de dominios