Dropbox cifrado multiplataforma

Tener datos en la nube me transmite cierta intranquilidad... De algún modo cuando colgamos algo en la nube, uno se expone a numerosos riesgos directos e indirectos por parte de la empresa que ofrece ese servicio y por la topología de Internet.

Con riesgos directos quiero decir que la propia empresa utilice dicha información con fines comerciales y con riesgos indirectos me refiero a la intrusión a los sistemas de esa empresa por parte de terceros. 

No me refiero directamente a Dropbox con lo comentado, ya que en sus políticas de seguridad/usuario exponen que no accederán a nuestros datos e incluso que no tienen acceso a ellos, hablo en plan generalista, aunque, ¿Que pasaría si alguien se colara en sus sistemas?... Con todo esto la mejor opción que se me ocurre es utilizar mecanismos de cifrado.

Dejo aquí un par de sites muy interesantes para configurar carpetas cifradas en Dropbox. Yo lo prefiero así ya que utilizar volúmenes TrueCrypt me parece bastante incomodo. De este modo puedes tener una carpeta cifrada y todo lo demás "abierto ;)". Destaco también que este sistema es multiplataforma y es sencillo y practico para todos los gustos.

                                                                                

Tener una carpeta cifrada en DropBox (Para GNU/Linux)

http://www.tuxapuntes.com/drupal/node/2137

 

Sistema de ficheros cifrado bajo DropBox (Para Windows)

http://www.securitybydefault.com/2011/05/sistema-de-ficheros-cifrado-bajo.html

Encriptar Dropbox con encfs File to File desde OSX (Para Mac)
http://redesysoftware.dustinthewind.es/encriptar-dropbox-con-encfs-file-to-file-desde-osx/ 

Utilizas otro método más cómodo? Comentarios son bienvenidos :D

XenServer - The VDI is not available

Al parecer en la versión 5.6 SP2 de XenServer este error es más común de lo que tendría que ser. Cuando por ejemplo un domain0 tiene una caída "cafre" por corte eléctrico algunos vdi quedan bloqueados e impiden volver arrancar las vm. 

Aparece el siguiente mensaje de error:

29/08/2011 13:23:18 Error: Starting VM 'virtualmachineX' on 'xendom01' - The VDI is not available

Doy por supuesto que ya has probado de hacer un "xe task-list" y ver que no hay tareas pendientes. Si es así primeramente hay que cancelarlas con un xe task-cancel uuid=UUID tarea" y volver a probar, pero si así tampoco arranca... A mi no me aparecía ninguna tarea XD.

Para solucionar esto he seguido los siguientes pasos:

1.- Localizamos el vdi:

[root@xendom01 ~]# xe vdi-list name-label=vmachine01-disk0

uuid ( RO)                : 1ffdd67d-3ff9-46b0-860e-eabe95844fb5

name-label ( RW): vmachine01-disk0

name-description ( RW): vmachine01-disk0

sr-uuid ( RO): 6b12a905-af60-cea1-88a5-854b6898c219

virtual-size ( RO): 13958643712

sharable ( RO): false

read-only ( RO): false

2.- Despresentamos el vdi:

xe vdi-forget uuid=1ffdd67d-3ff9-46b0-860e-eabe95844fb5

3.- Reescaneamos el SR donde estaba el vdi

xe sr-scan uuid=6b12a905-af60-cea1-88a5-854b6898c219

Si miramos en el XenCenter vermos que en el SR aparecera un nuevo disco sin nombre ni descripción. Ese es el vdi nuevamente presentado. Le ponemos el nombre, descripción y lo volvemos a asociar con la maquina virtual.

Arrancamos la maquina virtual y ya vuelve a funcionar correctamente.

XenServer - Eliminar un host del pool sin red

Si intentamos quitar un servidor dom0 de un pool y dicho servidor no tiene conectividad hacia el resto de hosts del pool. Aparecerá el siguiente mensaje:

root@xendom02 xensource# xe pool-eject host-uuid=9712025f-9b98-4c25-81ef-9222993b71f8
WARNING: Ejecting a host from the pool will reinitialise that host's local SRs.
WARNING: Any data contained with the local SRs will be lost.
Type 'yes' to continue
yes
You attempted an operation which involves a host which could not be contacted.
host: 9712025f-9b98-4c25-81ef-9222993b71f8 (xenserver01)

Esto lo podemos solucionar de la siguiente manera:

1.- Verificamos si hay maquinas asignadas como running en el dom0 que queremos eliminar.

