Compilación de módulos de Linux como externos

Puede ocurrir que a nuestro Linux le falte algún módulo que si esté integrado con el núcleo a nivel de código fuente, pero que nuestra distribución no lo incluya compilado. Es el caso del Linux de Debian para la NSLU2; no incluye los módulos del subsistema de infrarrojos IrDA.

Una solución es compilar todo el núcleo a nuestro gusto. Pero también podemos compilar únicamente los módulos extras que necesitemos. En Debian y con el subsistema IrDA podríamos hacerlo de la siguiente manera:

Partimos del sistema con Debian instalado y los paquetes necesarios para realizar una compilación, como gcc, make y compañía. Utilizamos como shell bash. Entonces, lo 1º que hacemos es instalar las fuentes de linux, en este caso linux-source-2.6.18 y extraer su contenido a un directorio de trabajo:

$ su
# apt-get install linux-source-2.6.18
# exit
$ mkdir src
$ cd src
$ tar jxvf /usr/src/linux-source-2.6.18.tar.bz2
$ cd linux-source-2.6.18/


Al árbol de Linux recién extraído le damos la configuración de nuestro sistema y añadimos la de los módulos adicionales que queremos incluir, en este caso los de IrDA. Estos están dentro de la opción 'Networking'. Todo lo que necesitemos lo activamos dejándolo con la marca 'M' o '*' según proceda. También guardamos en la variable de entorno CONFIG_PATH el path del fichero de configuración resultante.

$ cp /boot/config-`uname -r` .config
$ make menuconfig
$ export CONFIG_PATH=$PWD


Creamos el siguiente Makefile y lo grabamos con nombre Makefile.alt:

include $(CONFIG_PATH)/.config
include ./Makefile
export

KVERSION = $(shell uname -r)

all:
    make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules

install:
    make -C /lib/modules/$(KVERSION)/build M=$(PWD) \
    modules_install

clean:
    make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean


¡Ojo! el espaciado previo a cada make en ese fichero debe ser un tabulador, como en todo Makefile.

Entonces copiamos el Makefile.alt al directorio del módulo a compilar y lanzamos la compilación. Por último instalamos los módulos compilados. Solo se compilarán e instalarán los módulos que hayamos marcado con el make menuconfig:

$ cp Makefile.alt net/irda/
$ cd net/irda/
$ make -f Makefile.alt
$ su
# make -f Makefile.alt install
# exit


Y eso es todo. El último paso lo podemos repetir en tantos subdirectorios como sea necesario. Por ejemplo, para tener los drivers específicos de los dispositivos de infrarrojos deberíamos lanzar el make también en drivers/net/irda.

No he encontrado un método más ortodoxo para hacer esto. Al menos de esta manera se utilizan los Makefile y configuración propios de nuestro núcleo, con lo que nos aseguramos de que los resultados sean coherentes. También es un método bastante sencillo que no requiere tocar ningún fichero del los fuentes de Linux. Espero resulte útil.

El puerto de infrarrojos no funciona en Ubuntu 8.10

El puerto de infrarrojos ha dejado de funcionar en mi portátil Thinkpad Z60m desde que actualicé a Ubuntu 8.10 "Intrepid Ibex". Intenté configurarlo también en el X30, pero nada. Resulta que el problema es un 'bug' en el 'kernel' o núcleo de 'Intrepid': el 2.6.27. Si se arranca con los núcleos de la 8.04 (la serie 2.6.24), funciona bien. La siguiente versión del núcleo, la 2.6.28, también arregla el problema. De modo que la solución es instalarse ese nuevo núcleo, arrancar con las versiones anteriores o esperar que se aplique ese parche al núcleo de 'Intrepid Ibex'.

Una vez que se tiene ese problema solucionado, hacer funcionar el puerto de infrarrojos en un Thinkpad es solo cuestión de instalar el paquete 'irda-utils'. Si se quiere entrar un poco más en las tripas, estos dos enlaces son muy útiles:

