Dentro del mundo de la Virtualización, al momento de consolidar máquinas [1] lo más sencillo (o lo que primero se le puede ocurrir a uno [2]) es hacer una imagen bit a bit del disco donde éste se aloja a un archivo del Host, mediante alguna herramienta como dd en Linux:

$ dd if=/dev/sdb of=/vms/images/imagen.raw

Este mecanismo es generalmente infalible; luego de ésto, uno crea un perfil de una Máquina Virtual (típicamente un archivo XML donde se describen las características del Guest), se lo relaciona a esta imagen “cruda” de la ex-Máquina Física, y en un minutos la misma está corriendo como Máquina Virtual sin problemas.

Además, es más común utilizar un formato de imágenes más flexible que el Raw (“crudo”), que soporte características como:

• Almacenamiento/Crecimiento dinámico.
• Copy-On-Write (en este caso se trata de la posibilidad de tener una imagen “base” en modo sólo lectura y guardar las diferencias en otra imagen).
• Gestionar snapshots del disco de cualquier momento dado.
• Compresión al vuelo.
• Encriptación.
• etc.

Es aquí donde cada solución de virtualización tiene su propio formato para obtener todas o algunas de estas ventajas, según el caso:

• VirtualBox tiene al formato VDI,
• VMWare tiene el VMDK,
• KVM+QEmu tiene el QCow2,
• etc.

El manejo del almacenamiento en forma dinámica de éstos nos permite que al momento de crear una imagen de un disco de por ejemplo, 80 GB, la imagen ocupe físicamente unos pocos cientos de bytes; a medida que se van guardando archivos en el disco de la VM, éstos son almacenados finalmente en el archivo de imagen, hasta llegar al tope estipulado al momento de crear la imagen de disco (los 80 GB, por ejemplo).

Pero volvamos al caso de la generación de una imagen de un disco físico de un equipo, ¿qué pasa si éste era de 160 GB y sólo tenía 20 GB de información guardada en uso efectivo? El archivo .raw es una copia bit a bit del disco de punta a punta, por lo tanto, su imagen Raw (“cruda”) en el Host ocupará 160 GB. Es decir, este mecanismo no discrimina el espacio ocupado por los archivos de datos del no utilizado y/o de archivos eliminados.

Bueno entonces, ¿para qué tenemos los formatos de imágenes nativos del hypervisor (KVM+QEmu en nuestro caso) que mencionamos anteriormente? ¿Es posible convertir una imagen Raw en una QCow2, para que su imagen ocupe los 20 GB de datos en vez de 160 GB? Sí es posible la conversión; para todas las operaciones con imágenes de disco KVM+QEmu tiene la herramienta qemu-img:

$ qemu-img convert -f raw imagen.raw -O qcow2 imagen.qcow2

Con ese comando convertimos el archivo Raw al formato QCow2, buscando que la imagen a utilizar sea más pequeña , pero en su lugar la mejora de espacio es mucho menor a la esperada (aún si se llegara a dar). Es aquí donde nos encontraremos con un problema: ¡qemu-img no sabe distinguir entre los archivos de datos y el espacio no utilizado/eliminado! Si la máquina física estuvo en uso por algún tiempo, es probable que no lleguemos ni cerca al archivo “ideal” de 20 GB. Si momentáneamente tuve en ese disco de esa máquina física 60 GB extras de música y fotos familiares, seguramente el archivo QCow2 convertido desde Raw no va a bajar de los 80GB, por ejemplo.

¿Y esto porqué sucede? La teoría dice que:

• Todo aquel espacio de disco, que viene de fábrica digamos, está compuesto de bytes en cero (0×00).
• Todo aquel espacio de disco que es utilizado primero y luego borrado del disco, no es eliminado físicamente, es decir, no vuelve a cero, sino que queda con el contenido previo. El sistema de archivos en la enorme mayoría de los casos, para ganar velocidad (y mucha) al hacerlo, sólo quita la referencia en el índice del Sistema de Archivos al conjunto de clusters del disco que tiene el contenido real del archivo. Es por eso que uno “no ve” al archivo recientemente eliminado porque el índice de archivos existentes no lo tiene más, pero físicamente el archivo sigue estando.
• QEmu-img reconoce como espacio vacío los bytes en cero.

Sin embargo, tenemos opciones para hacer lo que queremos y no quedarnos sin espacio en el Host rápidamente, nada más que en KVM+QEmu hay que hacerlo un poco más a mano; este proceso se llama en inglés “Image Shrinking“ (“achicar”, “reducir”, “contraer” la imagen). [3][4]

Achicando (“Shrinkeando”) imágenes de discos virtuales

Según “la teoría” y los links que se han citado , para poder recuperar espacio ocupado del disco hay que ponerlo en cero; ¿Y cómo se hace? Fácil, creando un archivo tan grande como el espacio remanente del disco lleno de ceros.

Armando el Caso de Prueba

Vamos a tratar de reproducir el problema y solucionarlo en forma representativa con una imagen Raw de 10 MB, como para que cualquiera pueda seguir estos pasos y entender de qué se trata todo esto.

1) Creamos una imagen Raw de prueba con 10 MB de bytes aleatorios:

marcelo@marcelo-laptop:~$ dd if=/dev/urandom of=test.raw bs=1024 count=10000
10000+0 registros de entrada
10000+0 registros de salida
10240000 bytes (10 MB) copiados, 2,24907 s, 4,6 MB/s
marcelo@marcelo-laptop:~$

2) Ya que todo disco tiene una tabla de particiones, se la creamos con parted:

