Compactar particiones con zerofree

Para realizar backups de imágenes de discos usadas en QEmu/KVM se puede optimizar usar zerofree. Este programa  escribe 0 (ceros) en los lugares de la imagen que NO está siendo usada por archivos, y que han sido usadas pero actualmente están libres (por ejemplo, en el lugar donde se haya creado un archivo que luego haya sido borrado).

Zerofree funciona para ext2/ext3/ext4, en particiones que no están montadas, o montadas solo-lectura. Esta utilidad es "inteligente" en el sentido que no hace "crecer" a los archivos sparse. 


Los pasos a seguir son:

• cargar nbd

   ~$ sudo modprobe nbd max_part=16

• asociar imagen de disco disk01.qcow2 a nbd1 y crear dispositivos asociados a particiones

   ~$ sudo qemu-nbd -c /dev/nbd1 -v disk01.qcow2
   ~$ sudo partprobe /dev/nbd1

• ejecutar zerofree

   ~$ sudo zerofree -v /dev/nbd1p5

Listo! El archivo "disk01.qcow2" ocupa teóricamente 11G, pero como es un archivo sparse, en realidad está ocupado en disco sólo 1.9G:


   ~$ ls -lh disk01.qcow2
   -rw-r--r-- 1 root root 11G 2011-06-15 14:51 disk01.qcow2

   ~$ du -h disk01.qcow2 

   1.9G disk01.qcow2

El .tar ocupa sólo 918M:

   ~$ tar --sparse -cf disk01.qcow2.tar disk01.qcow2
   ~$ ls -lh disk01.qcow2.tar 
   -rw-r--r-- 1 horacio horacio 918M 2011-06-15 15:10 disk01.qcow2.tar

Y al comprimirlo solo nos queda 305M:

   $ gzip -1 disk01.qcow2.tar 
   $ ls -lh disk01.qcow2.tar.gz 
   -rw-r--r-- 1 horacio horacio 305M 2011-06-15 15:10 disk01.qcow2.tar.gz

   ~$ du -h *
   1.9G disk01.qcow2
   305M disk01.qcow2.tar.gz

En este caso, un archivo que ocupa inicialmente 1.9G lo llevamos a ocupar 918M (305M comprimido).

Cómo compilar cliente spice

Seguiendo los pasos para instalar Spice (un nuevo protocolo para comunicarse con guests KVM/QEMU/etc.) me surgieron unos errores, no muy complicados de resolver.

En general, segui las instrucciones de http://spice-space.org/page/Building_Instructions.
La instalación la hice en /usr/local/slice, asi que reemplace "INST_ROOT" por "/usr/local/slice".

Para compilar e instalar el cliente, en un momento hay que ejecutar:

~$ cd $SRC_ROOT/spice

~$ ./autogen.sh --prefix=$INST_ROOT

Pero este ultimo comando me generó un error:

----------------------------------------
(...)
checking for PROTOCOL... no
configure: error: Package requirements (spice-protocol >= 0.6.0) were not met:
No package 'spice-protocol' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables PROTOCOL_CFLAGS
and PROTOCOL_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
----------------------------------------

Esto se solucione usando:

~$ export PKG_CONFIG_PATH="/usr/local/spice/share/pkgconfig:/usr/local/spice/lib/pkgconfig"

~$ ./autogen.sh --prefix=/usr/local/spice

~$ cd client

~$ make install

Y... no funcionó...

----------------------------------------

