Howto


28
Jul 10

Backups de Nokia con Linux

Como suele ser común, la preocupación sobre una estrategia de backup solo surge después de un accidente. En mi caso, al tirarme a la piscina con el telefono movil en el bolsillo después de atiborrarme a tintos de verano para aguantar el calor durante un asado. Al final el cuento terminó con final feliz ya que después de pasar dos días sumergido en arroz el telefono volvió a revivir. Mientras tanto tuve que tirar de un movil viejo que no tenía los contactos con los que suelo comunicarme habitualmente y me surgió la duda de que haría si el telefono no reviviese. Facebook tiene una página de numeros de telefono de mis contactos, pero no todo el mundo tiene su numero publicado o actualizado y no todo el mundo tiene una cuenta de Facebook.

Una vez que pude volver a encender el movil estropeado me puse a buscar formas de generar backups de la información guardada en el movil. Ya que es notoria la baja calidad y compatibilidad del PC Suite (lease: unicamente para Windows) que viene con todos los telefonos Nokia quería encontrar o una alternativa abierta o algún método que dependiese lo menos posible en conexiones USB/Bluetooth/infrarojos. Después de un par de busquedas en google conseguí encontrar dos métodos que cubren dos aspectos distintos del backup y no requieren ningún tipo de software especial.

El primero es para generar backups completos del telefono usando una utilidad interna que podemos encontrar en Herramientas -> Memoria -> Opciones -> “Copia de seguridad en la tarjeta de memoria”. Esta utilidad genera un archivo Backup.arc y lo guarda en la tarjeta de memoria del telefono, luego se puede restaurar (en teoría a cualquier telefono symbian) o copiar desde un lector de tarjetas de memoria. Como no estoy muy seguro de que este método haga una copia de los contactos hay un segundo método especifico para los contactos.

Contactos -> Opciones -> Marcar todo -> “Copiar a tarjeta de memoria” copia todos los contactos en formato vCard a la tarjeta de memoria. Este método tiene la ventaja de que podemos ver/modificar/borrar los contactos individualmente desde otro programa o con un editor de texto. También, al ser un formato abierto y bastante extendido se debería poder importar los contactos a otro telefono con un sistema operativo distinto.

Fuentes:
Método 1: How to backup the data from Nokia E51 on Linux system?
Método 2 : Backup and restore Nokia contacts without PC-Suite


27
Feb 10

Bug #485923

Cuando comencé a usar Ubuntu Karmic la única cosa que no me gustó fue el consumo de memoria exagerado de algunas aplicaciones. Llegaba a ser tan malo que no podía dejar el ordenador encendido más de 5 días sin tener que reiniciar la sesión de Gnome. Al principio asumí que era el típico bug serio que sería solucionado rápidamente cuando mucha gente se quejase, pero investigando en Launchpad unas semanas después del lanzamiento de Karmic ni siquiera había una mención al problema. Investigando un poco más pude concluir que el problema era cosa de dos aplicaciones: gnome-settings-manager y gnome-volume-control-applet que al ir pasando el tiempo llegaban a consumir cantidades ingentes de memoria (1.5GB+ cada una). Al final, como no era un problema tan serio lo olvidé y me acostumbré a vivir con ello, a la espera de que con Lucid Lynx desapareciese.

Pero ayer por la tarde, mientras me aburría un poco me puse a buscar y esta vez tuve más suerte. Resulta que el problema es debido a una perdida de memoria de gnome-volume-control-applet junto con un comportamiento extraño de wine. Esto no sería un problema tan serio si no fuese porque yo uso Spotify con wine todo el día.

La buena noticia es que el problema fue solucionado hace unos pocos días. La mala noticia es que al ser un problema poco relevante para los usuarios regulares de Ubuntu y al no ser Karmic una LTS no se ha puesto el arreglo en los updates. La otra buena noticia es que un simpático usuario ha compilado la versión buena de gnome-volume-control-applet y la ha colgado en Launchpad. Con añadir las dos lineas a nuestro sources.list y hacer un apt-get update y upgrade ya nos basta para que este molesto problema desaparezca.