marcelo@marcelo-laptop:~$ parted test.raw print
AVISO: Usted no es el superusuario. Compruebe los permisos.
Error: /home/marcelo/test.raw: etiqueta de disco no reconocida
marcelo@marcelo-laptop:~$ parted test.raw mktable msdos
AVISO: Usted no es el superusuario. Compruebe los permisos.
marcelo@marcelo-laptop:~$ parted test.raw print
AVISO: Usted no es el superusuario. Compruebe los permisos.
Modelo:  (file)
Disco /home/marcelo/test.raw: 10,2MB
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio  Fin  Tamaño  Tipo  Sistema de ficheros  Banderas
 
marcelo@marcelo-laptop:~$

El “parted test.raw print” muestra la tabla de particiones, y el “parted test.raw mktable msdos” crea una tabla de particiones de tipo MSDOS (hay otros tipos, como por ejemplo GUID). Primero vemos que el print da un error, luego creamos la tabla y por último vemos la tabla de particiones sin particiones definidas.

3) Ahora hay que crear una partición en esa tabla, nuevamente con parted:

marcelo@marcelo-laptop:~$ parted test.raw mkpart primary 0 10
AVISO: Usted no es el superusuario. Compruebe los permisos.
Aviso: La partición resultante no está debidamente alineada para el mejor rendimiento.
Descartar/Ignore/Cancelar/Cancel? Ignore
marcelo@marcelo-laptop:~$ parted test.raw print
AVISO: Usted no es el superusuario. Compruebe los permisos.
Modelo:  (file)
Disco /home/marcelo/test.raw: 10,2MB
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio  Fin     Tamaño  Tipo     Sistema de ficheros  Banderas
 1      512B    10,2MB  10,2MB  primary
 
marcelo@marcelo-laptop:~$

4) Ahora le damos formato a la partición en la imagen, por ejemplo, NTFS. El parámetro “–fast” es para que no llene de ceros la partición al momento de crearla (sólo para que siga con datos aleatorios) y el “–force” es para que se haga la operación a pesar de que el archivo no es un disco “de verdad”.

marcelo@marcelo-laptop:~$ mkfs.ntfs --fast --force test.raw
test.raw is not a block device.
mkntfs forced anyway.
The sector size was not specified for test.raw and it could not be obtained automatically.  It has been set to 512 bytes.
The partition start sector was not specified for test.raw and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for test.raw and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for test.raw and it could not be obtained automatically.  It has been set to 0.
Cluster size has been automatically set to 4096 bytes.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
Creating NTFS volume structures.
mkntfs completed successfully. Have a nice day.
marcelo@marcelo-laptop:~$ parted test.raw print
AVISO: Usted no es el superusuario. Compruebe los permisos.
Modelo:  (file)
Disco /home/marcelo/test.raw: 10,2MB
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. loop
 
Numero  Inicio  Fin     Tamaño  Sistema de ficheros  Banderas
 1      0,00B   10,2MB  10,2MB  ntfs
 
marcelo@marcelo-laptop:~$

6) Perfecto, ya tenemos nuestro “mini disco” NTFS para jugar. Ahora vamos a montarlo y ver qué tiene:

marcelo@marcelo-laptop:~$ sudo mount -o loop test.raw /mnt
[sudo] password for marcelo:
marcelo@marcelo-laptop:~$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
[...]
/dev/loop0 on /mnt type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
marcelo@marcelo-laptop:~$ tail /var/log/syslog
[...]
Aug 14 02:28:57 marcelo-laptop ntfs-3g[19770]: Version 2010.3.6 external FUSE 28
Aug 14 02:28:57 marcelo-laptop ntfs-3g[19770]: Mounted /dev/loop0 (Read-Write, label "", NTFS 3.1)
Aug 14 02:28:57 marcelo-laptop ntfs-3g[19770]: Cmdline options: rw
Aug 14 02:28:57 marcelo-laptop ntfs-3g[19770]: Mount options: rw,silent,allow_other,nonempty,relatime,fsname=/dev/loop0,blkdev,blksize=4096
Aug 14 02:28:57 marcelo-laptop ntfs-3g[19770]: Ownership and permissions disabled, configuration type 1
marcelo@marcelo-laptop:~$  ls -l /mnt
total 0
marcelo@marcelo-laptop:~$

7) Ahora estamos como si hubiéramos hecho el dd de un disco físico en nuestro Host con KVM+QEmu. Como se ha visto, la imagen no tiene nada en el sistema de archivos pero físicamente está lleno de bytes aleatorios y ocupa 10 MB, el tamaño completo. ¿Qué pasa si lo convertimos a QCow2? ¿Se cumple “la teoría”?

marcelo@marcelo-laptop:~$ sudo umount /mnt
marcelo@marcelo-laptop:~$ qemu-img convert -f raw test.raw -O qcow2 test.qcow2
marcelo@marcelo-laptop:~$ ls -l
[...]
-rw-r--r--  1 marcelo marcelo 10420224 2010-08-14 02:37 test.qcow2
-rw-r--r--  1 marcelo marcelo 10240000 2010-08-14 02:28 test.raw
[...]
marcelo@marcelo-laptop:~$ qemu-img info test.raw
image: test.raw
file format: raw
virtual size: 9.8M (10240000 bytes)
disk size: 9.8M
marcelo@marcelo-laptop:~$ qemu-img info test.qcow2
image: test.qcow2
file format: qcow2
virtual size: 9.8M (10240000 bytes)
disk size: 9.8M
cluster_size: 65536
marcelo@marcelo-laptop:~$