root@localhost ~# xe vm-list resident-on=9712025f-9b98-4c25-81ef-9222993b71f8 is-control-domain=false
uuid ( RO) : 013c61ee-3f48-4f65-4377-ae6949f35427
name-label ( RW): onslave
power-state ( RO): running


2.- Hacemos un reset del estado de la/s maquina/s virtuales que esten running:

root@localhost ~# xe vm-reset-powerstate uuid=013c61ee-3f48-4f65-4377-ae6949f35427 --force


3.- Eliminamos el host

root@localhost ~# xe host-forget uuid=9712025f-9b98-4c25-81ef-9222993b71f8 --force

Posiblemente queden los discos físicos que tenia el servidor como dispositivos "not in database". Se pueden eliminar tranquilamente con un xe sr-forget

XenSever - Backup con Snapshots

Este método permite realizar backups de tus máquinas virtuales en formato nativo de Citrix XenServer.

Básicamente el proceso es hacer un snapshot de cada maquina virtual especificada en el fichero de configuración (backup2.cfg) y exportarla a un filesystem del domain0, ese puede ser NFS, SMB, Local... Una vez exportada la maquina virtual la comprime usando gzip. Cada vez que se ejecuta el script comprueba que no haya maquinas más antiguas de siete días en el FS de destino.

Se compone de 3 ficheros:

-backup2.cfg #Fichero de configuración donde se define el disco/directorio de destino del backup y las maquinas virtuales que queremos hacer backup.

-backup2.sh #La shell que lanza el proceso, se puede poner en un cron.

-backup2.log #El log de la shell

Puedes descargarlos desde: https://github.com/fsmsystems/stuff/tree/master/XEN-Backup o mediante git.

XenServer - RedHat / CentOS Paravirtualizados

Una de las ventajas de usar XenServer es la posibilidad de arrancar las máquinas virtuales en modo paravirtualizado (PV). Algunas distros dificultan un poco la instalación en PV directamente desde el Setup. Ese es el caso de Red Hat o CentOS que por defecto se instalan en modo Virtualización completa (HVM).

Una vez instalado el sistema, modificamos los siguientes parámetros del grub:

title CentOS Xen (2.6.18-53.1.14.el5xen)

        root (hd0,0)

        kernel /xen.gz-2.6.18-53.1.14.el5

          module /vmlinuz-2.6.18-53.1.14.el5xen ro root=/dev/VolGroup00/LogVol00

          module /myinitrd.img

Modificamos las líneas en negrita por:

title CentOS (2.6.18-53.1.14.el5xen)

        root (hd0,0)

        kernel /vmlinuz-2.6.18-53.1.14.el5xen ro root=/dev/VolGroup00/LogVol00

        initrd /myinitrd.img

Reiniciamos con el nuevo kernel y creamos un nuevo initrd, sino nos aparecerá el error:

mount: could not find filesystem '/dev/root'

Setting up other filesystems.

Setting up new root fs setuproot:

 ...

Booting has failed

Genramos el nuevo initrd. El nuevo initrd hay que generarlo ignorando el soporte SCSI mediante la siguiente línea:

mkinitrd --omit-scsi-modules --with=xennet --with=xenblk --preload=xenblk initrd-$(uname -r)-no-scsi.img $(uname -r)

Apagamos la maquina virtual y modificamos los siguientes parámetros mediante el CLI para que XenServer reconozca que tiene que arrancar esta máquina como PV.

xe vm-param-set uuid= HVM-boot-policy=""

xe vm-param-set uuid= PV-bootloader=pygrub

xe vm-param-set uuid= PV-args="console=ttyS0 xencons=ttyS"

La volvemos arrancar y tendría que iniciarse correctamente. Si aparece siguiente el error:

Error: (2, 'Invalid kernel', "elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest' section found.\n")

significa que hay algún problema con la config del grub, comprueba que el kernel que has configurado en el grub sea el correcto.

XenServer - Migración de maquinas virtuales entre diferentes pools

El tema en cuestión es bastante habitual, lo he visto preguntado en foros y también, personalmente, me he encontrado con la necesidad de encontrar una solución al hecho de traspasar las maquinas virtuales de un pool a otro como podria darse el caso en una migración de entorno físico donde los nuevos servidores tienen un hardware completamente distinto a los servidores domain0 que tenemos en producción.

Para ello utilizo una maquina virtual en la misma red que el management de los domain0  y una LUN conectada a los dos entornos, no hace falta que sea a todos los miembros del pool, yo lo he hecho con uno domain0 de cada entorno. El proceso tiene dos partes:

Exportación de la VM 

Pool-1  Exportamos la VM  a la LUN compartida

Importación de la VM

