MySQL nos permite hacer “dumps” de una base de datos que básicamente es una copia de la base de datos pero en un script SQL listo para ejecutar. Cuando tenemos distintas versiones de MySQL es común obtener errores como este al intentar restaurar un ‘backup’:

ERROR 1064 at line XX: You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'ENGINE=MyISAM DEFAULT CHARSET=latin1' at line 8

Para evitar esto es necesario indicar al mysqldump que queremos crear un script SQL compatible con versiones anteriores. Por ejemplo, para hacer un backup en MySQL 5 que sea compatible con MySQL 4 ejecutamos mysqldump así:

¡Es todo! Espero les sea de utilidad.

¡Hola a todos! Hace un par de días perdí la partición donde tenía mi /home. Afortunadamente pude recuperar el 98% de los archivos que necesitaba. Es decir, en realidad no me interesaba recuperar imágenes, música, etc… lo único importante era recuperar los archivos PHP con los que había estado trabajando.

Aclaro esto puesto que esta entrada se va a enfocar en la configuración manual de Foremost, un programa para hacer carving, de tal manera que rescatemos solamente aquello que realmente nos interesa. Existen otros programas, pero este fue el que realmente me ayudó en esos momentos de pánico.

¿Cómo funciona? Foremost trabaja con imágenes generadas con dd o particiones directamente, y se basa en el análisis de encabezados y footers de los archivos para ‘extraer’ lo que se pueda salvar.

Dicho esto, tienes dos opciones:

• Si tienes otra partición con suficiente espacio para almacenar un backup de la partición a ser tratada, puedes usar el comando dd y luego trabajar sobre esa imagen. En esta entrada se explica con más detalle cómo hacer esto.
• Si no tienes espacio (tal como me ocurrió a mi), puedes trabajar directamente sobre la partición (i.e. el archivo /dev/sdaX ó /dev/hdbX, etc.). Solo ten en mente que NO deberías montar dicha partición, al menos no en modo de lectura-escritura.

Instalación de Foremost

La instalación es bastante sencilla ya que Foremost se incluye en prácticamente todos los repositorios de cualquier distribución. Así que puedes usar tu gestor de paquetes preferido. Siendo tan sencilla la instalación por repositorios, solo me queda mostrar la instalación manual que es incluso más sencilla… descargamos la última versión de Foremost (1.5.6 al momento de escribir esta entrada), descomprimimos, compilamos e instalamos:

Ejemplo básico de uso de Foremost

El siguiente comando de ejemplo es un de los tantos cientos de miles que te encontrarás en la red… no me enfocaré mucho en este aspecto porque ya se encuentra muy bien documentado:

Básicamente le estamos diciendo al Foremost que busque archivos de tipo PDF en el archivo de imagen (creado con dd) imagen.iso y que los guarde en pdfs-recuperados. Lo único que nos interesa recalcar en este punto es que Foremost tiene un set de archivos predefinidos de los cuales conoce su header y footer (como los PDFs en este caso); este set se compone de los archivos más comunes (imágenes  y videos en diferentes formatos, archivos de office, zips, etc.) Pero… ¿qué pasa con otro tipo de archivos menos comunes? Tranquilo, ya vamos para allá

Ejemplo de configuración del Foremost

Foremost puede ser configurado mediante un archivo (por defecto: /etc/foremost.conf) de tal manera que no tengamos que especificar el tipo de archivo a buscar y, lo que es mejor, podemos definir nuestros propios tipos de archivos. En nuestro ejemplo, te meterás en mis zapatos, te imaginarás que has perdido el trabajo de tres días y que tu objetivo es rescatar unos cuantos archivos de PHP.

Entonces… ¿por donde comenzar? Bien… lo primero es echar un vistazo al archivo /etc/foremost.conf en donde puedes encontrar patrones de búsqueda para diferentes tipos de archivo (de hecho, son las que usa Foremost cuando usamos el flag -t). La sintáxis de estos patrones es sencilla y consta de una sola línea; esta línea tiene los siguientes parámetros separados por espacios o tabulaciones:

• Extensión del archivo… ¿debo explicar esto?
• Definir si se debe hacer distinción entre mayúsculas y minúsculas al buscar el header y footer del archivo. Pon ‘y’ si deseas que sea case-sensitive o ‘n’ en caso contrario.
• Tamaño máximo del archivo.
• Encabezado: lo que se debe buscar en los encabezados de los archivos; puede ser especificado en texto plano o, mejor aún, en hexadecimal.
• Footer (opcional): lo que se debe buscar al final de los archivos; puede ser especificado en texto plano o, mejor aún, en hexadecimal.

Por ejemplo, este es uno de los que se encuentra configurados por defecto en el Foremost:

jpg y 20000000 \xff\xd8\xff\xe1 \xff\xd9

Básicamente busca archivos con extensión .jpg y con un tamaño máximo de 20000000 bytes. Además especifica uno de los posibles encabezados que un archivo tipo JPEG puede tener (\xff\xd8\xff\xe1) y su footer (\xff\xd9).

Como puedes ver, el encabezado y el footer pueden ser especificados en hexadecimal. Esto es bastante útil ya que en muchos casos no necesitamos simples archivos de texto sino que podríamos querer recuperar uno binario. En cualquier caso, es recomendable usar hexadecimal… pero ¿cómo se qué debo poner? Bien… recuerda que tu misión es recuperar los archivos PHP, así que… ¿qué tal si creamos uno para ver cómo se ve en hexadecimal?

Creamos entonces un archivo con el siguiente contenido y lo guardamos como test.php:

<?php
if($meLoTire){
	echo "o_O mode-panic:on";
}
?>

Ahora debemos abrir este archivo con algún editor hexadecimal. Si usas Gnome, Ghex es una buena opción (sino, también)… lo instalas desde los repositorios y con él abres el archivo que acabas de crear… este lucirá así:

¡Ahora ya podemos configurar Foremost como expertos, puesto que ya sabemos qué hexadecimales poner! Cada caracter del archivo que creamos equivale a un valor en hexadecimal y nos interesa enfocarnos en la representación hexadecimal de “<?php” puesto que así comienzan los archivos en los que estamos interesados.

Así que para este caso, los hexadecimales son 3C, 3F, 70, 68 y 70. Por lo tanto podemos crear un nuevo patrón dentro de /etc/foremost.conf que luzca algo así:

php y 100000 \x3C\x3F\x70\x68\x70

Si queremos ser más precisos podemos especificar el footer:

php y 100000 \x3c\x3f\x70\x68\x70 \7d\0a\3f\x3e

Fíjate que he definido un footer bastante concreto que hará que Foremost busque archivos que finalicen con un ‘}’ seguido de un ‘Enter’ (retorno de carro) y finalmente con “?>”. Una vez hayamos terminado de configurar los patrones con los que queramos iniciar la búsqueda, guardamos y cerramos el archivo.

Puesto que es el archivo por defecto no es necesario especificarlo al momento de ejecutar Foremost. Esto por supuesto implica que puedes crear un archivo con patrones en cualquier otro lado, y en tales casos debes referencialo con el flag -c. ¡Que comience el carving!

Como puedes ver, no especificamos ningún tipo  de archivo así que Foremost se enfocará en aquellos configurados en el archivo .conf. Además, en este caso estamos especificando directamente la partición. Esto podría llevar un rato, así que tienes tiempo de leer algo entretenido ¿qué tal esta bonita guía sobre Vi? ¿o esta otra sobre un hermoso Gentoo/BSD?

Una vez Foremost haya terminado su trabajo… el tuyo apenas comienza. Aunque Foremost es un excelente programa, los resultados no pueden ser 100% confiables (¿hay algo que lo sea?). Y para empeorar las cosas, Foremost NO recupera los nombres de los archivos. En vez de ello, crea una secuencia de archivos numéricos con la extensión; cosas como 8392383874.php ó 239492782.php ¿chévere, no?

Todo parece que pasaremos un buen rato jugando con nuestro querido amigo GREP; y es que este maravilloso comando puede ser realmente útil en estos casos. Así que aquí van algunos comandos que te podrían servir:

• grep busqueda changos.ext
  Busca la cadena ‘busqueda’ dentro del archivo changos.ext