Sí, se cumple… es más, la imagen QCow2 ocupa más espacio que la Raw (por ahora). Hemos podido reproducir el problema.

Llenando de Ceros el espacio vacío – Wiper.py

Bien, ahora se me ocurrió armar un script en Python para que me ayude a automatizar el proceso de crear un archivo con ceros hasta que me quede sin espacio para luego borrarlo. Lo llamé “wiper.py”. El código fuente es el siguiente:

#!/usr/bin/env python
# coding: utf-8
 
# Wiper
# Copyleft 2010 - Licencia BSD
# Autor: Marcelo Fernández.
# Email: marcelo.fidel.fernandez@gmail.com
 
# This script creates a file which fills the available disk with zero bytes,
# and when the disk is full, the file is deleted.
# This allow to convert a raw partition to qcow2 'shrinking' the real image
 
import sys, os, errno
 
FILENAME = 'wiper.000'
STEP_SIZE = 4096
 
if __name__ == '__main__':
    if len(sys.argv) != 2:
        print 'usage: python wiper.py path_mounted_image'
        sys.exit(1)
    fat_file_path = os.path.join(sys.argv[1], FILENAME)
    try:
        fat_file = open(fat_file_path, 'wb', STEP_SIZE)
    except Exception, e:
        print 'There was an error opening the file in %s: %s' % (fat_file_path, str(e))
        sys.exit(2)
    print 'Temp file %s open for writing. Filling disk...' % fat_file_path
    try:
        while True:
            fat_file.write('\x00' * STEP_SIZE)
    except EnvironmentError, env_error:
        if env_error.errno == errno.ENOSPC:
            print 'No space left on device, good! Deleting temp file...'
        else:
            # There was another error different from 'No space available',
            # anyway we'll alway try to delete the fat_file
            print 'Abnormal error: ', oserror
    except Exception, e:
        # Rarely, but this could happend too
        print 'Exception: ' + repr(e)
    fat_file.close()
    try:
        os.unlink(fat_file_path)
    except Exception, e:
        print 'There was a problem deleting the temp file.'
    else:
        print 'Temp file erased ok.'

Básicamente hace lo necesario, el STEP_SIZE es importante para que la operación sea bastante más rápida que escribiendo de a un byte. Vamos a ejecutar el script y convertir nuevamente el archivo Raw a QCow2 con qemu-img a ver qué sucede:

marcelo@marcelo-laptop:~$ sudo mount -o loop test.raw /mnt
marcelo@marcelo-laptop:~$ python wiper.py /mnt/
Temp file /mnt/wiper.000 open for writing. Filling disk...
No space left on device, good! Deleting temp file...
Temp file erased ok.
marcelo@marcelo-laptop:~$ ls -l /mnt
total 0
marcelo@marcelo-laptop:~$ sudo umount /mnt
marcelo@marcelo-laptop:~$ qemu-img convert -f raw test.raw -O qcow2 test_shrinked.qcow2
marcelo@marcelo-laptop:~$ ls -l
[...]
-rw-r--r--  1 marcelo marcelo 10420224 2010-08-14 02:42 test.qcow2
-rw-r--r--  1 marcelo marcelo 10240000 2010-08-14 02:58 test.raw
-rw-r--r--  1 marcelo marcelo  3014656 2010-08-14 02:58 test_shrinked.qcow2
marcelo@marcelo-laptop:~$ sudo mount -o loop test.raw /mnt
marcelo@marcelo-laptop:~$ df -h
S.ficheros            Tamaño Usado  Disp Uso% Montado en
/dev/sda1              16G  6,7G  7,7G  47% /
[...]
/home/marcelo/test.raw
                      9,8M  2,5M  7,3M  26% /mnt
marcelo@marcelo-laptop:~$

Bueno, ahora sí, el archivo QCow2 ocupa un cuarto del archivo Raw (2,5 MB). ¿En qué se gastan estos 2.5MB? Seguramente en los índices del sistema de archivos para poder gestionar el espacio libre. Es altamente probable que más que este espacio recuperado no podamos ganar, ya que si tocamos estos índices, corrompemos el sistema de archivos; recordemos que en test.raw puede haber un Sistema Operativo completo con todos sus archivos de datos.

De todas maneras, esto puede variar según el sistema de archivos de la imagen (NTFS en este caso) y los parámetros con los cuales se está manejando el mismo (el tamaño de bloque y de cluster incide mucho en el espacio que ocupan los índices de los Sistemas de Archivos en general).

Conclusiones

Es bueno saber que también se puede usar el comando dd para crear un archivo lleno de ceros en la partición ntfs de pruebas montada, con el comando “dd if=/dev/zero of=/mnt/borrame.000″ y después borrar el archivo en cuestión, pero puede hacerse interminable el “llenado” si no pasamos como parámetro un block size relativamente grande, como de 4096 bytes:

marcelo@marcelo-laptop:~$ time dd if=/dev/zero of=/mnt/borrame.000 bs=4096
dd: escribiendo «/mnt/borrame.000»: No hay espacio libre en el dispositivo
1863+0 registros de entrada
1862+0 registros de salida
7626752 bytes (7,6 MB) copiados, 0,144428 s, 52,8 MB/s
 
real	0m0.149s
user	0m0.000s
sys	0m0.030s
marcelo@marcelo-laptop:~$

Prueben a pasarle bs=1, a ver cuánto tarda…. (lo pueden cortar con Ctrl+C).

