Anotaciones sobre la instalación y puesta en marcha de Bacula en una máquina virtual funcionando bajo Windows XP.

Planteamientos

La actividad que tenemos dentro de la máquina de Windows XP es muy limitada pero no inexistente. Y mientras no consiga «reparar» un par de utilidades para que funcionen bien en Linux seguiremos añadiendo datos, bit a bit, a un disco duro virtual que no tiene respaldo alguno.

Encontré hace tiempo un programa excelente para sincronizar máquinas Windows llamado Always Sync, visualmente atrayente, fácil de configurar y usar -incluso con trabajos planificados- y demoledor en los diagnósticos. Cuando trabaja viene a ser una copia espejo de tus procesos mentales así que todas las dudas de sincronismo que puede tener, cuándo mover un archivo a un lado y cuándo no, son identificables a poco que te pares a pensar en ello.

El problema que le veo es que es demasiado Windows, tanto que funciona con máquinas en red sólo de este tipo (con la excepción puntual de cosas como Amazon S3) y me parecía redundante sincronizar con una carpeta compartida vía Samba y luego integrar ésta en Bacula cuando puedo hacerlo directamente ya que sé que debe estar encendido un buen número de días a la semana.

Así pues, viendo que Bacula funciona muy bien en Windows siempre que entiendas qué hay que salvar en realidad, me decido a instalar el cliente y tras no pocas peripecias me encuentro con el principal obstáculo: la máquina virtual debe ser accesible en la red como una máquina más. Debo entonces ajustar la configuración del emulador para ello y activar el cortafuegos de Windows para controlar en lo posible las «llamadas a casa» de terceros.

Obtención del software

Bacula para Windows puede obtenerse de los repositorios oficiales ya que conservan versiones de 32 y 64 bits para ambas ramas: la 3 y la 5.

En mi caso descargo las correspondientes a la versión 3 por ser las más cercanas a la versión 2.4 que empleo en los servidores Debian Lenny y cruzo los dedos para que no tenga problemas de comunicación con los diferentes servidores que conforman el sistema de copias.

Como he bajado también el archivo de firma del paquete procedo a verificarla, indicando a GPG que recupere las claves públicas de su servidor predeterminado:

$ gpg --keyserver-options auto-key-retrieve=1 --verify winbacula-3.0.3a.exe.sig
gpg: Firmado el mié 09 dic 2009 06:29:45 CET usando clave DSA ID A361392A
gpg: solicitando clave A361392A de hkp servidor pgp.rediris.es
gpg: clave A361392A: clave pública "Bacula Systems (Bacula Systems Distribution Verification Key) <kern@baculasystems.com>" importada
gpg: 3 dudosa(s) necesarias, 1 completa(s) necesarias,
modelo de confianza classic
gpg: nivel: 0  validez:   5  firmada:  11  confianza: 0-, 0q, 0n, 0m, 0f, 5u
gpg: nivel: 1  validez:  11  firmada:   4  confianza: 9-, 0q, 0n, 2m, 0f, 0u
gpg: siguiente comprobación de base de datos de confianza el: 2015-01-09
gpg: Cantidad total procesada: 1
gpg:               importadas: 1
gpg: Firma correcta de "Bacula Systems (Bacula Systems Distribution Verification Key) <kern@baculasystems.com>"
gpg: ATENCIÓN: ¡Esta clave no está certificada por una firma de confianza!
gpg:           No hay indicios de que la firma pertenezca al propietario.
Huellas dactilares de la clave primaria: 0AA0 43FF 0616 2B55 E28E  D022 0366 17EE A361 392A

Como dicen en la documentación de GPG esta opción de búsqueda de claves (

auto-key-retrieve

) entraña cierto riesgo de revelación de información, ya que los operadores del servidor de claves saben qué clave se ha buscado, en qué momento y desde qué dirección IP. ^[1]

Instalación y configuración en el cliente

Una vez copiado el ejecutable a la máquina Windows analizo su contenido con el antivirus (Clamav) y tras ver que está limpio, lo lanzo y elijo la instalación rápida que solo me pide el identificador, la contraseña y el nombre en red del director de copias que puede contactar con él, además de indicarme que la configuración se guardará en el archivo

