crux@macumba:/var/blog$

in 1 mes, 9 días, 16 horas, 53 minutos, 39 segundos

…no es caída. ¿O sí?

Les pido disculpas a los millones de lectores del blog porque habrán notado que esta semana estuvo caído.

Hace unos 20 días macumba empezó a colgarse y descubrí un sector defectuoso en el disco. Me llevó un buen rato poder meterle mano pero ya parece estar todo bien. Además el cable de alimentación del disco estaba medio suelto así que no sé que habrá sido primero.

Lo más relevante de todo esto para Uds. es que la base de datos MySQL explotó y tuve que recuperar desde backups y el último que tenía era del 18/6/2008. Eso implica que cualquier comentario que hayan dejado desde ese entonces hasta hoy se esfumó en el éter de la Internet. Lo siento.

Ahora continuamos con nuestra programación habitual.

Tampoco apoyo al gobierno!

En general no apoyo a nadie con poder que tenga pretenciones de salvador. Ya sea la de repente bondadosa oligarquía dueña de los intereses del campo ni tampoco el de repente justo gobierno populista. Disculpen pero soy desconfiado por aprendizaje. ¿Será que no soy suficientemente argentino?

No me la agarro contra el gobierno “por costumbre”. No me la agarro contra el campo “por defender al gobierno”.

Quiero dejar en claro ésto porque últimamente lo único que escucho es un montón de gente puteando contra el gobierno y eligiendo lados como si se tratara de un River-Boca. Los medios contentos. Al que formó su juicio crítico con información lo felicito y lo invito a que disentamos. Así se crece. NO podemos estar TODOS de acuerdo SIEMPRE.

He dicho

PD: Disculpas por la queja pero necesitaba decirlo

It’s been a little over two months since I accomplished this and wanted to share it as I hadn’t found it anywhere over the net. It took me a while but finally it’s here! Enjoy!

To get everyone in context I’ll say that I had some Xen VMs which used LVM volumes as disk images living in one machine and I suddenly needed them on another one. After searching for some tried and tested solution I found none. So the only option I could see was to do some kind of dump (probably dd involved with bzip2) and bring them over to the other machine. Be it by network, DVD or external disk. Haven’t done it before, and it sure would have taken some effort on my part. Downsides: dangerous precise movements required and nothing new learned. This was a no-op

Luckily an alternative came to my mind. I could use AoE [1] (ATA over Ethernet not Axis of Evil nor Age of Empires!!!) and some LVM wizardry. Upsides: dangerous precise movements required and cool stuff learned. This was the way to go!

Just for the sake of clarity some definitions and requirements first. All the stuff below was done on two Debian Etch 4.0 boxes. Both of them having Xen for virtualization and LVM2 for storage administration. You’ll need an AoE enabled kernel (Debian’s kernels are from 2.6.11+). You’ll also need the aoetools package in the destination machine at least. Let’s call ORIG and DEST the machines and VG = Volume Group, PV = Physical Volume and lv = Logical Volume. If that’s mumbojumbo to you then keep away from the next commands!

Now to the recipe:

Enable AoE server on ORIG

root@orig-host# vbladed 0 0 eth1 /dev/md1

That should export any block device you want over eth. In my case a whole RAID device (md1) was exported through eth1 with major 0 and minor 0. Consider that Ethernet protocol is layer 2 and is non-routable. Another thing is that AoE provides no security inherently, so I enabled it manually for this and disabled it afterwards. If you are going to use it otherwise make sure you design a security scheme to go with it.

Enable AoE support on DEST

root@dest-host# modprobe aoe

Then search for AoE devices and make sure it found some

root@dest-host# aoe-discover
root@dest-host# aoe-stat

That should output something like “e0.0 250.000GB eth0 up”. At this point you should have a new block device available on the client box named /dev/etherd/e0.0. You can do anything to that block device as if it was a locally attached device. Cool!

Now we have to disable the ORIG-VG and make it unknown to the ORIG LVM system

root@orig-host# vgchange -an ORIG-VG
root@orig-host# vgexport ORIG-VG

Tip from experience: it’s better to have a dedicated VG for storing VMs images so we don’t have any downtime in the real box. I had the root filesystem on the same VG and had to switch to runlevel 1 just in case

Search for new PVs on DEST and add them to LVM

root@dest-host# pvscan

Merge the two volume groups into one

root@dest-host# vgmerge DEST-VG ORIG-VG

Move LVs from ORIG-PV to DEST-PV. This is the step that’s gonna take forever or not depending on your network speed and the amount of data to move. I don’t have my exact figures but I recall it taking a couple of hours.

root@dest-host# pvmove -n some-lv /dev/etherd/e0.0 /dev/md1

Note this time /dev/md1 is the destination RAID device which belongs to DEST-VG, not the one on ORIG box stated before.