Una cuestión más que queda dando vueltas es que esta situación de espacio desperdiciado por la imagen se da también luego de un tiempo de usar la Máquina Virtual, si se da el caso de que se libere espacio en forma masiva; como caso, el ejemplo de un disco de 80 GB con 20 GB dedicados al Sistema Operativo más 60 GB de fotos y música eliminados recientemente.  Aquí también será útil correr wiper.py en la imagen montada y volver a ejecutar “qemu-img convert” para shrinkear la imagen.

En fin, espero que este post le sea de utilidad a aquellos que trabajamos con tan formidable hypervisor como lo es KVM y su gestor de I/O como lo es QEmu.

Saludos

[1] Si bien a un Linux se lo puede consolidar más fácilmente, sólo copiando todos los archivos con rsync, o “cp -a”, con Windows este método no funciona, y hay que copiar el disco o al menos la partición completa. La idea al usar dd es abstraerse del SO.
[2] En vez de dd se puede usar una herramienta de clonación de discos/particiones que “entienda” o “interprete” el filesystem, como Partimage para intentar generar directamente una imagen Raw con el espacio no utilizado en cero; pero nunca lo probé, ni me parece un método muy “limpio”, ya que estamos insertando un software algo complejo en el medio de algo que de cualquier otra manera es conceptualmente simple y repetible. En el único caso que lo probaría es si estoy falto de espacio de disco en el Host. Si alguien lo prueba, me avisa.
[3] Creo que “comprimir” no es la palabra apropiada porque da la idea al lector de que hay un proceso (que implementa un algoritmo) de compresión de datos sin pérdida, como por ejemplo, LZ. Sin embargo, aquí lo que se necesita es recuperar el espacio no utilizado de la imagen, para obtener un tamaño de imagen menor.
[4] Como nota al margen, VMWare tiene en sus VMWare Tools una opción para hacer “Shrink” de la imagen, pero ¿cómo se divierte un Sysadmin con ganas de aprender si sólo tiene que hacer click en un botón que diga “Shrink Image”?

Supongamos que tengo un equipo donde usualmente estoy trabajando y otro equipo que está siempre encendido, ambos separados por Internet. En este último, el único puerto abierto sobre una IP Pública es el 22 para usar SSH, con lo cual me viene perfecta la capacidad de rsync de sincronizar carpetas y los últimos cambios mientras estoy trabajando, todo mediante un canal seguro.

El Script de sincronización

Lo único que necesito es este script en la carpeta personal de mi equipo “cliente”, o sea, donde hago mis quehaceres diarios:

#!/bin/bash
# Script para sincronización a Servidor vía Casero rsync/ssh.
#
# Copyleft 2010 - Licencia BSD
# Autor: Marcelo Fernández.
# Email: marcelo.fidel.fernandez@gmail.com
#
# Características:
#  - Guarda la salida en un archivo de log (~/sync.log).
#  - Sincronización de una vía; pisa las modificaciones (y elimina) en el destino.
#  - Envía notificaciones al escritorio del usuario.
#  - Se sugiere ser llamado desde cron (gnome-schedule para el usuario final).
#  - Sincroniza (una sola vía) el directorio Documentos de mi Carpeta Personal y el Escritorio,
#    se pueden agregar más carpetas a gusto al momento de ejecutar el comando rsync.
#    También debe personalizarse el destino del backup, ahora en /media/Disco1/Backup
#
# Requerimientos:
#  - Rsync
#  - Paquete libnotify-bin (Debian/Ubuntu), que brinda el comando notify-send.
#
# Parámetros:
#  - Host destino. El script se lo llama "./sync.sh mi_host".
#    El login debe ser vía public keys, y la passphrase la maneja Gnome.
 
HOST=$1
LOG_FILE="sync.log"
export DISPLAY=:0.0 # Para el notify
export SSH_AUTH_SOCK="$(find /tmp/keyring*/ -perm 0755 -type s -user $LOGNAME -group $LOGNAME -name '*ssh' | head -n 1)"
 
notify-send -u normal --icon=gtk-refresh --category=transfer "Sincronizando a Casa..."
echo `date` >> $LOG_FILE
rsync -avz -e 'ssh' --delete ~/Documentos ~/Escritorio $HOST:/media/Disco1/Backup/ &>> $LOG_FILE
RETVAL=$?
if [ $RETVAL -ne 0 ]; then
    notify-send -u critical --icon=gtk-dialog-error --category=transfer.error  "Error al Sincronizar";
else
    notify-send -u normal --icon=gtk-apply --category=transfer.complete "Sincronización Completa";
fi

Programando su ejecución automática

Este script está pensado y preparado para ser llamado desde la aplicación “Tareas Programadas” de Gnome (disponible en el Centro de Software de Ubuntu o se instala haciendo click aquí):

Este es el detalle de la configuración de la tarea:

Y además nos avisa de que está trabajando y si tuvo éxito o no al sincronizar:

Algunas cuestiones para destacar

Como se aclara en los comentarios, cada vez que rsync copia las modificaciones al servidor, “pisa” lo que había anteriormente, lo que comúnmente se denomina sincronización de archivos “de una vía“.