c:\londres-fd.conf

(Londres es el nombre de la máquina). Este archivo contiene las directivas a añadir a la configuración del director de copias.

El caso es que una vez terminada la instalación no he visto que lanzase el programa bacula como servicio y he estado buscando sin éxito la manera de hacerlo. Y aquí es donde he tenido que recurrir por primera vez a la documentación que acompaña al programa porque estoy acostumbrado a que los programas para windows, cuando funcionan, lo hagan te guste o no de forma autónoma y justo después de terminar de instalarlos.

El manual viene en PDF y tengo instalado como visor el programa llamado Sumatra. Procedo a abrirlo y me dice que es la versión 0.9.3 y que hay disponible la 0.9.4 que si quiero actualizarlo. Como supongo que tendrá que ver con la seguridad le digo que adelante y abre el navegador, me lleva a su página y allí me entero que no es la 0.9.4 si no la 1.0.1 y que si quiero amor. Le digo que vale, que acepto porque no tengo otra y descarga y lanza la instalación (a todo esto Windows actualizando porque hoy al parecer había un aluvión de parches del fabricante); después me dice que no, que tiene una instancia suya abierta y que no puede grabar sobre el ejecutable. Ya, claro, si eso ya lo sé, pero otros programas de los llamados «de terceros» cuando se encuentran ante dicho dilema cierran esa instancia y continuan sin alarmismos tontos. Bueno, pues vale, cierro y le digo que siga y sigue y al final me abre la documentación y veo que hay unos cuantos problemas con los que no contaba, entre ellos el de que el director de copias y el servidor de almacenamiento tiene que poder acceder directamente a este servidor de archivos.

Así que toca ajustar la configuración a mano y empleando tal vez algunos de mis apuntes.

A todo esto, entremedias he tenido una actualización de Java que también me ha dado cierto trabajo, pero ya parece que el sistema se ha estabilizado.

Cliente accesible vía red

Como uso qemu para la máquina virtual en Windows XP he consultado mis notas al respecto y he modificado el programa de arranque para que pueda ser accesible directamente por el sistema.

Conseguir ésto parece ser más fácil de lo que creía aunque se me plantean dudas sobre la seguridad -ya tengo otra máquina virtual en la misma máquina física- así que tendré que darle algunas vueltas más antes de pasarlo a producción. El método consiste en crear el interfaz de red

tap1

, añadírselo al puente que tengo ya funcionando e indicarle al emulador que lo emplee.

Según las fuentes consultadas es conveniente que ambas interfaces de red tengan una dirección MAC distinta, así que he descargado de la red un script Python llamado macgen.py y he apuntado un valor distinto para cada instancia de qemu.

# tunctl -t tap1
# brctl addif br0 tap1
# brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.0015175ea9d8       no              eth0
tap0
tap1
# qemu -net nic -net tap,ifname=tap1,macaddr=00:16:3e:13:5d:12 $OTHER_OPTIONS $VIRTUAL_DISK

Como existe un servidor de direcciones IP en la red la máquina Windows engancha a la primera y parece que funciona. Y digo bien, parece, porque se producen extraños retrasos en el acceso a las dos máquinas virtuales, similares a parones, y he tenido que apagar una de ellas (la Windows obviamente) dado que la otra es vital para el trabajo.

Y además he descubierto …

… otra cosa sobre mi red: dos dispositivos se están anunciando vía uPnP al resto del mundo mundial. Se trata del router inalámbrico funcionando bajo OpenWrt y una impresora Samsung ML-2855. En ambos es muy sencillo desactivar dicha funcionalidad.

Es más, también hay un recurso de red («windows share») que aparece normalmente junto con los dos dispositivos anteriores; tengo que ver quién está anunciándose pero me huele a restos de alguna prueba antigua.

Enlaces y referencias

1. La entrada «QEMU TAP bridge network configuration» del blog de Alan Tan@.
2. Página «QEMU and Tuntap» del wiki de Qemu.
3. El artículo «Using QEMU for cross-platform development» en la red de IBM.
4. Página «Networking» del proyecto KVM.