• ¿qué tal una búsqueda en todos los archivos? Esto podría servir para nuestro caso de los PHP:
  cat *.php | grep -l cosa_a_buscar
• ¿y si queremos buscar un string en varios archivos que se encuentran en diferentes directorios? Este comando es de los que más uso a diario:
  find /ruta/ -exec grep -l cosa_a_buscar {} \;

Cosas por considerar

• Existe una gran probabilidad que los datos recuperados no estén del todo bien formados. Por ejemplo, podrían tener “basura” dentro. Esto es posible de corregir en archivos de texto, ya que solo necesitas un editor decente y un par de minutos para “ver qué te sirve”.
• Si los archivos recuperados tienen basura dentro, es mejor usar editores de texto en consola que no se quejan tanto al momento de editarlos. Gedit simplemente no los abre.
• Algunas veces los archivos quedan fragmentados; esto es, en un archivo recuperado queda una parte de lo que buscas, y en otro queda el restante. Por esto, es bastante útil que uses herramientas como Meld (excelente por cierto).  Considera este ejemplo de la vida real: en el archivo blablaa.php tenía parte inicial del archivo mientras que en blebelbel.php tenía el resto:

Esto es difícil de notar ‘a ojo’, por lo que puedo decir que Meld me salvó el trasero una vez más (y de paso se ganó una donación). Así, combinando el trabajo de Foremost y la ayuda de Meld pude recuperar prácticamente todo lo que necesitaba.

Pero, te repito, si fuesen archivos binarios los que quieres rescatar la cosa sería mucho más difícil. En este caso, ‘la basura’ se puede identificar fácilmente dentro del archivo, y de la misma manera se puede eliminar. En una archivo binario sin embargo es un poco más difícil.

Otros buenos programas con propósitos similares

• TestDisk (aka, PhotoRec)
• Scalpel
• Magic Rescue
• Sleuth Kit y Autopsy
• Sleuthkit

En esta entrada abordaremos un tema bastante interesante: cómo correr un programa en Java como servicio en Windows o demonio en UNIX/Linux. Puesto que el API de Java no proporciona nada para estos casos, utiliza

remos una librería llamada Java Service Wrapper. Dicha librería nos ofrece una serie de scripts y binarios preparados para diferentes sistemas operativos y arquitecturas, que nos permitirán correr nuestros programas como un servicio; además ofrece diferentes versiones: Profesional, Estándar y Comunity. En este caso usaremos la versión Comunity que es libre y gratuita.

La mejor manera de aprender a usar dicha librería es con un pequeño laboratorio, así que he preparado uno en donde explico la integración más simple que existe con Java Service Wrapper (existen 4 métodos; unos más avanzados que otros). La integración sencilla que he escogido nos permitirá ejecutar como servicio una aplicación que ya esté creada (probablemente ya empaquetada en un .jar) y a la que no podemos o es difícil hacerle modificaciones. Esta es la manera más sencilla de hacerlo, sin embargo tiene una desventaja: al detener el servicio se envía directamente un System.exit() a la JVM por lo que la aplicación no se cerrará limpiamente.