Once it finishes we want to make things go back to normal. So we disable the VG so we can do the split (James Brown style baby!) Then we re-enable the VG

root@dest-host# vgchange -an DEST-VG
root@dest-host# vgsplit DEST-VG ORIG-VG /dev/etherd/e0.0
root@dest-host# vgchange -ay DEST-VG

Now we have to disable the ORIG-VG and make it unknown to the DEST LVM system

root@dest-host# vgexport ORIG-VG

Back to the ORIG box we re-add the “lost” VG and re-activate the VG

root@orig-host# vgimport ORIG-VG
root@orig-host# vgchange -ay ORIG-VG

And that should be it! I’ll stop writing now since it’s a long post already. Hope somebody finds this useful and/or inspiring. Good luck!

[1] http://www.howtoforge.com/ata_over_ethernet_debian_etch

Who hasn’t sent an email claiming it had an attachment but forgot to include it? I certainly have. But don’t worry, you can start using Evolution and if you do forget your attachment the program will try to guess and remind you about it.

Esta mañana estaba en el laburo intentando crear un pernodrive booteable. Después de algunos intentos fallidos decido empezar de nuevo: “dd if=/dev/zero of=/dev/sda” … me agacho para ver si el LED del pendrive parpadeaba y no … vuelvo a mirar el monitor y lo más rápido que pude apreté Ctrl-C. La salida de dd indicaba que había alcanzado a llenar de ceros los primeros ~150MB del disco rígido. Eso incluyó el Master Boot Record (MBR) y la tabla de particiones.:oops: (Nota para los distraídos: el dispositivo correcto hubiera sido /dev/sdb)
Después de sufrir un corto pero efectivo ataque de pánico que me dejó catatónico mi cerebro volvió a la vida y empecé a pensar como hacer para arreglar ese pequeño inconveniente. El sistema seguía funcionando a la perfección. Los datos que tenía con certeza eran que el disco tenía dos particiones, una sda1 con un /boot de ~1GB y una sda2 con LVM de ~250GB. Casi seguro que los datos que se rompieron fueron las imágenes de kernels y demás yerbas del /boot. Eso no es crítico para que el sistema siga andando, sólo para que vuelva a arrancar.
Salí corriendo a buscar un disco rígido externo que hay por ahí en la oficina y le creé una partición del tipo LVM. Inspirado por este 1, 2, 3, 4 del LVM-Howto me puse a laburar. Creé el volumen físico en el disco externo con pvcreate y se lo asigné al grupo de volúmenes con vgextend. Después hice que los volúmenes lógicos que tenía (root, home y data) se pasaran al disco externo con pvmove. Esto demoró un buen rato y mientras estuve rezando para que no fuera a fallar nada más mientras que hacía esto. Al menos estaba seguro que la tabla de particiones estaba en la memoria del kernel, pero no estaba seguro que LVM no fuera a intentar nada raro mientras hacía esos pases mágicos. A propósito, y se me acaba de ocurrir, habrá alguna manera de saber con detalle suficiente cuál es la idea que tiene el kernel sobre la tabla de particiones? Ya voy a investigar, pero si alguno que lea esto lo quiere comentar no me enojo.
Una vez que terminó de mover todos los datos saqué el disco interno del grupo de volúmenes con vgreduce. También desmonté todas las particiones de ese disco y las volví a crear aproximadamente a como eran con fdisk. Reinstalé el paquete linux-image-2.6 y puse el GRUB de nuevo en el MBR. Para finalizar hice todos los pasos anteriores del LVM pero al revés, moviendo los datos desde el disco externo al disco interno nuevamente.
Crucé los dedos y reinicié. Y todo volvió a estar como antes!
Moraleja: LVM es una herramienta muy poderosa, pero aún más lo es dd

In an interview that appears in the film “This film is not yet rated (2006)” [1] [2] mister Jack Valenti says: “…the motion picture association is composed of the seven largest producers of film and television in the world, the old great studio names, and I’ve been the head of it 34 years…”. The association he was referring to is the MPAA (Motion Picture Association of America) which is integrated by:

• Sony Pictures
• Warner Brothers
• Universal
• 20th Century Fox
• Walt Disney Pictures
• Paramount
• MGM (bought in 2005 by capitals in part from Sony)

These corporations control more than 95% of the U.S. film business

Even more, these corporations are part of even larger conglomerates:

• Sony Pictures → Sony
• Warner Brothers → TimeWarner
• Universal → General Electric
• 20th Century Fox → News Corp.
• Walt Disney Pictures → The Walt Disney Company
• Paramount → VIACOM
• MGM → Sony

These last conglomerates own more than 90% of all media in the U.S.

PS: Watch the movie. It’s a documentary about how the MPAA accomplishes censorship in the land of freedom in the most open and declared way. One more and counting…