Probando RAM con MD5sum

Copio de un post de Guppi en Kriptopolis:

"El algoritmo MD5 es un algoritmo de reducion criptografico.

Basicamente sirve para firmar un mensaje, es decir, al algoritmo le pasamos un mensaje (da igual la longitud de este) y MD5 nos devuelve 128 bits que serian la firma del mensaje. Con cambiar un solo bit en el mensaje, el resultado de MD5 cambia totalmente.

Aqui tienes para que veas como funciona:
http://es.wikipedia.org/wiki/MD5"

O sea, la utilidad primaria del MD5 es probar si un archivo no ha cambiado, aunque sea en un solo bit. Esto se logra generando un "resumen" (digest) del texto o archivo que se supone único para ese texto, como el resumen es único sirve para "firmar" criptograficamente textos o archivos. Cada vez que pasemos MD5sum a un texto o archivo, si da el mismo resumen podemos estar seguros que no ha sido alterado ni un solo bit.

Esto tiene una aplicación muy interesante que permite detectar si la memoria RAM de un computador presenta problemas. Simplemente se toma un archivo cualquiera muy grande, por ejemplo una imagen ISO y se le hace MD5 unas 10 o 20 veces, el resultado tiene que ser siempre el mismo, si sale un solo resultado distinto entonces la memoria RAM està con problemas.

El MD5sum para windows pueden bajarlo aqui En Linux y Unix viene incluìdo en el sistema.

Revisando Bucardo con GIT

Bucardo es un sistema de replicación asíncrona de bases de datos Postgres SQL, esto es un sistema que permite -por ejemplo- mantener respaldos actualizados de bases de datos en servidores ubicados en distintas ciudades, usando Internet a través de conexiones seguras SSH. La alternativa es hacer respaldos vía LAN con servidors ubicados físicamente en el mismo lugar, pero eto no es bueno en términos de seguridad en caso, por ejemplo, de una catástrofe, incendio, etc. donde están ubicados ambos servidores.

GIT por su parte es un sistema alternativo a Subversion, para trabajo colaborativo y control de versiones, al parecer diseñado por Linus Tovards para ordenar el desarrollo de Linux. Su gran ventaja es que es muy rápido y funcionaba bajo Linux.

Pero no por mucho tiempo, porque Google Code desarrolló msysGIT para Windows que permite tener este control de versiones en windows de manera similar a lo que hace Tortoise con Subversion.

Mi tarea era instalar GIT y clonar el repositorio de Bucardo para poder revisar las novedades de su desarrollo (Bucardo todavía está en pleno desarrollo). Para eso lo prinero que hice fue descargar msysGit desde este link en Google Code e instalarlo.

Esto me dejó instaladas dos distintas versiones de GIT: una en batch mode y otra con interfaz gráfica de usuario. Finalmente tuve que usar ambas. No pude clonar el repositorio de Bucardo, ubicado en http://www.bucardo.org/bucardo.git/ con la GUI así es que entrando al batch mode y leyendo la ayuda hice un:

$ git-clone http://bucardo.org/bucardo.git/

Initialized empty Git repository in c:/Documents and Settings/Tomas/bucardo/.git/

got ......
walk......

Gtting alternates list for http://bucardo.org/bucardo.git
got...
got...
got...

Getting index for pack .....
got....
got...
got....
walk..
walk...
walk...
etc.

(donde ... representa una serie de letras y números que no tengo la menor idea que serían)
Después de eso se creó en C:\Documents and Settings\Tomas\ una carpeta llamada Bucardo, que contenía varios archivos y carpetas, entre los archivos

files bucardo.html
bucardo.pm.html
bucardo_ctl,html
.perllcriticrc
bucardo.schema
bucardo_ctl
changes
LICENSE
bucardo.pm
bucardo.schema
INSTALL
MAkefile.pl

Y las carpetas .git, t y scripts ¡parece que ya tengo clonado el repositorio!

Luego usando GIT GIU elegí la opción Open existing repository y me aparecieron los contenidos del repositorio en una forma leíble por seres humanos normales



O sea, parece que voy más o menos. Me imagino que usando Remote, Fetch from Origin se debería actualizar el repositorio, espero que así sea, recién estoy averiguando como funciona la cosa

Clonado Ubuntu vía SSH

El problema era clonar el Ubuntu 7.10 que tenía funcionando en una máquina Virtual PC hacia el disco de 650 GB de mi nuevo servidor Linux. No fue buena idea, al parecer el disco virtual de tamaño dinámico no se llevaba bien con la estructura del disco de 650 GB, parece que había un problema de emulación SCSI vs. IDE/PATA.

En la práctica esto significó que aunque el disco se clonó, el Linux copiado en el server tuvo muchos problemas del tipo "segmentation faults" que hicieron al sistema clonado inoperante. Peor todavía, al tratar de instalar el gOS que venía con la motherboard, manteniendo el disco clonado en otra partición, comenzaron a aparecer problemas de hardware, congelamiento, errores I/O etc. La única forma de solucionarlo fué haciendo una partición que ocupa todos los 650 GB del disco duro, total, eso más tarde se puede modificar.

En todo caso el procedimientoes de clonar por ssh es el mismo que se usa para hacer backup remoto de servidores, así es que lo describiré porque puede servir para otras cosas.

En el laptop IPCLENOVO tengo Windows XP y varios Linux en máquina virtual, entre ellos el Ubuntu 7.10. Para arrancar el server usé un live CD con trinity-rescue-kit.3.3-build-306.iso, una vez arrancado hice ifconfig para ver la IP de ese equipo (192.168.1.103), luego arranqué el Ubuntu 7.10 desde Virtual PC y con ifconfig también anoté la IP (192.168.1.109) luego hice ping para ver sis se conectaban sin problemas cosa que ocurrió.

Luego volvi a arrancar Trinity en el server, pero esta vez con la opción SSH server habilitada. En el Ubntu 7.10 de Virtual PC instalé el meta-paquete ssh. Luego me fuí a Windows en el laptop y usando Putty abrí sesiones ssh para 192.168.1.103 (server con Trinity) y a 192.168.1.109 (para Ubuntu 7.10 VPC)). Ingresadas estas sesiones y autentificado, seguí el procedimiento indicado en este link, para hacer la transferencia. Fundamentalmente consiste en:

nc -l -p 9000 | dd of=/dev/hda en el sistema con Trinity

Luego en la sesión de Ubuntu Virtual PC

sudo bash
dd if=/dev/sda | nc 192.168.1.103 9000

Aparentemente no ocurre nada, exepto que los prompts desaparecen de ambas sesiones, pero la actividad de los discos duros muestra que se está haciendo la transferencia de los 16 GB desde el Ubuntu Virtual PC hacia el server con Trinity, después de casi una hora, esta transferencia se completa. Los conceptos clave en este caso son: la transferencia por cables de la red local usando ssh (ambos equipos van conectados por cable al router), el esquema amo-esclavo de conexión y el comando dd para clonar un disco.