• Linux-IrDA quick tutorial.
• Using IrDA infrared devices - Community Ubuntu Documentation.

Sincronización y copia de seguridad con Unison

Si se trabaja con dos ordenadores o más, el tema de 'que archivo está donde' es un verdadero lío. Para resolver este problema está muy bien la herramienta de sincronización Unison. Permite mantener dos copias de la misma colección de archivos y directorios y replicar entre las dos los cambios que se hagan en cualquiera de ellas.

Entonces, con dos ordenadores la idea es:

1. Tener un tercer espacio de almacenamiento accesible para ambas máquinas. Un servidor de discos, tipo NFS o samba, o un simple disco USB, valen. Lo llamaremos unidad de sincronización.
   


2. Instalar Unison en las dos máquinas con las que trabajamos.


3. Configurar Unison en la primera de modo que se replique nuestro conjunto de ficheros de trabajo a la unidad de sincronización.
   


4. Ejecutar Unison para que se realice la réplica. Si tenemos muchos datos, las primeras réplicas son largas. Pero las siguientes, por ser un proceso incremental, van mucho más rápidas.
   


5. Configurar Unison en la segunda máquina. Lo normal es que en esta segunda máquina tengamos un entorno de trabajo muy parecido a la primera, y la misma forma de acceder a la unidad de sincronización; así que esta configuración será igual a la realizada en la primera máquina.


6. Ejecutar Unison para sincronizar el conjunto de trabajo de la segunda máquina con lo replicado por la primera a la unidad de sincronización.


7. Si la segunda máquina ha añadido modificaciones a la unidad de sincronización, habría que volver a sincronizar la primera máquina con dicha unidad.

Ya está, tenemos las dos máquinas con el mismo conjunto de archivos y directorios. A partir de este punto solo nos queda ser un poco disciplinados y lanzar Unison al principio y al final de cada sesión de trabajo. Así siempre tendremos lo mismo no importa que ordenador usemos.

Además, la replicación nos da mayor seguridad pues en realidad tenemos como resultado colateral tres copias de seguridad. Es cierto que el procedimiento descrito no crea un 'backup' incremental y con almacenamiento en lugares separados, como mandan los cánones. Pero si da un grado mayor de protección contra la pérdida de ficheros e información.

En mi caso, los 2 ordenadores con los que trabajo son dos portátiles Thinkpad, un Z60m y un X30. La unidad de sincronización la tengo en un pequeño servidor NSLU2 de LinkSys accesible por red Ethernet o WiFi. Se podría trabajar contra este servidor por NFS, pero a Unsion la afecta bastante la velocidad de acceso a disco. Es más eficaz tener Unsion instalado también en el servidor y que ambas instancias de Unison se comuniquen por ssh. De modo que en la NSLU2 tengo instalado GNU/Debian y los paquetes de unison y openssh-server. No hace falta instalar ni configurar nada más. Solo en los clientes hay que tener los ficheros de configuración de Unison; por ejemplo:

# Preferencias de Unison
auto = true
root = /home/usuario
root = ssh://usuario@nslu2//home/usuario

# Directorios a sincronizar
path = trabajo/codigo
path = trabajo/documentos
path = varios
path = .evolution
path = .bash_profile
path = .bashrc
path = .emacs
path = .emacs-places
path = .xemacs
path = .xemacs-options
path = .java
path = .java.policy

# A ignorar
ignore = Path .java/deployment/cache/*
ignore = Path .evolution/mail/imap/*
ignore = Name {_java*.O}
ignore = Name {.metadata}
ignore = Name {_obj}

# Log
logfile = /home/usuario/.unison/sync.log


Este fichero se guardaría en ~/.unison/nslu2.prf y para lanzar la réplica solo habría que ejecutar:

$ unison-gtk nslu2

Por supuesto, en el manual de Unison se puede encontrar más ayuda.