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