make[1]: *** No rule to make target `../common/libspice-common.la', needed by `spicec'. Stop.
make[1]: Leaving directory `/mnt/sin_encriptar/src/spice-client-src/spice/client'
make: *** [install] Error 2

----------------------------------------

Pero, compilando manualmente lo del directorio "common", luego lo de "cliente" funciona:

~$ cd ..

~$ cd common

~$ make install

~$ cd ..

~$ cd client

~$ make install

Y ahora sí!

Eliminando *.pyc del repositorio Git

Por un error subí archivos pyc al repositorio Git. Ya que no me hace falta mantener esos archivos en el repositorio, decidí intentar eliminarlos del historial, usando "git filter-branch". Resultó ser bastante fácil!

$ git filter-branch --tag-name-filter cat \
--index-filter 'git rm -r --cached --ignore-unmatch *.pyc' HEAD

Esto no es peligroso para repositorios "personales", pero SI para repositorios compartidos, ya que este comando reescribe todo el historial. También hay que tener cuidado si se están utilizando varios branches, ya que este comando solo trabaja en 1 branch a la vez.

La documentación del comando puede verse aqui.

Probando LM335 con PyArduinoProxy

Subi unos screenshots, mostrando cómo usé la interfaz web de PyArduinoProxy para testear unos LM335.

https://github.com/hgdeoro/py-arduino-proxy/wiki/Example%3A-Testing-LM335

Chau Skype!

La compañía Skype fue comprada, asi que ya es hora de buscar alternativas!

• Jitsi - http://www.jitsi.org (audio/video)
• Blink - http://icanblink.com (Linux/Max/Win, audio, envío de archivos, compartir escritorios, conferencia múltiple)
• Ekiga - http://www.ekiga.org (Linux/Win, audio/video)
• GoogleTalk - http://www.google.com/talk/ (Linux/Mac/Win/Web) permite hacer llamadas a numero fijos!
• Empathy - http://live.gnome.org/Empathy (audio/video)
• LinPhone - http://www.linphone.org/ (Linux/Win/Mobile)
• QuteCom - http://trac.qutecom.org/ (Linux/Win)
• Twinkle - http://www.twinklephone.com/ (Linux)

Flyback diode

Son diodos utilizados para eliminar repentinos picos de voltaje. Estos picos se producen en circuitos altamente inductivos, cuando el voltaje en dicho circuito baja o es eliminado.

La teoría de circuitos demuestra que cuando la corriente que pasa por un inductor se detiene, aparece una tensión a tavés de dicho inductor, en sentido contrario de la corriente que se detuvo. Esta corriente es llamada "flayback". Esa corriente no "aparece de la nada": es originada en la energía almacenada en el campo magnético del inductor, o sea, el campo magnético creado por la corriente inicial, libera su energía como electricidad (pero en sentido opuesto a la corriente inicial).

Tomada de WikiPedia: http://en.wikipedia.org/wiki/File:Flyback_Diode.svg

Esto lo traducí (con ayuda de Google) de http://digital.ni.com/public.nsf/allkb/336D3653F6B6387386256F36005BE09F

Hay más información (en inglés) en: http://en.wikipedia.org/wiki/Flyback_diode

Capacitores para suprimir ruido eléctrico

Encontré que es aconsejable utilizar capacitores en los circuitos, para suprimir cualquier "ruido" que pueda generarse, sobre todo si se usan motores (me imagino que también debe ser importante si se usan reles, por ejemplo).

http://www.seattlerobotics.org/encoder/jun97/basics.html

En inglés: Bypass capacitors help filter the electrical noise out of your circuits. They do this by removing the alternating currents caused by ripple voltage. Most digital circuits have at least a couple of bypass capacitors. A good rule of thumb is to add one bypass capacitor for every integrated circuit on your board. A good default value for a bypass cap is 0.1uF. Higher frequencies require lower valued capacitors.

Traducido por Google: Los condensadores de desacoplo ayudan a filtrar el ruido eléctrico de los circuitos. Lo hacen mediante la eliminación de las corrientes alternas causada por variaciones de la tensión. La mayoría de los circuitos digitales tienen por lo menos un par de condensadores de desacoplo. Una buena regla es agregar un condensador de desacoplo por cada circuito integrado en la placa. Un buen valor por defecto es 0.1uF. Las frecuencias más altas requieren capacitores de menor valor .

 Otras páginas interesantes que encontré sobre el tema:

• http://forum.allaboutcircuits.com/showthread.php?t=24095#2
• http://www.ami.ac.uk/courses/topics/0191_elp/index.html

Py-Arduino-Proxy + LCD

Ya estoy buscando la forma de utilizar LCDs desde Py-Arduino-Proxy :-D En este caso, muestro la temperatura (con un LM35)

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