Si quieres integrar tu aplicación de una manera más segura y estás en la capacidad de prepararla para ello, podrías intentar la integración avanzada en la que utilizas el API de Java Service Wrapper para implementar métodos de inicio, pausa y detención del servicio [Para este caso utilizaremos una aplicación de ejemplo que recibe un archivo como parámetro y escribe en él información sobre la memoria del sistema, cada 60 segundos. He escogido este ejemplo porque posee varios aspectos interesantes: requiere de librerías externas (tanto JARs como librerías nativas [.so, dll, etc.]) y recibe parámetros.

Puedes descargar la aplicación de ejemplo de haciendo clic aquí. Si la ejecutáramos de manera convencional veríamos algo de este tipo:

Como puedes ver se trata de una aplicación de consola común y corriente. La aplicación consta básicamente de:

• El ejecutable servicio.jar ubicado en el directorio bin/
• La librería sigar.jar en el directorio lib/
• Las librerías específicas de cada arquitectura de sigar en lib/

Pasos para la integración

Lo primero es descargar el paquete de Java Service Wrapper y descomprimirlo. Supondremos que el directorio donde se encuentra Java Service Wrapper es $RUTA_JSW y que el directorio de la aplicación que  vamos a convertir en servicio es $RUTA_APP.

1. Copiamos los siguentes archivos al directorio bin de nuestra aplicación de ejemplo…

UNIX/Linux

El archivo $RUTA_JSW/bin/wrapper podría no existir; por lo tanto lo que debes copiar es el archivo wrapper-xxx específico para tu plataforma. Por ejemplo, en este caso estoy usando Gentoo Linux de 64bits por lo tanto copiaré el archivo $RUTA_JSW/bin/wrapper-linux-x86-64.

Windows

2. Renombramos algunos archivos…

UNIX/Linux…

Ahora debes renombrar el script sh.script.in con el nombre de la aplicación con la que haremos la integración y darle privilegios de ejecución. En este casó se llama simplemente “servicio”:

Windows

Ahora debes renombrar los archivos .bat  para que concuerden con el nombre de la aplicación con la que haremos la integración. En este casó se llama simplemente “servicio” (lo puedes hacer usando el explorador si no te gusta usar la consola, pero a mi me daría pena):

3. editar archivo de configuración

Editamos el archivo wrapper.conf y lo dejamos en el directorio $RUTA_APP/conf/. El archivo para este ejemplo tendrá el siguiente contenido (importante! lee la explicación si usas Windows):

# Comando de Java
wrapper.java.command=java
# Clase que ejecutara el Wrapper
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
# Librerias necesarias para ejecutar el programa
wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=servicio.jar
# Java Library Path (ubicacion de las librerias wrapper.dll o wrapper.so)
wrapper.java.library.path.1=../lib
# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
wrapper.java.additional.auto_bits=TRUE
# Parametros del programa
wrapper.app.parameter.1=net.casidiablo.servicio.Servicio
wrapper.app.parameter.2=/tmp/log
#********************************************************************
# Wrapper General Properties
#********************************************************************
# Allow for the use of non-contiguous numbered properties
wrapper.ignore_sequence_gaps=TRUE
# Title to use when running as a console
wrapper.console.title=servicio
#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# Name of the service
wrapper.name=jgossip
# Display name of the service
wrapper.displayname=Servicio
# Description of the service
wrapper.description=Monitor de memoria
# Mode in which the service is installed. AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START
# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false

Explicación del archivo de configuración:

• wrapper.java.command=java es el comando para ejecutar java. En este caso es simplemente java porque estoy en Linux y además tengo configurado correctamente el path. En Windows podría ser algo como: c:\archivos de programa\java\jdk1.6\bin\java.exe
• wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp indica el archivo a ejecutar es la clase WrapperSimpleApp que se usa en la integración sencilla. Esta clase envoltorio es la que permite ejecutar la aplicación como servicio.
• wrapper.java.classpath.1=../lib/wrapper.jar
wrapper.java.classpath.2=servicio.jar indican las rutas o archivos del classpath.
• wrapper.java.library.path.1=../lib indica el directorio donde se encuentran las librerías a usar.
• wrapper.app.parameter.1=net.casidiablo.servicio.Servicio
wrapper.app.parameter.2=/tmp/log estos son los parámetros que se pasarán al programa. Importante: como estamos haciendo la integración simple, el primer parámetro debe ser la clase que contiene el método main de nuestra aplicación.
• wrapper.name=jgossip esta opción es para Windows y define el nombre del servicio en el sistema.
• wrapper.ntservice.starttype=AUTO_START si estás en windows, define si el servicio quedará configurado para iniciar automáticamente.

4. Probar/Instalar el servicio…

Ahora veremos cómo podemos probar la aplicación para asegurarnos que ha quedado bien configurada antes de proceder con la instalación.

UNIX/Linux

Ejecutamos el script ’servicio’ que configuramos en el paso 1 y 2 con el parámetro console:

Deberías ver algo como:

Lo detienes presionando Ctrl+C. Ahora, si queremos probarlo como demonio basta con ejecutar los comandos típicos de un demonio en UNIX/Linux:

Para instalarlo basta con crear un enlace simbólico del script en el directorio /etc/init.d y añadirlo al listado de servicios a iniciar; por ejemplo:

Windows

Para instalarlo en Windows basta con ejecutar el archivo InstallServicio-NT.bat. Puedes verificar que fue instalado correctamente accediendo a la consola de administración de servicios de NT (ejecutas el comando services.msc):

Fuentes y descargas

Aunque en esta entrada no explico cómo hacer la integración avanzada, he preparado un ejemplo completo que puedes descargar en el listado de abajo.

• Puedes encontrar más documentación en la página oficial del proyecto
• Descargar el laboratorio de esta entrada
• Descargar el código fuente del laboratorio
• Descargar código fuente y laboratorio de la integración avanzada

En este pequeño manual explicare la manera de instalar Gentoo de una forma sencilla, simple, ilustrada y rápida, este proceso incluye instalación de Gentoo para x86 y AMD (32bits y 64bits), a su vez, puede también tomarse este manual como una opción alternativa a los manuales Oficiales de Gentoo…

Descargar [licencia cc]

Página del autor

Antes que nada, una definición de prompt:

Se llama prompt al carácter o conjunto de caracteres que se muestran en una línea de comandos para indicar que está a la espera de órdenes. Éste puede variar dependiendo del intérprete de comandos y suele ser configurable (extraído de la Wikipedia).

Normalmente no lo vemos como algo muy importante, pero leyendo este artículo en Make Tech Easier he reflexionado un poco acerca de este aspecto, y he hecho un listado de los prompts que me parecieron más útiles:

1. Cambiar el color del prompt dependiendo del resultado del comando ejecutado

Este es de los que más me ha gustado: si ejecutas bien un comando, el prompt queda en su color original (en este caso verde); pero si te equivocas al tipearlo entonces queda en rojo. Además tiene una característica bastante interesante: te muestra el número dentro del historial que será asignado al comando que ejecutes. El resultado es el siguiente:

Para usarlo, ejecutas esto o lo pones en tu archivo ~/.bashrc para hacerlo permanente:

PROMPT_COMMAND='PS1="\[\033[0;33m\][\!]\`if [[ \$? = "0" ]]; then echo "\\[\\033[1\\\;32m\\]"; else echo "\\[\\033[1\\\;31m\\]"; fi\`[\u:\`if [[ `pwd|wc -c|tr -d " "` > 18 ]]; then echo "\\W"; else echo "\\w"; fi\`]\$\[\033[0m\] "; echo -ne "\033]0;`hostname -s`:`pwd`\007"'

2. Mostrar una carita feliz si se ejecuta un comando correctamente

Este puede sonar algo infantil pero me parece bastante interesante. Funciona igual que el de arriba y el resultado es el siguiente:

PS1="\`if [ \$? = 0 ]; then echo \[\e[33m\]^_^\[\e[0m\]; else echo \[\e[31m\]O_O\[\e[0m\]; fi\` \[\033[01;32m\]\u:\[\033[01;34m\]\w \$\[\033[00m\] "

3. Mostrar bastante información en el prompt

El siguiente prompt es bastante grande y se encuentra distribuido en 3 líneas. Muestra la fecha y hora actual, el usuario, el nombre del equipo, la terminal con la que se está trabajando, el directorio en donde estamos, la cantidad de archivos en el directorio y el espacio que ocupan. Se ve así:

PS1="\n\[\033[35m\]\$(/bin/date)\n\[\033[32m\]\w\n\[\033[1;31m\]\u@\h: \[\033[1;34m\]\$(/usr/bin/tty | /bin/sed -e 's:/dev/::'): \[\033[1;36m\]\$(/bin/ls -1 | /usr/bin/wc -l | /bin/sed 's: ::g') files \[\033[1;33m\]\$(/bin/ls -lah | /bin/grep -m 1 total | /bin/sed 's/total //')b\[\033[0m\] $ \[\033[0m\]"

4. Mostrar la cantidad de procesos corriendo en background

Este es otro bastante interesante ya que te muestra aparte de lo normal: el número en el historial del comando a ejecutar, y la cantidad de procesos que se encuentren corriendo en background (aquellos ejecutados de la forma comando &). Se ve así:

PS1='\[\e[1;32m\]\u@\H:\[\e[m\] \[\e[1;37m\]\w\[\e[m\]\n\[\e[1;33m\]hist:\! \[\e[0;33m\] \[\e[1;31m\]jobs:\j \$\[\e[m\] '

5. Mostrar información de los archivos y procesos en background

Esta combina cosas de la 3 y la 4: muestra cantidad de archivos y espacio que ocupan, además de la cantidad de procesos corriendo en background. El resultado es este:

PS1="\n\[\e[30;1m\]\[\016\]\[\017\](\[\e[34;1m\]\u@\h\[\e[30;1m\])-(\[\e[34;1m\]\j\[\e[30;1m\])-(\[\e[34;1m\]\@ \d\[\e[30;1m\])->\[\e[30;1m\]\n\[\016\]\[\017\](\[\e[32;1m\]\w\[\e[30;1m\])-(\[\e[32;1m\]\$(/bin/ls -1 | /usr/bin/wc -l | /bin/sed 's: ::g') files, \$(/bin/ls -lah | /bin/grep -m 1 total | /bin/sed 's/total //')b\[\e[30;1m\])--> \[\e[0m\]"

¿se te ocurre algún otro?

Actualización: he creado un ZIP con los prompts dentro ya que hay usuarios que, por culpa del navegador, no pueden verlos completos (cosas del resaltador de sintaxis):

Descargar

Siempre olvido cómo generar salida coloreada en la consola, y por lo tanto pierdo tiempo buscando en Internet. Así que, aprovechando que tengo fresco dicho tema, mejor dejo un listado y las instrucciones con el ánimo de que sea útil para alguien (y para mi, por supuesto).

• Negro 0;30
• Gris oscuro 1;30
• Azul 0;34
• Azul resaltado 1;34
• Verde 0;32
• Verde resaltado 1;32
• Cian 0;36
• Cyan resaltado 1;36
• Rojo 0;31
• Rojo resaltado 1;31
• Púrpura 0;35
• Púrpura resaltado 1;35
• Café 0;33
• Amarillo 1;33
• Gris 0;37
• Blanco 1;37

Ejemplos…

Si lo vas a probar usando el comando echo, debes ejecutarlo con el parámetro -e:

echo -e 'Esto es \e[0;31mrojo\e[0m y esto es \e[1;34mazul resaltado\e[0m'

Resultado: 

echo -e 'Así se escribe \e[1;34mG\e[0m\e[1;31mo\e[0m\e[1;33mo\e[0m\e[1;34mg\e[0m\e[1;32ml\e[0m\e[1;31me\e[0m'

Resultado:

Como puedes observar, se trata de poner lo que quieras colorear entre los caracteres de escape \e[CODIGOm y \e[0m.

Ya hace bastante tiempo desde la última vez que usé Ubuntu, por lo cual aprovecho para poner un tip que aprendí. Se trata de configurar Ubuntu para añadir una opción a los menús contextuales de Nautilus que nos permite montar imágenes ISO, CUE, BIN, etc. Y para ello usaremos fuesiso y nautilus-actions.

Primero instalamos el software necesario y nos unimos al grupo fuse:

Para ello basta con ejecutar este par de comandos:

Debes cambiar nombreusuario por el nombre de tu usuario. Luego descargas el script userisomount.sh al directorio /usr/local/bin y le cambias los permisos:

Ahora descargas los esquemas MOUNTING y UNMOUNTING del Nautilus Actions.

Abre Configuración de Acciones de Nautilus (Sistema->Preferencias->Configuración de Acciones de Nautilus) e importa los dos archivos .schema. Luego guarda y cierra Nautilus Actions, y reinicia Nautilus (alt+F2 y ejecutas esto):

Ahora deberías ser capaz de montar y desmontar imágenes de CD con un simple clic.

En este pequeño tip vamos a aprender a instalar paquetes en Gentoo, que no estén dentro de los repositorio oficial de portage. Lo primero por supuesto es contar con ebuild bien formado; en este caso vamos a trabajar con el ebuild de un programa llamado nautilus-actions  [Los ebuild de Portage deben vivir en algún lugar de nuestro sistema; sin embargo, ponerlos en el mismo directorio en donde Portage los guarda por defecto (/usr/portage), no es una buena idea – estos serán eliminados después de la próxima sincronización. Por lo tanto debemos crear un directorio con la misma estructura; a esos tipos de directorios se les llama overlay.

Este how-to está basado en el artículo The Kernel Newbie Corner: Your First Loadable Kernel Module escrito por Rob Day en Linux.com. En él se enseñan las bases de la programación de módulos para el kernel de Linux. Este primer artículo pretende ilustrar de manera clara los conceptos básicos y espero que, a medida que Rob vaya escribiendo más artículos, pueda ir traduciéndolos para ofrecer este excelente contenido en español. Además, funciona para cualquier distro, aunque en este caso lo hice todo sobre Gentoo. Sin más, ¡vamos al grano!

¿Es necesario tener privilegios de root?

Mientras desarrollamos el módulo, no. Pero al momento de cargar el módulo necesitaremos privilegios administrativos. Por supuesto, es recomendable que el desarrollo lo hagamos con un usuario normal, y solo al final usemos un usuario root para cargar o remover los módulos.

Prerrequisitos

Antes de comenzar es necesario saber/tener algunas cosas:

• La versión del kernel con la que vamos a trabajar (usualmente la que estamos corriendo). Esto lo hacemos con el comando uname -r:
  $ uname -r
  2.6.29-gentoo-r5
• El uso de herramientas de desarrollo, como gcc, binutils, etc.
• Tener instalados las utilidades para trabajar con módulos (insmod, rmmod, etc.), el cual se encuentra en el paquete module-init-tools.
• El código del kernel de Linux, de tal manera que puedas compilar tu módulo contra este.

¿Para qué el código del kernel?

Esto es realmente importante, así que echaremos un vistazo un poco más profundo. Cuando compilamos un módulo para Linux es necesario tener el código fuente de algunas partes del kernel, puesto que muchas instrucciones de preprocesador usadas no se encuentran en los headers estándar de desarrollo. En vez de ello, se encuentran en los headers de kernel.

Podrías simplemente descargar el código del kernel directamente de la página oficial, aunque lo más sencillo es instalar el paquete que corresponda a la versión del kernel que estemos ejecutando. Por lo general, este tipo de paquetes instala el código en /usr/src o /usr/src/kernels. Por ejemplo, en Fedora el paquete que debes instalar se llama kernel-dev, mientras que en Gentoo es gentoo-sources.

Una vez tengas el código instalado, es necesario saber exactamente en donde se encuentra, de tal manera que podamos referenciarlo al momento de compilar el módulo. Podrías revisar eso manualmente o, mejor aún, buscar el enlace simbólico hacia el kernel, que por lo general se encuentra en /lib/modules:

El enlace simbólico que buscamos es build, y como puedes ver en el ejemplo, apunta a la raíz del código del kernel. Esto significa que, cada vez que quieras hacer referencia al kernel en el momento de compilar el módulo, basta con usar dicho enlace.

“Hola, kernel!”

Bien, es hora de crear nuestro primer módulo. Sin más rodeos, el código sería el siguiente:

/* El nombre del archivo es 'hola.c'. */
#include <linux/module.h>      // para todos los modulos
#include <linux/init.h>        // para las macros entry/exit
#include <linux/kernel.h>      // para usar la macro printk
#include <asm/current.h>       // informacion del proceso (solo por diversion)
#include <linux/sched.h>       // para usar la estructura "task_struct"
static int hola(void)
{
     printk(KERN_INFO "Hola, el modulo esta siendo cargado.\n");
     printk(KERN_INFO "El user space del proceso es '%s'\n", current->comm);
     printk(KERN_INFO "El PID es  %i\n", current->pid);
     return 0;       // para indicar que todo ha salido bien
}
static void adios(void)
{
     printk(KERN_INFO "Chao, el modulo esta siendo removido.\n");
}
module_init(hola);     // lo que se debe llamar al cargar un modulo
module_exit(adios);    // lo que se debe llamar al remover un modulo

MODULE_AUTHOR("Robert P. J. Day");
MODULE_AUTHOR("Cristian Castiblanco [solo lo puse en castellano]");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_DESCRIPTION("Aqui puedes poner una descripcion de tu modulo");

Algunas observaciones acerca del código de arriba:

• Técnicamente, no es necesario imprimir cosas cada vez que se carga o remueve un módulo (con printk). Pero puesto que es nuestro primer módulo, y aún no hace nada especial, es más divertido si lo dejamos así.
• Es necesario hacer que la función de inicio retorne 0, si queremos indicar que la carga fue satisfactoria.
• No, no es necesario poner una coma después de indicar el nivel de logs (KERN_INFO). Es un error común hacerlo.

Eso es todo… ¡vamos a compilarlo!

El archivo Makefile

Este es el archivo Makefile que necesitaremos:

ifeq ($(KERNELRELEASE),)  

KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)  

.PHONY: build clean

build:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules  

clean:
	rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c
else  

$(info Building with KERNELRELEASE = ${KERNELRELEASE})
obj-m :=    hola.o

endif

Como has de saber, los archivos Makefile indican las reglas necesarias para compilar código. En este caso, explicándolo a groso modo, lo que hace el Makefile es detectar que aún nos encontramos en el directorio de desarrollo de nuestro módulo, y por lo tanto se dirige al directorio del kernel, compila el módulo desde ahí y se devuelve. Para probarlo basta con ejecutar el comando make:

Examinar el módulo

Una vez compiles el módulo obtendrás un archivo con extensión .ko. Si quieres echarle un ojo a dicho archivo, puedes usar el comando modinfo así:

$ sudo modinfo hola.ko
filename:       hola.ko
description:    Aqui puedes poner una descripcion de tu modulo
license:        Dual BSD/GPL
author:         Cristian Castiblanco [solo lo puse en castellano ]
author:         Robert P. J. Day
depends:
vermagic:       2.6.29-gentoo-r5 SMP mod_unload CORE2

En Gentoo es necesario ejecutarlo con privilegios; en otras distros puedes ejecutarlo normalmente.

Cargar o remover el módulo

Llego la hora de cargar nuestro módulo. Para ello, como comenté anteriormente, es necesario poseer privilegios administrativos. Al grano:

¿Y donde está lo que imprimimos con printk? Bien, no es común imprimir en consola cosas mientras un módulo es cargado o removido; en este caso, la salida va a dar al archivo de logs principal de Linux (/var/log/messages); puedes ver la salida con el comando dmesg o directamente en dicho archivo:

Conclusión

Estas son apenas las bases que deberíamos tener para comenzar con la construcción de un módulo para el kernel de Linux. Es de valiosa ayuda jugar un poco con este ejemplo, de tal manera que podamos estar seguros que todo irá bien cuando hagamos algo un poco más complejo.

Descargar código fuente del ejemplo

Hola amigos… he grabado un pequeño vídeo en donde enseño cómo ejecutar varios sistemas operativos REALES, es decir, que no son virtuales, al mismo tiempo usando VirtualBox. Por ejemplo, si tienes instalado Windows XP, Ubuntu y Fedora, y en cada uno tienes aplicaciones que usas a diario, podrías ejecutar Windows XP desde Ubuntu sin necesidad de tener que reiniciar el equipo.

Esto tiene una gran ventaja frente al típico entorno en el cual tienes máquinas virtuales instaladas ya que, cuando realmente quieras usar el otro sistema operativo, lo ejecutas directamente en tu máquina sin las limitaciones de RAM o aceleración gráfica. Es más o menos lo que explicaba en esta entrada, en donde lo hacia con Windows XP. Pero puesto que algunos han tenido problemas con eso, y otros más me han pedido algo de información más detallada, mejor dejar todo registrado en este vídeo.

Como siempre lo he subido en Blip.tv, Youtube y Vimeo. El vídeo es completamente libre, puedes darle el uso que desees; si deseas el vídeo original para cualquier propósito me contactan por correo.