Lo más interesante es que a pesar de ser ejecutado desde Cron, aprovecha las llaves SSH desbloqueadas por Gnome en la sesión de escritorio del usuario, es decir que la primera sincronización, si previamente no me había conectado al equipo remoto, me pide la frase de paso para desbloquear la clave privada; a partir de ese momento ésta queda compartida, gracias al ssh-agent que utiliza Gnome en background. Luego, mientras siga la sesión de escritorio establecida, va a aprovechar la llave desbloqueada por el usuario y hacer la sincronización sin mayor problema. Esto es mucho mejor en cuanto a seguridad que usar una clave privada sin frase de paso contra el servidor, y me permite desbloquearla sólo la primera vez y no cada vez que se hace la sincronización, siendo un perfecto balance (al menos para mí) entre seguridad, automatización y comodidad. Lógicamente esto sirve para utilizar en cualquier conexión SSH que se quiera establecer, y la solución, después de dar muchas vueltas y probar muchas alternativas (¡el ssh del cron no “veía” al agente!), la encontré en este post.

Conclusión

Este script fue creciendo desde algo muy simple, totalmente manual y que ejecutaba “cada vez que me acordaba” a mejorarlo un poco en cuanto a la automatización y hacerlo más “lindo” como está hoy. Si bien hay muchísimos mecanismos más robustos o con más facilidades (usando los snapshots de rsync por ejemplo y/o sincronizando ida y vuelta), éste es el que funciona para mí. Es bien claro lo que hace y no hay ninguna “magia” en el medio; trabaja sin que me moleste en mi actividad diaria y me despreocupo totalmente de que tenía que hacer backup.

Espero que les sirva como a mí. Acá hay mucha más información sobre rsync y una explicación más profunda de las diferentes opciones y alternativas, que por supuesto se pueden utilizar con esto como base.

¡Saludos!

En Ubuntu 10.04 funciona sin instalar nada adicional, pero los principales problemas son que funciona sólo a 11Mbps y que aleatoriamente se desconecta, sin causa aparente, y el Network Manager vuelve a reconectarse. El problema es más serio cuando Network Manager se cansa de revivir a la placa, y el equipo se queda desconectado definitivamente. Y más si no estoy cerca para reconectarla a mano.

Luego de probar unas cuantas recetas (y de esquivar Ndiswrapper porque es un equipo de 64 bits), decidí que voy a dejarlo así, y me hice un scriptcito de cron para reiniciar Network Manager si la interfaz está caída:

#!/bin/bash
 
# /usr/bin/network_respawn
# Network respawn -- rtl8187b dies randomly and despite Network-Manager usually
# reconnects again, sometimes it gives up and dies without connection.
 
# If wlan0 is not connected, it restarts Network-Manager
# This script is meant to be called from a cron job. 
 
IFACE="wlan0"
 
CONNECTED=`grep $IFACE /var/run/network/ifstate`
if [ "$CONNECTED" == "" ]; then  # Disconnected. Respawning...
    /usr/bin/service network-manager restart
fi

Además, hay que crear el archivo en /etc/cron.d/network_respawn para que el sistema llame al script anterior, cada 3 minutos en mi caso:

# Network respawn -- rtl8187b dies randomly and despite Network-Manager usually
# reconnects again, sometimes it gives up and dies without connection.
# If wlan0 is not connected, it restarts Network-Manager
 
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
*/3 * * * * root /usr/bin/network_respawn

Es un script sencillo, y puede ser utilizado para cualquier propósito como el mío. Lo malo es que reinicia todas las conexiones del equipo, ya que reinicia el Network Manager .

¿A alguien se le ocurre cómo hacerlo mejor?

Saludos

Claro, PyFpdf es un port más o menos “haragán” (lazy) de Fpdf para PHP, y el autor original evidentemente encontró más sencillo definir algunas fuentes (en binario) haciendo sucesivas llamadas a la función chr(), como  esta:

fpdf_charwidths['times']={chr(0):250, chr(1):250, chr(2):250, chr(3):250,} # Sigue...

Enseguida pensé en mejorarlo, reemplazando esas sucesivas llamadas a chr() por la misma función pero ya evaluada y en forma de byte string; por ejemplo, la idea era convertir lo anterior en:

fpdf_charwidths['times']={'\x00':250,'\x01':250,'\x02':250,'\x03':250,} # Sigue...

De esa manera, los archivos .py se simplificarían (se harían más legibles), no sufrirían modificaciones en su comportamiento y hasta serían más veloces en su interpretación y ejecución.

Primero se me ocurrió primero hacer algo más “a mano”, pero en cuanto se me complicó un poquito enseguida pensé que la mejor herramienta era usar expresiones regulares para el matching del patrón “chr(x)” y, por consiguiente, el módulo re de la librería estándar de Python.

Leyendo esta excelente página y la documentación del módulo en cuestión, armé un script, y me quedó así:

#!/usr/bin/python
# coding:utf-8
 
# This script tries to identify all chr(XX) constant calls in python scripts
# and replace them with '\xXX' strings.
# Author: Marcelo Fernández - License: MIT
 
import sys
import re
 
def chrrepl(match):
    # See http://www.amk.ca/python/howto/regex/regex.html
    # Use the captured group to get the hex string value.
    char_number = match.group(1)
    return repr(chr(int(char_number)))
 
if __name__ == '__main__':
    if len(sys.argv) != 3:
        print 'Usage: python chr_cleaner.py infile.py outfile.py'
        sys.exit(1)
 
    infile = sys.argv[1]
    outfile = sys.argv[2]
    # Open file for reading
    try:
        fin = open(infile, 'r')
        fout = open(outfile, 'w')
    except IOError:
        print 'Error when reading %s or trying to write %s' % (infile, outfile)
        sys.exit(2)
 
    intext = fin.read()
    pattern = 'chr\\((\\d+)\\)' # Group the chr() function parameter to capture it
    p = re.compile(pattern)
    outtext = p.sub(chrrepl, intext)
    fout.write(outtext)
    fout.flush()
 
    fin.close()
    fout.close()