27
Aug 08

Para la próxima

Pequeños saltamontes, prestar atención.

Cuando uno compila PHP, es conveniente usar el parámetro --enable-shared al ejecutar ./configure para no pasaros 5 horas investigando por qué PHP no quiere cargar las extensiones externas (PECL, o compiladas a mano con phpize).

Sí, ya se que suena obvio ahora, pero ya me podría haber dicho algo PHP en vez de quedarse mirandome así con cara de que no pasa nada.


27
Jul 08

HOWTO: Install Ubuntu over a network

I recently bought a laptop with a broken cdrom drive and this is how I’ve managed to put Ubuntu on it. The process is based on this tutorial on the official Ubuntu help site, although it differs slightly in software used and goes into more detail.

The Problem

I have a laptop I want to install Ubuntu on and I can’t use the cdrom. This method is also useful if you want to install Ubuntu on a bunch of machines at the same time without having to deal with the hassle of burning multiple copies of the cd image.

Minimum Requirements

This process is faily complicated and requires a few things that aren’t normally available. First off you need the target computer to support booting over PXE. Most modern BIOS support this nowadays, but if you’re dealing with legacy hardware this could be an issue. The second basic component is another computer which will act as the PXE server. You’ll need to install a dhcp server, a tftp server, and you’ll need to configure it to act as a internet proxy for the target computer. The point is that you need full access to this machine and you’ll need to have both machines connected over a network, preferably ethernet.

My setup

To make the tutorial easier to follow here’s what I have and what it’s called.

Joker (192.168.2.X) is the laptop I want to install Ubuntu on, it is connected through a switch to blackmesa (192.168.2.1) which is another laptop which acts as a router for the house network, it does dhcp, tftp and ip forwarding so that the other computers can get to the internet.

Let’s get started

First we’ll get blackmesa setup to serve the files we need. We’ll need to download the alternate cd image, or one of the minimal install images. The alternate image can be found next to the normal desktop and server images on any of the Ubuntu ftp mirrors. The minimal cd images are linked from a page on the Ubuntu help wiki.

The tutorial uses dnsmasq as the dhcp and tftp server, I used dhcp3-server because that’s what I already had running. dhcp3-server doesn’t have a built-in tftp server so we’ll need one as well.

sudo apt-get install tftpd-hpa tftp-hpa xinetd dhcp3-server

My /etc/dhcp3/dhcpd.conf file looks like this:

subnet 192.168.2.0 netmask 255.255.255.0 {
    option routers 192.168.2.1;
    option subnet-mask 255.255.255.0;
    option domain-name-servers 80.58.61.250, 80.58.61.254;
    range dynamic-bootp 192.168.2.2 192.168.2.254;
    default-lease-time 21600;
    max-lease-time 43200;
    filename "pxelinux.0";
    next-server 192.168.2.1;
}

The important lines are the last two. filename specifies what the file PXE will try to grab is called, pxelinux.0 is the normal value for this and what the file Ubuntu uses is called. next-server tells the client computer where to find the PXE files. In this case, because the tftp server and the dhcp server are the same the ip number is the same.

Now we copy the files we need for netboot. We mount the iso image as a loop device:

sudo mount -t iso9660 -o loop ubuntu-8.04.1-alternate-i386.iso /media/cdrom

And copy the files we need to the tftp server folder