Pool-2  Importamos la VM desde la LUN al nuevo storage del nuevo pool

El proceso a mano seria:

1- Montamos la LUN en el serividor de origen

2- Apagamos la maquina virtual: xe vm-shutdown name-label=vm_a_migrar

3- Exportamos la VM: 

xe vm-export name-label=vm_a_migrar filename=LUNFS/vm_a_migrar.xva

4- Desmontamos el FS de la LUN

5- Montamos la LUN en el serividor de destino

6- Importamos la VM: xe vm-import filename=LUNFS/vm_a_migrar.xva

7- Desmontamos el FS de la LUN

El proceso es sencillo y se puede hacer a mano, pero para no corromper el filesystem en caso que por error montara el EXT3 de la LUN en dos servidores a la vez, he hecho el siguiente script de bash (migrate.sh) que monta y desmonta la LUN en cada pool para cada uno de los procesos Exportación/importación de modo que solo esté montado en un servidor a la vez.

La sintaxis es migrate.sh nombre_de_la_vm entonces el script se encarga de apagar la maquina virtual,  hacer la exportación xe vm-import ... desde el servidor original $S_OR y la importación en servidor (pool) de destino $S_DE de la maquina virtual que le hemos especificado. Una vez finaliza deja la máquina virtual original y la nueva apagada y la LUN desmontada en ambos servidores.

Si en tu entorno no se puede para las maquinas en producción, puedes hacer el mismo proceso pero en vez de apagar la maquina, capturar un snapshot y luego exportarlo como maquina virtual mediante: 

xe template-param-set is-a-template=false ha-always-run=false uuid=$snapshotUUID

Espero que les sirva de utilidad.
Saludos

Ferran Serafini, nuevo moderador de los foros de virtualización XenServer

Tal día como hoy, hace una hora, se me ha presentado oficialmente como moderador de los foros de virtualización de XenServer en http://www.josemariagonzalez.es/foros/ donde estaré encantado de poder ayudaros en vuestros problemas con XenServer. 

Para quien no conozca este site, es una web de referencia dentro del mundo de la virtualización. Desde que empece a seguirlo percibí que tanto la comunidad de usuarios recurrentes como los nuevos, aportan preguntas y soluciones de alto nivel. Es por eso que para mí es un honor poder formar parte de esta comunidad como moderador.

Aparte del foro podemos encontrar el blog http://www.josemariagonzalez.es/ todo un blog de referencia para entusiastas de la virtualización galardonado por ejemplo con la categoria de vExpert durante tres años consecutivos. Desde hace un tiempo también podemos ver a José María González en http://www.virtualizacion.tv/ donde realiza el "show de la virtualización y Cloud Computing", un entretenido programa semanal donde se exponen trucos, casos de éxito y respuestas a preguntas.

Des de aquí mando le mando un saludo a él y a todo su comunidad.

XenServer - Netback CPU al 100% y sin red

El otro día mientras cambiaba la configuración de una Network para que utilizara otra NIC y posteriormente eliminar las antiguas Network con la NIC anterior tuve una caída "chungisima"... 

Todas la máquinas virtuales de dos domain0 se quedaron sin conectividad por otra Network que nada tenia que ver con las que estaba reconfigurando.

Lo que se podía ver en esos domain0 era un proceso "netback" al 100% de CPU, intenté matar el proceso sin fortuna. Al final se recuperó reiniciando los servidores, el susto fué importante.

Googleando por la red he visto que no soy el único que ha tenido este tipo de caidas. Al parecer este error esta causado porque el servidor domain0 se queda sin memoria. Se puede solucionar asignando una cantidad de memoria exclusiva para el domain0 mediante el siguiente parametro en el grub:

dom0_mem=512M

Y mediante el fichero de config de Xen cambiando dom0-min-mem=256 por dom0-min-mem=0

Esta solución funcionará para plataformas Xen OpenSource pero no para Citrix XenServer.

Entrando un poco a fondo de lo que es netback

netback forma parte de los Backend Drivers, estos están iniciados en los Dom0. Tenemos principalmente controladores de red y controladores de bloqueos. Este controlado en concreto forma parte de los modulos de red y reside en sparse/drives/xen/netback. El controlador de bloqueo esta en sparse/drives/xen/blkback.

Hay muchas cosas en común entre los controladores netback y blkback. La diferencia principal es que los controladores de blkback corren bajo un hilo del kernel (xenblkd), mientras que el controlador netback no corre en ningún hilo del núcleo.

Posiblemente al quedarnos sin memoria, la interconexión entre NetFront y NetBack dejó  las VM incomunicadas.