Si bien creo que el snippet es bastante legible, lo interesante es que con el módulo re se puede:

• Identificar un patrón en un texto: En este caso el patrón sería “chr(\d)” (\d porque busco un número allí).
• Marcar grupos en ese patrón utilizarlos luego; como sé que voy a utilizar el número en cuestión para convertirlo a su byte string, lo defino dentro de un grupo. El patrón queda entonces “chr((\d))”. También es posible usar named groups, identificables por nombre en vez de por posición, pero eso lo dejo de tarea al lector
• Reemplazar todo el texto que coincide con ese patrón, y en cada reemplazo, llamar a una función que especifique “lo que hay que poner” allí, devolviendo un string. Esta es la frutilla del postre…
  Si bien puedo usar p.sub() para reemplazar lo que busco por un texto constante, también puedo hacer que en cada ocurrencia del patrón una función cualquiera sea llamada, y  se le pase la instancia de MatchObject para que decidamos qué hacer con lo encontrado y devolver un string. Esto hace la función chrrepl() del snippet. Allí tomo el primer grupo (el grupo 0 es el string completo, el 1 es el primer grupo definido posicionalmente, y así sucesivamente), lo convierto a entero, ejecuto la función chr() y devuelvo su representación en byte string.

En fin, después de experimentar un buen rato, esto funcionó y acá se puede ver el diff del commit correspondiente para que se aprecie un poco mejor…

Saludos

Bitsense empresa dedicada a la implementación de soluciones telefónicas, dará comienzo a su 3er curso de capacitación de Telefonía IP denominado Biac (Bitsense Initial Asterisk Course), el mismo es el primer curso en la Argentina dictado por dos instructores certificados dCAP (Digium-certified Asterisk Professional) junto con el apoyo de certificados Cisco y Juniper.

Para solicitar mas informacion envienos un mail a capacitacion@bitsense.com.ar y un representante se comunicará con usted o llamenos al telefono al 5353.9858 (int 105).

Saludos

Resulta que yo tengo una Impresora Multifunción Samsung SCX-4200, que tiene unos drivers (cerrados) para Linux [1]. Estos drivers sirven para imprimir y escanear, y si bien hoy en día Ubuntu se las arregla bárbaro para imprimir con los drivers libres de SpliX (¡instalación y configuración automágica!), queda pendiente aún el tema del escaneo.

Por algún motivo al utilizar el scanner (vía USB) la transferencia se caía, y resultó ser que la comunicación Scanner <-> USB 2.0 no funciona, como ya documenté en este mismo blog hace unos años (con la impresión no hay problemas); y no importa la mother, chip o cosa que haya en el medio (lo probé con diferentes equipos). O es esta printer en particular (mucha mala suerte), o es algo del firmware que me tocó en gracia, o… shit happens.

En fin, en versiones anteriores de Ubuntu anteriores a 9.10, para forzar una comunicación USB 1.1 se solucionaba con un “sudo rmmod ehci_hcd”, porque el módulo USB 2.0 (ehci_hcd) era justamente, un módulo que se cargaba dinámicamente. Pero a partir de Ubuntu 9.10 (¿o antes?) este módulo fue incluido en el kernel (estáticamente), con lo cual a priori no tenía manera sencilla de forzar una comunicación USB 1.1 con algún dispositivo (que no sea cambiar el parámetro correspondiente en el BIOS), ya que no es posible descargar un módulo estático del kernel (más info acá).

Me puse a buscar, y encontré una solución. Para simular la “descarga” el módulo es necesario posicionarse en el directorio /sys/bus/pci/drivers/ehci_hcd y pasarle al archivo “unbind” qué hub USB “unbindear” (¿”desrelacionar”?); los hubs USB se pueden ver con un lsusb -v, y los que van a aparecer en el directorio mencionado son los de “Full Speed”, o sea, los de USB 2.0 [2] .

Si tu PC soporta USB 2.0 (y por ende tenés este problema, je), al menos uno hay, que corresponde al Hub de la motherboard. En mi caso hay dos, pero para no andar especulando (y porque quiero que el scanner funcione sin averiguar a cuál de los dos hub está conectado en particular), “unbindeo”/”desrelaciono”/”desenlazo” (?) ambos hubs:

marcelo@marcelo-laptop:~$ sudo -i
[sudo] password for marcelo:
root@marcelo-laptop:~# cd /sys/bus/pci/drivers/ehci_hcd/
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# ls -l
total 0
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 0000:00:1a.7 -> ../../../../devices/pci0000:00/0000:00:1a.7
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 0000:00:1d.7 -> ../../../../devices/pci0000:00/0000:00:1d.7
--w------- 1 root root 4096 2010-03-19 14:12 bind
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 module -> ../../../../module/ehci_hcd
--w------- 1 root root 4096 2010-03-19 14:12 new_id
--w------- 1 root root 4096 2010-03-19 14:12 remove_id
--w------- 1 root root 4096 2010-03-19 14:12 uevent
--w------- 1 root root 4096 2010-03-19 14:12 unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# echo -n 0000\:00\:1a.7 > unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# echo -n 0000\:00\:1d.7 > unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd# ls -l
total 0
--w------- 1 root root 4096 2010-03-19 14:12 bind
lrwxrwxrwx 1 root root    0 2010-03-19 14:12 module -> ../../../../module/ehci_hcd
--w------- 1 root root 4096 2010-03-19 14:12 new_id
--w------- 1 root root 4096 2010-03-19 14:12 remove_id
--w------- 1 root root 4096 2010-03-19 14:12 uevent
--w------- 1 root root 4096 2010-03-19 14:21 unbind
root@marcelo-laptop:/sys/bus/pci/drivers/ehci_hcd#