sudo cp -a /media/cdrom/install/netboot/* /var/lib/tftpboot/

Next we configure the tftp server by creating a new file called /etc/xinetd.d/tftp, it should look something like this:

service tftp
{
    disable                 = no
    socket_type             = dgram
    wait                    = yes
    user                    = root
    server                  = /usr/sbin/in.tftpd
    server_args             = -v -s /var/lib/tftpboot
}

And reboot the tftp service

sudo killall -HUP xinetd

The last thing you need to do is enable the host computer to do ip forwarding so that the client computer can get to the internet and download the packages it needs. To do so is fairly simple:

sudo su
echo 1 > /proc/sys/net/ipv4/ip_forward

If all is well we’re done setting up the host machine, blackmesa in this case.

Onto the client

Telling the client to boot from the network device is very easy but varies wildly from BIOS to BIOS. In my case I had to go into the boot order page and enable Ethernet device and set it as first option. Now when you reboot, your computer will bring up a text based installer. If it doesn’t and it gets stuck grabbing dhcp or comunicating with the tftp server then something is going wrong, in my case the process was so quick I didn’t even see this screen.

Once in the text based installer, continue the install process as you normally would, but remember to disable network booting after you’re done or you’ll get sent to the text based installer when you reboot.


7
Oct 06

HOWTO: Backups remotos con rsync

Después de unos meses de infructosos intentos conseguí esta semana hacer backups remotos con rsync, dado que me costó tanto he decidido compartir la experiencia y espero que le ahorre a alguien unos cuantos meses y disgustos. Ahí va!

El escenario es el siguiente: tenemos un dos servidores, Alice y Bob, y queremos que Alice guarde backups de Bob. Pero Alice y Bob estan en distintas redes y lo único que los conecta es Internet, con lo cual cosas como Samba quedan descartadas. Originalmente lo que se me ocurrió fue escribir un pequeño script en Perl que hiciera archivos tar.bz2 incrementales todos los días, cada domingo un tar.bz2 total y que Bob los enviara por ftp a Alice. Pero esto es una chapuza, fijense el nivel de vaguería, con tal de no tener que aprenderme los comandos de rsync preferí escribir un script en Perl… las cosas que uno hace. Así que me puse las pilas y esto es lo que salió: usando llaves conseguimos que Alice pueda acceder por SSH a Bob y usando rsync sacamos un snapshot el primero domingo de cada mes, luego snapshots incrementales contra el del dia anterior y cada domingo hacemos un snapshot incremental contra el snapshot original del primer domingo. Si, ya se que suena rebuscado y complicado, pero ya verán como es una buena idea.

Configurar acceso con llaves por SSH

Esto fué altamente frustrante, pero es una tontería. Primero generamos una llave publica y privada en Alice

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
c3:de:3c:46:d2:dd:87:34:ec:63:ed:09:c5:55:07:c9 root@alice

Dejamos todo por defecto y usamos una passphrase vacía, esto es importante porque sino nos la pedirá cada vez que intentemos usar la llave y así no se puede automatizar (que yo sepa). Abrimos /root/.ssh/id_rsa.pub, copiamos la cadena y la pegamos en /root/.ssh/authorized_keys en Bob. Ahora en Bob configuramos sshd, en Gentoo el archivo de configuración se encuentra en /etc/ssh/sshd_config. (Atención: no confundir con ssh_config, este último es para el cliente, sshd_config es para el servidor). Estas son las directrizes a tener en cuenta:

PermitRootLogin no
AuthorizedKeysFile     .ssh/authorized_keys

Y dejando el resto comentado funciona, pero como todo el mundo tiene SSH configurado distinto es cuestión de ir probando y ver que funciona, sin embargo hay dos cosas a tener en cuenta.

PermitRootLogin no te permite acceder directamente a la cuenta root, pero al usar llaves esto no le afecta. Es decir, sin usar llaves no podremos conectarnos como root, sino que tendremos que acceder con una cuenta normal y luego elevar privilegios con su, pero usando llaves podemos acceder como root directamente. Sin embargo no podemos tener root en DenyUsers porque eso sí que no funciona.

La directriz de Protocol es confusa, este HOWTO usa el protocolo 1 ya que guardamos la llave en authorized_keys, si la guardamos en authorized_keys2 debería usar cualquier protocol, pero esto no lo he probado y no se como va.

Reiniciamos el servidor SSH en Bob e intentamos acceder manualmente desde Alice a Bob para ver si funciona

# ssh root@bob
Last login: Fri Oct  6 17:06:25 2006 from **************.*****.co.uk
[root@bob root]#

Usando rsync

Ahora que Alice puede acceder a Bob sin contraseñas pasamos a la parte de hacer los backups.

# rsync -v -u -a --delete --rsh=ssh --stats bob://misc /backup
receiving file list ... done
misc/
misc/prueba.txt

Number of files: 2
Number of files transferred: 1
Total file size: 6 bytes
Total transferred file size: 6 bytes
Literal data: 6 bytes
Matched data: 0 bytes
File list size: 57
Total bytes sent: 32
Total bytes received: 119

sent 32 bytes  received 119 bytes  60.40 bytes/sec
total size is 6  speedup is 0.04
  • -v = verbose
  • -u = update
  • -a = archive
  • –delete = borra en Alice los archivos que hayan sido borrados en Bob, veremos más adelante que esto no es necesario
  • –rsh=ssh = especifica que queremos usar ssh para conectarnos
  • –stats = nos muestra las estadísticas tan simpáticas

Especificamos la fuente y luego el destino, lo que hace el ejemplo es hacer una copia de /misc en Bob y la pone en /backup en Alice. Sin embargo esto compara /backup con /misc y luego copia los archivos que hayan cambiado, esto no nos sirve para hacer backups incrementales. rsync tiene un parametro llamado --compare-dest que nos permite decirle a rsync que copie a /backup los archivos que hayan cambiado en /misc pero comparando con otra carpeta en Alice. Esto es altamente confuso, asi que pongo un ejemplo:

Usando la estructura que expliqué al principo tenemos un árbol tal que:

backups
  monthly-06-08-06
  weekly-13-08-06
  weekly-20-08-06
  weekly-27-08-06
  monthly-03-09-06
  weekly-10-09-06
  weekly-17-09-06
  weekly-24-09-06
  monthly-01-10-06
  weekly-08-10-06
  weekly-15-10-06
  weekly-22-10-06
  weekly-29-10-06

El método es el siguiente, cada primer domingo de mes hacemos un snapshot (los monthly-DD-MM-YY), luego cada domingo de ese mes hacemos otro snapshot incremental (weekly-DD-MM-YY) comparando con el monthly y luego cada día hacemos un snapshot incremental comparando con el del último domingo, estos últimos los he omitido porque sino esto se pone confuso, pero el método es igual que el de la semana.

Cada primer domingo de mes hacemos

rsync -vua --delete --rsh=ssh --stats bob://desde /backups/monthly-01-10-06

y luego cada siguiente domingo hacemos

# rsync -vua --delete --rsh=ssh --stats \
> --compare-dest=/backups/monthly-01-10-06 \
> bob://desde /backups/weekly-08-10-06

Antes dije que la opción de --delete no sirve, como estamos haciendo un backup incremental /backup/weekly-08-10-06 estará vacio antes de empezar, con lo cual no hay nada para borrar.

Digamos que el disco duro de Bob decide que ya esta cansado de girar y decide expirar, lo re-emplazamos por uno nuevo y restauramos todos los archivos de la siguiente manera:

Primero copiamos el último snapshot mensual, luego copiamos encima el último snapshot semanal y luego copiamos todos los snapshots diarios desde ese último domingo. La razon de hacer snapshots semanales es para evitar que si el disco duro muere a fin de mes tengamos que copiar casi 30 snapshots diarios. De esta manera solo tenemos que copiar seis snapshots diarios, un semanal y un mensual como máximo.

Y bueno, ahí lo tenemos, lo único que falta es escribir algún script en bash o PHP para que lo automatice. La idea es guardar los últimos tres meses, con lo cual hay que ir borrando los meses antiguos.

Recomiendo leerse man rsync, rsync tiene muchas opciones interesantes.

Espero que esto le sirva a alguien, si hay sugerencias o correcciones hagan uso de los comentarios :-P