[...]
[64720.180444] ehci_hcd 0000:00:1a.7: remove, state 4
[64720.180464] usb usb1: USB disconnect, address 1
[64720.184731] ehci_hcd 0000:00:1a.7: USB bus 1 deregistered
[64720.184838] ehci_hcd 0000:00:1a.7: PCI INT C disabled
[64730.610396] ehci_hcd 0000:00:1d.7: remove, state 1
[64730.610417] usb usb2: USB disconnect, address 1
[64730.610422] usb 2-4: USB disconnect, address 3
[64730.684860] ehci_hcd 0000:00:1d.7: USB bus 2 deregistered
[64730.684980] ehci_hcd 0000:00:1d.7: PCI INT A disabled
[64731.070210] usb 6-2: new full speed USB device using uhci_hcd and address 5
[64731.254158] usb 6-2: configuration #1 chosen from 1 choice
[64731.259814] uvcvideo: Found UVC 1.00 device FO13FF-50 PC-CAM (05c8:0100)
[64731.273207] input: FO13FF-50 PC-CAM as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2:1.0/input/input11
[...]

En mi caso no tenía conectada la impresora, pero sirve el ejemplo de todas maneras ver cómo la webcam es reconocida por uhci_hcd (USB 1.1). Para volver atrás, supongo que hay que hacer lo mismo pero con bind (no lo probé, sólo me parece lógico…), aunque yo reinicio la máquina para no complicarme.

Esto es fácil de meter en un script, y espero que le sirva a alguien (me llevó un buen rato encontrarlo).

Saludos

Marcelo

[...]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.31-20-generic ehci_hcd
  iProduct                2 EHCI Host Controller
  iSerial                 1 0000:00:1d.7
  bNumConfigurations      1
[...]

Resulta que a nivel de I/O tenemos algo parecido a la virtualización al nivel de CPU: emulación, paravirtualización y ejecución “directa”, por llamarlo de alguna manera. Sugiero leer el artículo para más detalles, pero sólo quiero agregar que recién estamos en la etapa de paravirtualización, y que (en buena hora) Intel y AMD agregaron unidades IOMMU en sus últimos diseños para poder asignar dispositivos directamente a una (o más, según el caso) VM, evitando el Hypervisor y ahorrando ciclos de CPU. Pero esto parece estar verde aún.

Virtio vendría a ser como una serie de drivers de paravirtualización de I/O. Lo bueno es que no sabía que VirtualBox soportaba para las interfaces de red, algo que al parecer (y de esta manera) intenta ser un estándar  (net y block devices por ahora),  ya que tiene una API de comunicación Host <–> Guest abierta, independiente y en paralelo a la propuesta de KVM como hypervisor.

Luego de ver un poco todo esto, me puse  a configurarlo en una VM con WinXP, le instalé estos drivers y ya estoy usando menos CPU para la parte de red en mi guest

Acá se ve un poco la mejora a nivel de tráfico de red *real* que hay usando I/O paravirtualizado:

http://www.linux-kvm.org/page/Using_VirtIO_NIC

En fin, esperemos que todo esto mejore más aún. KVM ya soporta virtio para dispositivos de almacenamiento, además de los de red (linkeo la instalación de los drivers de Windows porque lógicamente Linux tiene estas baterías ya incluídas, je).

Saludos

Básicamente SR permite que exista un proceso “sender”en el master que envíe a procesos “receiver” en el/los nodos secundarios porciones de WAL (Write-Ahead Log), es decir, de transacciones “comiteadas” recientemente. Antes (PostgreSQL 8.4 y anteriores) los WAL se podían archivar a otro nodo una vez se hayan completado 16 MB de transacciones (por defecto), con lo cual si se tenía una BD que “cambie poco”, 16 MB podían representar un lapso de tiempo físico importante. A partir de ahora, el lapso de tiempo se reduce a unos pocos segundos de diferencia en el master y la/las réplicas (dependiendo el enlace, la carga del master, etc.), con lo cual es una mejora substancial en las capacidades y posibilidades de PostgreSQL.

Hay que resaltar que por ahora este proceso es asincrónico, y aunque hay usuarios que pueden necesitar replicación sincrónica, cada esquema tiene sus ventajas y desventajas, y sin lugar a dudas esta primera versión de momento atiende muchísimas necesidades.  Combinado con otra de las novedades de 9.0 que es la posibilidad de usar un nodo secundario (recibiendo WALs mediante SR o el método tradicional) como Sólo Lectura (característica llamada “Hot Standby“), 9.0 da un paso muy adelante con respecto a versiones anteriores.

Para más adelante (y planificado para hacerse, ojo) quedó la opción de Straming Replication sincrónico y obtener más y mejor info del proceso de replicación (lag, estadísticas, etc.). Otro punto flojo, que espero se resuelva mejor (o con un mecanismo estándar), es que uno tiene que scriptear a mano el Failover, es decir, el proceso de recuperación (heartbeat es una herramienta genérica para este tipo de cosas).

Dejo algunos links relacionados con más info y demostraciones:
http://www.depesz.com/index.php/2010/02/01/waiting-for-9-0-streaming-replication/
http://www.depesz.com/index.php/2010/01/08/waiting-for-8-5-hot-standby/

¡Saludos!
Marcelo

Si bien PostgreSQL 8.4 ya salió y tiene unas cuantas novedades, quisiera hacerme eco de lo que está en la cola de parches a aprobar para integrar la nueva rama de desarrollo de PostgreSQL 8.5. Esta lista está compuesta por cosas como:

• GRANT ON ALL IN schema: Una manera de otorgar permisos a todos los objetos de un esquema.
• Machine-readable explain output v2: Salidas del comando EXPLAIN fácilemente legibles por otro software, es decir, fácilmente parseables para su procesamiento. El comando explain aceptaría como segundo parámetro el formato (además de los actuales) la keyword FORMAT, quedando así: EXPLAIN FORMAT [TEXT | JSON | XML]. Está bueno porque abre la puerta del desarrollo de herramientas de auto-tunning, basado en reglas estilo Sistema Experto.
• SE-PostgreSQL: Security-Enhanced PostgreSQL, una mejora sustancial en la seguridad del SGBD y en el nivel de detalles del sistema de privilegios.
• Replicación Sincrónica: Si algo le faltaba a PostgreSQL es una manera de replicación sincrónica integrada en el gestor. Esperemos que esto sí entre, aunque está bastante discutido el asunto porque es un cambio relativamente “gordo” en los internals del código, pero por lo que leí de estas discusiones parece haber consenso en llevarlo adelante e implementarlo. Por mi parte… ¡lo necesito ya!
• \dL para listas los lenguajes utilizados en psql: Es una nueva característica en psql, la de poder listar los lenguajes instalados en la base de datos (plpythonu, plpgsql, etc.).
• Estadísticas de esperas por bloqueos: La idea es poder tener un historial de los bloqueos sufridos por los clientes en la BD, para poder detectar problemas y saber bien qué pasa en todo momento.

Bueno, de más está decir que no hay ninguna garantía de que todo esto sea finalmente integrado en 8.5, sino que se está evaluando al mejor estilo Software Libre™: peer-review, discusión de estrategias del proyecto, consenso en la comunidad de desarrolladores y posterior aceptación/pedido de mejoras/rechazo. Así que veremos cómo sigue.

Saludos!
Marcelo

Ninja

La primera llamada Ninja, que viene a ser algo así (traducido de su página web):

Ninja es un sistema de detección y prevención de escaladas de privilegios para GNU/Linux. Mientras está corriendo, monitorea las actividades de los procesos locales por un lado, y de los procesos corriendo como root por el otro. Si un proceso lanza a otro nuevo con UID o GID cero (root), Ninja va a loguear la información necesaria acerca del mismo, y opcionalmente lo puede finalizar si fue creado por un usuario (es decir, un proceso de un usuario) sin autorización.

En mi opinión, si bien hay herramientas más complejas para hacer este tipo de cosas con servicios en producción, parece un buen complemento cuando se necesita algo más sencillo y no tan crítico, como dar acceso de terminal o X  a usuarios finales. Acá hay un post sobre cómo instalarlo en Ubuntu.

KSplice

La otra herramienta, promete algo que sería la salvación para todos los sysadmins: aplicar actualizaciones al núcleo de un SO sin reiniciar el equipo, “al vuelo”, en forma transparente. Esta herramienta de salvación para todos nosotros se llama KSplice, es abierta, y fue tema de investigación y desarrollo por gente del MIT. Si realmente anda bien y funciona, sólo falta que salga en Slashdot (no creo que tarde mucho…).

KSplice funciona creando actualizaciones (aplicables instantáneamente) para el kernel en ejecución. Estas actualizaciones son igual de efectivas que las estándar (supongamos las que provee la distribución que estamos utilizando), con la diferencia de que no hace falta reiniciar para que entren en funcionamiento.

Para esto, necesita el código fuente de la actualización (un parche para el kernel que se está corriendo), más el código fuente del kernel en ejecución. El núcleo no necesita ser modificado por adelantado para que esto funcione (sólo x86 y x86_64).  El proceso de creación y aplicación de un parche es bastante sencillo, y ¡hasta se puede deshacer!

Por el momento sólo funciona con Linux x86, x86_64 y ARM, que su código se puede bajar en forma de fuente, agregar los repositorios GIT, y también descargar una versión binaria para instalar en cualquier distro GNU/Linux.

Las únicas desventajas (si cabe) en cuanto a lo técnico que le veo es que:

• Sólo aplica parches que no cambien la semántica del núcleo (supongo que esto quiere decir que no hacen que cambie su ABI). Sin embargo, ellos mismos afirman que el 88% de los parches de seguridad para núcleo publicados entre Mayo de 2005 y Mayo de 2008 eran aplicables perfectamente con KSplice. Esto hace que sirva en primera instancia para parches de seguridad, y para corrección de fallos en segundo lugar.
• No hay información sobre qué pasa si reinicio el equipo efectivamente con parches aplicados vía KSplice (supongo que todos los cambios se deshacen, ya que esto es al vuelo y no hay modificación sobre la imagen binaria del núcleo en sí mismo).
• Es necesaria la misma versión de compilador (o casi, ya que no hace un chequeo por número estricto de versión, sino que hace un chequeo de posibles conflictos y aborta en caso de detectar uno, afirmando en su web que esto es seguro).

Por otra parte, próximamente van a ofrecer el servicio de actualizaciones, esperemos que cumplan lo que prometen, a mí me cuesta creer que esto sea así de fácil. Sería bueno que todas las distros lo incluyeran e integraran…

Bueno, es todo por ahora.

¡Saludos!

Marcelo