En esta ocasión vamos a aprender usar el System Tray desde una aplicación hecha en Java. El System Tray o área de notificaciones, es el espacio en el escritorio en donde ‘residen’ aplicaciones que el sistema está ejecutando, pero que no tienen en foco de lo que estamos haciendo.

Antes se usaban librerías nativas + JNI para lograr esto, pero desde hace un tiempo se incluyeron en el API de Java 6 las clases SystemTray y TrayIcon (dentro del paquete java.awt) lo cual nos facilita mucho las cosas.

0. Entendiendo las clases SystemTray y TrayIcon + Prerrequisitos

Antes que nada, debes tener instalada una versión reciente del JDK6. La clase java.awt.SystemTray representa el System Tray del escritorio. Para manipular dicha clase es necesario obtener un objeto estático de esta usando el método SystemTray.getSystemTray() (es decir, no es posible crear instancias de dicha clase). Además, es necesario verificar que el uso de esta clase sea soportada en el sistema donde se ejecuta. Esto lo hacemos usando el método estático SystemTray.isSupported(). Si no hay soporte, este método retornará false. Si haces un llamado al método getSystemTray y tu sistema no está soportado, se lanzará la excepción java.lang.UnsupportedOperationException.

La instancia de SystemTray contiene uno o más TrayIcons, los cuales son añadidos usando el método add(java.awt.TrayIcon), y son eliminados con el método remove(java.awt.TrayIcon).

1. Ejemplo de uso

import java.awt.*;
import java.awt.event.*;
public class EjemploSystemTray {
    public EjemploSystemTray() {
        //se declara el objeto tipo icono
        final TrayIcon iconoSystemTray;
        //se verifica que el SystemTray sea soportado
        if (SystemTray.isSupported()) {
            //se obtiene una instancia estática de la clase SystemTray
            SystemTray tray = SystemTray.getSystemTray();
            //esta es la imagen de icono
            Image imagenIcono = Toolkit.getDefaultToolkit().getImage("icono.png");
            //este listener nos permite capturar cualquier tipo de evento
            //que se haga con el mouse sobre el icono
            MouseListener mouseListener = new MouseListener() {
                public void mouseClicked(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse clicked!");
                }
                public void mouseEntered(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse entered!");
                }
                public void mouseExited(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse exited!");
                }
                public void mousePressed(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse pressed!");
                }
                public void mouseReleased(MouseEvent e) {
                    System.out.println("Icono del System Tray - Mouse released!");
                }
            };
            //este listener se asociara con un item del menu contextual
            //que aparece al hacer click derecho sobre el icono
            ActionListener escuchadorSalir = new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    System.out.println("Saliendo...");
                    System.exit(0);
                }
            };
            //menu que aparece al hacer click derecho
            PopupMenu popup = new PopupMenu();
            MenuItem item = new MenuItem("Exit");
            item.addActionListener(escuchadorSalir);
            popup.add(item);
            //iniciamos el objeto TrayIcon
            iconoSystemTray = new TrayIcon(imagenIcono, "Prueba System Tray", popup);
            //este tipo de listener captura el doble click sobre el icono
            ActionListener accionMostrarMensaje = new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    iconoSystemTray.displayMessage("Titulo mensaje",
                            "Este es el contenido del mensaje!",
                            TrayIcon.MessageType.INFO);
                }
            };

            iconoSystemTray.setImageAutoSize(true);
            iconoSystemTray.addActionListener(accionMostrarMensaje);
            iconoSystemTray.addMouseListener(mouseListener);

            //se debe capturar una excepción en caso que falle la adicion de un icono
            try {
                tray.add(iconoSystemTray);
            } catch (AWTException e) {
                System.err.println("No es posible agregar el icono al System Tray");
            }
        }
        else
            System.err.println("Tu sistema no soporta el System Tray");
    }
    public static void main(String[] args) {
        new EjemploSystemTray();
    }
}

Así se ve en Linux (usando Gnome) y en Windows7:

Del ejemplo anterior veamos las líneas más importantes:

• Línea 8: verificamos que tengamos soporte.
• Línea 10: obtenemos una instancia de la clase SystemTray.
• Línea 46: creamos el icono que vamos a añadir.
• Línea 50: invocación del método displayMessage para mostrar globos de notificación.
• Línea 62: añadimos el icono al systray.

2. ¿Cómo usar Swing en vez de AWT?

Si te fijaste bien, el SystemTray es una clase que pertenece al paquete AWT… por alguna razón no se tuvo en cuenta Swing en todo esto. Es por ello que no podemos usar directamente JPopupMenu en vez de PopupMenu. Además, JPopupMenu tampoco es una subclase de PopupMenu por lo cual no podemos usar polimorfismo

Afortunadamente hay algunos trucos para hacerlo funcionar con Swing que nos proporciona varias ventajas: la apariencia del menú sería igual en cualquier sistema operativo, podemos añadir iconos a los items, etc.

El truco más sencillo del cual tengo conocimiento lo leí en el blog de Artem Ananiev, en un post llamado Using JPopupMenu in TrayIcon. He preparado entonces otro ejemplo sencillo en donde se muestra cómo lograr esto:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class EjemploSystemTraySwing {
    public EjemploSystemTraySwing() {
        //se declara el objeto tipo icono
        final TrayIcon iconoSystemTray;
        //se verifica que el SystemTray sea soportado
        if (SystemTray.isSupported()) {
            //se obtiene una instancia estática de la clase SystemTray
            SystemTray tray = SystemTray.getSystemTray();
            //esta es la imagen de icono
            Image imagenIcono = Toolkit.getDefaultToolkit().getImage("icono.png");
            //este listener se asociara con un item del menu contextual
            //que aparece al hacer click derecho sobre el icono
            ActionListener escuchadorSalir = new ActionListener() {
                public void actionPerformed(ActionEvent e) {
                    System.out.println("Saliendo...");
                    System.exit(0);
                }
            };
            //menu que aparece al hacer click derecho
            final JPopupMenu popup = new JPopupMenu();

            //aniadir un menu con icono (swing)
            JMenuItem carita = new JMenuItem("casidiablo.net",  new ImageIcon("carita.png"));
            popup.add(carita);
            popup.addSeparator();

            //aniadir el item de salir
            JMenuItem item = new JMenuItem("Exit", new ImageIcon("salir.png"));
            item.addActionListener(escuchadorSalir);
            popup.add(item);
            //iniciamos el objeto TrayIcon
            iconoSystemTray = new TrayIcon(imagenIcono, "Prueba System Tray", null);
            iconoSystemTray.setImageAutoSize(true);
            //iconoSystemTray.addMouseListener(mouseListener);
            iconoSystemTray.addMouseListener(new MouseAdapter() {
                public void mouseReleased(MouseEvent e) {
                    if (e.isPopupTrigger()) {
                        popup.setLocation(e.getX(), e.getY()-50);
                        popup.setInvoker(popup);
                        popup.setVisible(true);
                    }
                }
            });
            //se debe capturar una excepción en caso que falle la adicion de un icono
            try {
                tray.add(iconoSystemTray);
            } catch (AWTException e) {
                System.err.println("No es posible agregar el icono al System Tray");
            }
        }
        else
            System.err.println("Tu sistema no soporta el System Tray");
    }
    public static void main(String[] args) {
        new EjemploSystemTraySwing();
    }
}

El resultado es algo como lo que aparece en la primera imagen que acompaña esta entrada. Importante tener en cuenta las líneas resaltadas (40 a 44) que es donde se hace la magia Como siempre, puedes descargar el código y probar tú mismo:

Descargar ZIP con ejemplos

¡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 esta guía aprenderemos a obtener información de los recursos sistema en Java, usando la librería Sigar. Los datos que podremos extraer son los siguientes:

• Información de la CPU.
• Espacio en disco disponible.
• Cantidad de espacio que consume un directorio en específico.
• Cantidad de memoria RAM disponible y en uso.
• Información de red (dirección IP, nombre de la NIC, puertos abiertos, tablas de enrutamiento, etc.)
• Información de los procesos que se están ejecutando en el sistema.
• Asignación de variables de entorno.
• Uptime, o cantidad de tiempo que el equipo ha estado encendido.
• Nombre y versión del sistema operativo.
• Usuarios logueados actualmente.

Resaltadas en negrita está la información en la que nos concentraremos en el ejemplo. Pero antes aclaremos un poco que es Sigar: el API de Sigar nos proporciona una serie de métodos que nos permiten obtener información del sistema operativo; consta de una librería de Java (.jar) y otras librerías nativas específicas para cada sistema operativo soportado (libsigar-amd64-linux.so, para Linux de 64 bits o sigar-x86-winnt.dll para Windows de 32 bits, por poner un ejemplo).

Teniendo esto en cuenta, para hacer funcionar dicha API en una de nuestras aplicaciones, bastaría con tener el archivo .jar y la librería específica de nuestro sistema operativo. En el desarrollo del ejemplo se usará Eclipse y, aunque se explicará cómo añadir las librerías en el proyecto, se da por conocido el funcionamiento del flag --classpath de los comandos javac y java (obligatorio si no se usa ningún IDE).

El resultado…

Siempre pongo primero el resultado ya que nos aclara la visión de hacia donde vamos, y de paso saber si lo que está aquí es lo que buscamos. Esta es la salida del programa en mi Gentoo Linux:

====Informacion del sistema====
Descripcion del SO	Gentoo 2.1.6
Nombre del SO		Linux
Arquitectura del SO	x86_64
Version del SO		2.6.31-gentoo
Nivel de parches	unknown
Fabricante		Gentoo
Version SO		2.1.6
Encendido durante:	6:15

==== Informacion de la CPU ====
Fabricante:		Intel
Modelo			Core(TM)2 Duo CPU     T5750  @ 2.00GHz
Mhz			1994
Total CPUs		2
CPUs fisiscas		1
Nucleos por CPU		2
Tamanio cache		2048

Consumo de CPU 0	22.0%
Consumo de CPU 1	2.0%
Consumo total de CPU	6.0%

====Informacion del sistema de archivos====

dispos.|total|usado|disponible|%uso|dir|tipo

/dev/root|24042944|10698228|12123376|47%|/|ext4
/dev/sda1|175457764|155825380|10719932|94%|/home|ext3

====Informacion de la memoria====
Cantidad de memoria RAM: 3968MB
Total: 4056984
Usada: 2307076
Disponible: 1749908
Memoria SWAP total: 1052248
Memoria SWAP usada: 0
Memoria SWAP libre: 1052248

Descargar Sigar

Puedes descargar Sigar de la página oficial: http://support.hyperic.com/display/SIGAR/Home que incluye además ejemplos para Java, Perl, C, Python, Ruby, y más. Puedes además descargar el código fuente que se encuentra licenciado bajo la GPL2.

Creación del proyecto en Eclipse

Voy a usar este ejemplo para además enseñar a manipular librerías externas en Eclipse; si lo que te interesa es conocer el código, puedes saltarte a dicha sección directamente.

Creamos un proyecto en Eclipse llamado InfoSistema:

Ahora creamos una carpeta dentro del proyecto llamada lib, en donde guardaremos las librerías de Sigar (.jar, .so, .dll, etc.):

Ahora descomprimimos el archivo que descargamos de Sigar, y copiamos los archivos que se encuentran en la carpeta sigar-bin/lib a la carpeta lib de nuestro proyecto. En mi caso la copia la hice con este comando:

Cabe resaltar que bastaría con copiar el archivo llamado sigar.jar y la librería del sistema donde vamos a correr nuestro programa (libsigar-amd64-linux.so en mi caso).

Una vez hecha la copia, hacemos clic en la raiz del proyecto en Eclipse y presionamos F5 para actualizar el árbol de ficheros; de esta manera Eclipse sabrá de los nuevos archivos que hemos copiado. Y lo que haremos a continuación será enlazar la librería sigar.jar a nuestro proyecto, para lo cual hacemos clic derecho en el mismo, Build Path -> Configure Build Path…

En la ventana que aparece, seleccionaremos la pestaña Libraries y hacemos clic en el botón Add JARs… Seleccionamos el archivo sigar.jar y hacemos clic en OK:

Ahora que la librería se encuentra añadida, podemos utilizar el API que Sigar nos ofrece. ¡Pasemos entonces al código!

Información del sistema…

La siguiente clase nos permite obtener información del sistema operativo, como el nombre, la versión, la arquitectura, etc. Creamos una nueva clase llamada InfoSO con el siguiente código:

import org.hyperic.sigar.OperatingSystem;
import org.hyperic.sigar.Sigar;
import org.hyperic.sigar.SigarException;

public class InfoSO {
	private Sigar sigar = new Sigar();
	public void imprimirInfo() {
		OperatingSystem sys = OperatingSystem.getInstance();
		System.out.println("Descripcion del SO\t" + sys.getDescription());
		System.out.println("Nombre del SO\t\t" + sys.getName());
		System.out.println("Arquitectura del SO\t" + sys.getArch());
		System.out.println("Version del SO\t\t" + sys.getVersion());
		System.out.println("Nivel de parches\t" + sys.getPatchLevel());
		System.out.println("Fabricante\t\t" + sys.getVendor());
		System.out.println("Version SO\t\t" + sys.getVendorVersion());
		try {
			imprimirUptime();
		} catch (SigarException e) {
			e.printStackTrace();
		}
	}
	public void imprimirUptime() throws SigarException {
		double uptime = sigar.getUptime().getUptime();
		String resultado = "";
		int dias = (int) uptime / (60 * 60 * 24);
		int minutos, horas;
		if (dias != 0)
			resultado += dias + " " + ((dias > 1) ? "dias" : "dia") + ", ";
		minutos = (int) uptime / 60;
		horas = minutos / 60;
		horas %= 24;
		minutos %= 60;
		if (horas != 0)
			resultado += horas + ":" + (minutos < 10 ? "0" + minutos : minutos);
		else
			resultado += minutos + " min";
		System.out.println("Encendido durante:\t" + resultado);
	}
}

Aspectos importantes:

• La clase que nos proporciona los métodos para recuperar información del sistema operativo es OperatingSystem.
• Con los métodos getName y getDescription obtenemos el nombre del sistema operativo y descripción (por ejemplo: nombre = Linux; descripción = Gentoo 2.1.6).
• El método getUptime de la clase Sigar nos permite conocer cuanto tiempo ha estado prendido el equipo analizado.

Información de la CPU…

La siguiente clase nos permitirá conocer el modelo del procesador, sus capacidades, la cantidad de núcleos y el uso de los mismos, etc. Creamos una nueva clase llamada InfoCPU con el siguiente código:

import org.hyperic.sigar.CpuInfo;
import org.hyperic.sigar.CpuPerc;
import org.hyperic.sigar.Sigar;
import org.hyperic.sigar.SigarException;

public class InfoCPU {
	private Sigar sigar;

	public void imprimirInfoCPU() {
		sigar = new Sigar();
		CpuInfo[] infos = null;
		CpuPerc[] cpus = null;
		try {
			infos = sigar.getCpuInfoList();
			cpus = sigar.getCpuPercList();
		} catch (SigarException e) {
			e.printStackTrace();
		}

		CpuInfo info = infos[0];
		long tamanioCache = info.getCacheSize();
		System.out.println("Fabricante:\t\t" + info.getVendor());
		System.out.println("Modelo\t\t\t" + info.getModel());
		System.out.println("Mhz\t\t\t" + info.getMhz());
		System.out.println("Total CPUs\t\t" + info.getTotalCores());
		if ((info.getTotalCores() != info.getTotalSockets())
				|| (info.getCoresPerSocket() > info.getTotalCores())) {
			System.out.println("CPUs fisiscas\t\t" + info.getTotalSockets());
			System.out
					.println("Nucleos por CPU\t\t" + info.getCoresPerSocket());
		}

		if (tamanioCache != Sigar.FIELD_NOTIMPL)
			System.out.println("Tamanio cache\t\t" + tamanioCache);
		System.out.println("");

		for (int i = 0; i < cpus.length; i++)
			System.out.println("Consumo de CPU " + i + "\t"
					+ CpuPerc.format(cpus[i].getUser()));

		try {
			System.out.println("Consumo total de CPU\t"
					+ CpuPerc.format(sigar.getCpuPerc().getUser()));
		} catch (SigarException e) {
			e.printStackTrace();
		}
	}
}

Aspectos importantes:

• Se deben usar objetos de CpuInfo y CpuPerc que proporcionan los métodos para recuperar información del procesador. Dichos objetos se crean a partir de un objeto principal de tipo Sigar.
• Para extraer información acerca del procesador usamos los métodos de la clase CpuInfo (por ejemplo getVendor o getModel).
• Los datos específicos de cada núcleo de nuestro procesador se extraen con los métodos de la clase CpuPerc (getUser para obtener el uso de un núcleo, por ejemplo).

Información del sistema de archivos…

La siguiente clase nos permite obtener información del sistema de archivos: unidades montadas, espacio en disco, tipo de sistema de archivos, etc. Creamos una nueva clase llamada InfoSistemaArchivos con el siguiente código:

import org.hyperic.sigar.Sigar;
import org.hyperic.sigar.SigarException;
import org.hyperic.sigar.FileSystem;
import org.hyperic.sigar.FileSystemUsage;
import org.hyperic.sigar.NfsFileSystem;
import org.hyperic.sigar.SigarProxy;
import org.hyperic.sigar.SigarProxyCache;

public class InfoSistemaArchivos {
	private SigarProxy proxy;
	private Sigar sigar;

	public InfoSistemaArchivos() {
		sigar = new Sigar();
		proxy = SigarProxyCache.newInstance(sigar);
	}

	public void imprimirInfo() throws SigarException {
		FileSystem[] listaSistemaArchivos = proxy.getFileSystemList();
		System.out.println("\ndispos.|total|usado|disponible|%uso|dir|tipo\n");
		for (int i = 0; i < listaSistemaArchivos.length; i++)
			imprimirSistemaArchivos(listaSistemaArchivos[i]);
	}

	public void imprimirSistemaArchivos(FileSystem sistemaArchivos)
			throws SigarException {
		long usado, disponible, total, porcentaje;

		try {
			FileSystemUsage uso;
			if (sistemaArchivos instanceof NfsFileSystem) {
				NfsFileSystem nfs = (NfsFileSystem) sistemaArchivos;
				if (!nfs.ping()) {
					System.out.println(nfs.getUnreachableMessage());
					return;
				}
			}
			uso = sigar.getFileSystemUsage(sistemaArchivos.getDirName());

			usado = uso.getTotal() - uso.getFree();
			disponible = uso.getAvail();
			total = uso.getTotal();

			porcentaje = (long) (uso.getUsePercent() * 100);
		} catch (SigarException e) {
			// por ejemplo, si en al procesar D:\ en windows falla
			// con "Device not ready"
			usado = disponible = total = porcentaje = 0;
		}

		String porcentajeUso;
		if (porcentaje == 0)
			porcentajeUso = "-";
		else
			porcentajeUso = porcentaje + "%";

		System.out.print(sistemaArchivos.getDevName());
		System.out.print("|" + total);
		System.out.print("|" + usado);
		System.out.print("|" + disponible);
		System.out.print("|" + porcentajeUso);
		System.out.print("|" + sistemaArchivos.getDirName());
		System.out.println("|" + sistemaArchivos.getSysTypeName());
	}
}

Aspectos importantes:

• La clase que nos proporciona los métodos para obtener información de una unidad en específico es FileSystem.
• El método getDevName nos devuelve el nombre del dispositivo referenciado por el objeto de la clase FileSystem.
• Los métodos getTotal y getAvail devuelven un long que representa el espacio total del dispositivo y espacio disponible, respectivamente.
• Para conocer el tipo de sistema de archivos (ext4, ntfs, fat, btrfs, etc.) utilizamos el método getSysTypeName.

Información de la memoria…

La siguiente clase nos permite conocer la cantidad de memoria RAM que tiene el equipo, así como la que se está usando actualmente (tanto memoria física como virtual, aka, swap). Creamos una nueva clase llamada InfoMemoria con el siguiente código:

import org.hyperic.sigar.Mem;
import org.hyperic.sigar.Sigar;
import org.hyperic.sigar.Swap;
import org.hyperic.sigar.SigarException;

public class InfoMemoria {
	private Sigar sigar = new Sigar();
	public void imprimirInfo() throws SigarException {
		Mem memoria = sigar.getMem();
		Swap intercambio = sigar.getSwap();

		System.out.println("Cantidad de memoria RAM: "+ memoria.getRam() + "MB");

		System.out.println("Total: "+enBytes(memoria.getTotal()));
		System.out.println("Usada: "+enBytes(memoria.getUsed()));
		System.out.println("Disponible: "+enBytes(memoria.getFree()));

		System.out.println("Memoria SWAP total: "+enBytes(intercambio.getTotal()));
		System.out.println("Memoria SWAP usada: "+enBytes(intercambio.getUsed()));
		System.out.println("Memoria SWAP libre: "+enBytes(intercambio.getFree()));

	}
	private Long enBytes(long valor) {
		return new Long(valor / 1024);
	}
}

Aspectos importantes:

• La clase Mem nos proporciona métodos para obtener información de la memoria del sistema.
• La clase Swap hace lo mismo que Mem, pero para la memoria virtual.
• Los métodos getTotal y getUsed nos devuelven un long que representa (en bits) la cantidad de memoria del equipo y lo que está usando, respectivamente.

La clase main…

El main de nuestro proyecto estará contenido en la clase InfoSistema:

import org.hyperic.sigar.SigarException;
public class InfoSistema {
	public static void main(String[] args) {
		try {
			System.out.println("====Informacion del sistema====");
			new InfoSO().imprimirInfo();
			System.out.println("\n==== Informacion de la CPU ====");
			new InfoCPU().imprimirInfoCPU();
			System.out.println("\n====Informacion del sistema de archivos====");
			new InfoSistemaArchivos().imprimirInfo();
			System.out.println("\n====Informacion de la memoria====");
			new InfoMemoria().imprimirInfo();
		} catch (SigarException e) {
			e.printStackTrace();
		}
	}
}

Eso es todo, solo nos queda ejecutar el proyecto y, opcionalmente, crear un archivo .jar para ejecutar en cualquier lado.

Descargas…

• Descarga del código fuente usado en esta entrada
• Descargar librerías de Sigar de SourceForge

Contribuyendo a la excelente labor de mi amigo Cortex, vamos con este pequeño artículo.

Una de las tareas más dispendiosas a la hora de configurar el kernel es determinar qué opción/driver activar para determinado dispositivo. La idea de este artículo es dar a conocer una excelente herramienta online que nos permitirá conocer mejor nuestro sistema, y de paso saber los nombres de los drivers que podemos usar por cada dispositivo.

La página en cuestión es http://kmuto.jp/debian/hcl/ y contiene una base de datos de IDs de dispositivos PCI, que nos permite consultar información acerca de nuestros dispositivos y los drivers que los controlan.

Uso

Para usarlo debemos ejecutar el siguiente comando:

y copiamos la salida en el area de texto que aparece al entrar a http://kmuto.jp/debian/hcl/; hacemos clic en el botón Comprobar y obtendremos un listado de dispositivos vs. nombre del driver.

Por ejemplo, mi laptop tiene una ranura para insertar memorias SD; el nombre de dicho dispositivo es R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter y el driver es sdhci-pci.

Con dicha información, podemos hacer una búsqueda (presionando la tecla /) en la configuración del kernel (cuando hacemos un make menuconfig):

El resultado es la ubicación exacta de la opción que debes habilitar para tener tu dispositivo funcionando:

Eso es todo. Ahora podemos estar seguros de escoger el driver adecuado y podemos compilar nuestro kernel normalmente.

Anterior artículo…

Continuando con la serie de posts dedicados al Kernel, hoy vamos a hablar sobre las cámaras web y la herramienta sysctl.

Cámaras Web

En la actualidad, el kernel tiene muy buen soporte para las cámaras web, tanto las integradas como las externas. Basado en mi experiencia, nunca he tenido ningún problema con dispositivos de captura de video en Linux aunque me imaginó que en algún hardware habrá incompatibilidades. La ventaja es que los desarrolladores del kernel cada día trabajan por mejorarlo y desarrollando controladores para maximizar el soporte en la mayor cantidad de máquinas posibles.

Lo primero que debemos hacer es identificar la referencia del dispositivo. Si tienes un portatil y lo que buscas es hacer funcionar la cámara integrada que trae, usando el driver UVC sería suficiente:

Device Drivers  --->
     <*> Multimedia support  --->
          [*]   Video capture adapters  --->
               [*]   Autoselect pertinent encoders/decoders and other helper chips
               [*]   V4L USB devices  --->
                    <*>   USB Video Class (UVC)
                          [*]     UVC input events device support

Ahora, en caso de que la cámara sea externa debes conectarla y hacer un lsusb. Hay tantos modelos disponibles que sería difícil hacer una guía definitiva, además de que ya existe un completo HOWTO que explica esto. Lo que haré, será mostrar un ejemplo haciendo uso de una vieja cámara Genius que tengo. Si la conecto y hago un dmesg puedo ver la información del dispositivo:

Ahora lsusb:

Teniendo el ID, debemos buscar cuál es el módulo necesario para esta cámara. Aquí tienes una larga lista de IDs con su respectivo módulo. Si buscamos también en la base de datos de drivers del kernel veremos la configuración que debemos hacer y el módulo a activar. El driver en cuestión es: gspca_pac207.

<*>   GSPCA based webcams  --->
     <M>   Pixart PAC207 USB Camera Driver

Si compilaste como módulo no olvides agregarlo al inicio del sistema (si es lo que deseas). En Gentoo con OpenRC y Baselayout 2:

Para esta cámara es necesario tener instalada la librería v4l (Video 4 Linux).

Y listo. Reiniciamos con el nuevo kernel y usamos cualquier programa como cheese para comprobar que todo funciona bien.

Sysctl

A raíz de un comentario de arpunk, he decidido posponer uno de los temas que iba a tocar en este artículo y hablar sobre sysctl.

El kernel Linux es tan flexible que te permite modificar la manera en que trabaja, dinámicamente, a través del comando sysctl. Sysctl provee de una interfaz que permite examinar y cambiar cientos de parámetros en núcleos Linux y BSD. Gracias a esta herramienta podemos modificar y optimizar el kernel sin tener que recompilarlo. Los cambios son realizados inmediatamente e incluso pueden ser definidos como persistentes, de manera que continúen después de reiniciar.

Para ver los parámetros actuales del kernel en ejecución:

Con el segundo lo que hacemos es ver el valor de un determinado parámetro, en este caso vm.swappiness. Suponiendo que quisiéramos decirle al kernel que use más la memoria RAM que la swap ó habilitar el forwarding en IPv4, bastaría con cambiar el valor de estas variables:

Recuerda que las modificaciones que hagas con este comando serán temporales, y la próxima vez que reinicies el sistema se cargarán los valores por defecto. Para cambiar este comportamiento, hay que editar el archivo /etc/sysctl.conf

Básicamente eso es sysctl. El tema podría tornarse más extenso pero la idea de estos artículos, es tan sólo, recopilar conceptos en torno al kernel Linux. Para más información man sysctl.

Hasta aquí por hoy. En el próximo artículo hablaremos un poco de optimizaciones para el procesador y de otras buenas prácticas a la hora de compilar el núcleo.

Hola a todos! Otra vez yo, Cortex, que hace un buen rato no me pasaba por aquí.

Hoy me gustaría hablar sobre un tema en el que seguro todos tenemos muchas lagunas, configurar el kernel. Si alguna vez has instalado ó intentando instalar Gentoo te habrás dado cuenta que en el ritual de instalación debes de compilar tu propio núcleo, incluyendo también la configuración del mismo. Desde mi experiencia, este suele ser un punto en el que la mayoría de usuarios se quedan; es cierto que también existe genkernel, una herramienta que facilita por completo este proceso pero que también, entre otras cosas, ralentiza mucho el arranque.

Casi la totalidad de distribuciones Linux, incluyen en su sistema un kernel con soporte para la mayor cantidad de hardware posible y en el booteo hay un script que se encarga de identificar el perfil del equipo en cuestión y cargar los módulos respectivos (sonido, disco, sistemas de archivos, etc.). Este sistema me parece excelente, puesto que sobretodo al usuario nuevo le ahorra mucho trabajo a la hora de poner a funcionar su distribución, pero como dije anteriormente no es lo más óptimo, sobretodo si queremos el mejor rendimiento posible.

No pretendo con esta entrada crear una guía completa de configuración del kernel. Primero, porque mis conocimientos en este tema son limitados, o sino que lo diga Javi, que siempre le toca aguantarse mis quejas porque no me funcionan bien las cosas Y segundo, porque todos tenemos necesidades diferentes y puede que algunos necesiten soporte para determinadas cosas que otros no. Lo que sí me gustaría es hablar sobre buenas prácticas a la hora de trabajar con el núcleo y sobre problemas muy comunes que surgen cuando hacemos una configuración desde 0, como dispositivos que no funcionan, entre otras cosas. El post está abierto a cualquier aporte/mejora/correción que quieran hacer.

Brillo en pantallas LCD

Son varias las personas que alguna vez me han preguntado como pueden hacer funcionar las teclas para definir la intensidad del brillo de la pantalla. Si usas portatil, habrás notado que es una funcionalidad demasiado útil y que además es muy maluco tener que trabajar únicamente con el brillo que el laptop haya decidido definir al ser encendido.

• Lo primer es activar el controlador:

Device Drivers  --->
     Graphics Support --->
          [*] Lowlevel video output switch controls
          [*] Backlight & LCD device support  --->
               <*>   Lowlevel LCD controls
               <*>     Platform LCD controls
               -*-   Lowlevel Backlight controls
               <*>     Generic (aka Sharp Corgi) Backlight Drive
      Display device support  --->
           <*> Display panel/monitor support

• Ahora nos dirigimos a las opciones de ACPI y activamos el manejo de video:

Power management and ACPI options  --->
     [*] ACPI (Advanced Configuration and Power Interface) Support  --->
          <*>   Video

Y con esto bastaría recompilar para disfrutar del brillo

/proc/config.gz

Una opción que quizás muchos no conocen es la de poder acceder a la configuración del kernel en ejecución a través del archivo /proc/config.gz. Actívemosla y curémosnos en salud ante la pérdida del preciado .config.

General setup  --->
     <*> Kernel .config support
     [*]   Enable access to .config through /proc/config.gz

Para disponer del archivo de configuración:

Sonido como módulo

Entre los problemas más comunes en Linux está el sonido. Sobretodo si trabajamos con versiones de ALSA muy viejas ya que nos toca recurir a hacks ó pasar parámetros a la hora de cargar los módulos. Por si no está claro para alguien, ALSA (Advanced Linux Sound Architecture) a grosso modo, es el encargado de la gestión del sonido en Linux, reemplazando al obsoleto OSS. No es la única opción, pero sí la mejor en la mayoría de los casos.

Existen 3 formas de instalar ALSA:

• Desde los drivers del kernel (estáticamente)
• Desde los drivers del kernel (módulo)
• Drivers externos (alsa-drivers)

La más recomendada es la segunda. Las ventaja de compilar el sonido como módulo es que no tenemos que preocuparnos de identificar cual es el controlador apropiado para nuestra tarjeta, sino, simplemente dejar hacer su trabajo a alsaconf y usar alsamixer para definir el volumen. Aparte de que también se obtiene un mejor rendimiento.

Si quieres profundizar un poco en el tema puedes leer este artículo.

No pondré aquí las opciones que se necesitan activar en el núcleo, puesto que en la documentación de Gentoo está todo perfectamente explicado. Más bien hablemos sobre los micrófonos integrados, esos que a veces resulta tan difícil hacer funcionar.

Abrimos en una shell alsamixer y presionando la tecla Tabulador nos movemos a los dispositivos de Captura. Debemos cambiar en Input Source, Mic por Front Mic y también verificar que los dispositivos Capture y Digital no están mudos y además que tengan el volumen al 100%.

Guardamos la configuración

Ahora abrimos cualquier aplicación para captura de audio y probamos con los dispositivos disponibles a ver cual funciona. Eso es todo.

No quiero alargar más el post, de momento es suficiente. Más adelante veremos como podemos hacer funcionar las cámaras web en Linux y algunas otras cosas.

Cualquier comentario será bien recibido, ¡Hasta pronto!

Esta entrada pretende profundizar los temas aprendidos en el anterior artículo (Tu primer módulo cargable para el Linux kernel), con el fin de clarificar dudas, atar algunos cabos que dejamos sueltos y prepararnos para los siguientes artículos.

¿Puedo usar directamente el árbol del código fuente del kernel?

Sí, por supuesto. Como ya sabes, no es posible compilar un módulo cargable sin al menos parte del código fuente del kernel – esto es, la parte que contiene la infraestructura de construcción general y los archivos de cabecera esenciales. Solo por recordar, un archivo header (con extensión .h), contiene, normalmente, una declaración directa de clases, subrutinas, variables, u otros identificadores; sin la definición de estas, no es posible compilar código que las use.

En cualquier caso, es siempre útil tener una copia completa del código del kernel, y la manera más fácil de obtenerla es usando git:

Además que puedes actualizarlo fácilmente:

Nótese que, al contrario de instalar el paquete oficial de desarrollo del kernel como hicimos en el anterior artículo, usando git no es necesario tener privilegios administrativos para poner todo el código en algún lugar de tu directorio home. Además, si por alguna razón no puedes usarlo, puedes descargarte un archivo tar y funcionará igual; claro, usar git es mucho más cool

Urgando en el código fuente: examinando los archivos de cabecera (Header Files)

Recordemos que en el ejemplo del artículo anterior, nuestro código contiene referencias a archivos de cabecera del kernel:

#include <linux/module.h>      // para todos los módulos
#include <linux/init.h>        // para entrada y salida de macros
#include <linux/kernel.h>      // para los macros de prioridad de printk
#include <asm/current.h>       // procesar información, solo por diversión
#include <linux/sched.h>       // para usa la estructura task_struct

Tales referencias son siempre relativas al nivel superior del directorio include/ en el código fuente del kernel, así que un include de, por ejemplo, <linux/module.h>, se refiere al archivo de cabecera include/linux/module.h, y así sucecivamente.

Sin embargo, si miras un poco más de cerca, notarás que no hay un directorio include/asm/, lo cual es bastante fácil solucionar. Incluso si no planeas construir algo contra el código fuente que descargaste, deberías prepararlo de tal manera que refleje de una manera más precisa lo que piensas hacer con él:

Los comandos anteriores hacen bastantes cosas, aunque lo único que nos interesa en este momento es que crea algunos enlaces simbólicos en el directorio include/, que reflejan la arquitectura de nuestro sistema.

Antes de ejecutar los comandos:

Después de ejecutarlos:

Una vez que esto es hecho, los includes de preprocesador tendrán sentido, y podemos usar los nombres genéricos para referirnos al archivo de cabecera apropiado de ahora en adelante. Por supuesto, esto que hicimos no es necesario hacerlo con los paquetes oficiales de desarrollo del kernel, puesto que ya vienen preparados.

¿Es posible generar mensajes de salida con un módulo?

No, no lo es. Bueno, no realmente. Como un autor de módulos novato, es necesario que entiendas que tu módulo será ejecutado en el kernel space, no en el user space, así que debes dejar de pensar en impresiones de mensajes en la consola. Olvídate de ello. La manera canónica de generar mensajes de depuración desde tu módulo es con llamadas printk:

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);  

Corriendo el riesgo de sobre-simplificar el asunto, la salida que genera printk acabará en el archivo /var/log/messages así que, si estás insertando y removiendo tu módulo, es útil tener una terminal aparte mostrando en tiempo real todo lo que sea escrito en dicho archivo (para lo cual necesitas privilegios administrativos):

Para los más ambiciosos, es útil fijarse en la definición de los niveles de log en el archivo de cabecera <linux/kernel.h>:

#define KERN_EMERG    "<0>"  /* system is unusable                 */
#define KERN_ALERT    "<1>"  /* action must be taken immediately   */
#define KERN_CRIT     "<2>"  /* critical conditions                */
#define KERN_ERR      "<3>"  /* error conditions                   */
#define KERN_WARNING  "<4>"  /* warning conditions                 */
#define KERN_NOTICE   "<5>"  /* normal but significant condition   */
#define KERN_INFO     "<6>"  /* informational                      */
#define KERN_DEBUG    "<7>"  /* debug-level messages               */

Si algunos de ellos lucen vagamente familiares, no es de sorprenderse – son los niveles de depuración (debugging) soportados por syslog, así que eres libre de personalizar el syslog si quieres redireccionar la salida de tu módulo a donde quieras basado en los niveles de log, lo cual está más allá del objetivo de este artículo.

printk(KERN_INFO "Hola, el modulo esta siendo cargado.\n");
printk("<6>" "Hola, el modulo esta siendo cargado.\n");
printk("<6>Hola, el modulo esta siendo cargado.\n");

Aun así, es mejor hacerlo como se muestra en la primera línea. Incluso programando cosas del kernel, la estética importa.

Cargando tu módulo lleno de información

Como te diste cuenta la última vez, puedes cargar tu módulo con información bastante útil como:

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");

que puede examinarse con el comando modinfo:

$ 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

Algunas cosas útiles acerca de esta característica:

• El conjunto completo de estos macros está definido en el archivo de cabecera <linux/module.h>, en donde verás macros relacionados con firmware, tablas de dispositivos y más.
• Además de esos macros en específico, está el menos conocido macro genérico MODULE_INFO, el cual puedes usar dentro del módulo en el lugar que quieras. Curiosamente, muy pocos programadores toman ventaja de este.
• La única macro que realmente debes poner es la licencia. Si no especificas alguna de las variaciones de la licencia GPL, entonces el módulo “contaminará” el kernel, un tema que trataremos en otro artículo. El conjunto completo de licencias válidas está definido en el mismo archivo de cabecera.

Compilando contra el código fuente del kernel

Finalmente, podrías querer construir tu módulo, no contra el código instalado por el paquete de desarrollo, sino contra el código que descargaste tú mismo. Si ese es tu plan, es bastante simple.

Primero, como decíamos arriba, necesitas preparar tu código fuente para construir el módulo:

Todo lo que falta es configurar el Makefile de tal manera que compile el módulo contra nuestro código fuente. Recordemos parte del archivo Makefile del artículo anterior:

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

Lo que hace la segunda línea es asignar la ubicación del código fuente del kernel a ser usado. Para cambiar esta variable, podemos asignarle el valor deseado con este comando:

y aquí es donde comienzas a notar algunas diferencias. Asumiendo que la versión del código que descargué es 2.6.31-rc1, esto es lo que sucede en mi sistema:

Puesto que estoy compilando contra un código fuente que no concuerda con el que estoy corriendo actualmente, pierdo la tabla de símbolos actual, pero la compilación funciona.

El comando modinfo también muestra el árbol contra el cual el módulo fue compilado:

$ 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.31-rc1 SMP mod_unload 686

Ahora algunas preguntas capciosas – ¿es posible cargarlo? ¿no dará problemas por la versión? Eso depende de si el kernel que se está ejecutando fue configurado para permitir diferencias de versiones, y hay una manera rápida de comprobarlo. En mi Gentoo por ejemplo:

Mala suerte. Tal parece que el kernel no fue compilado con las opciones necesarias. Si miramos en el archivo /var/log/messages:

Por lo pronto entonces, de ahora en adelante, jugaremos un poco dentro de la seguridad que nos ofrece compilar contra el kernel que concuerda con la versión que corremos. No hay motivo para hacerlo más difícil de lo que debe ser. En el próximo artículo veremos algo acerca de las rutinas entry y exit.

Nota: de nuevo un tutorial raro, que tal vez a pocos le importa. Lo siento.

Esta receta la aprendí configurando mi Gentoo pero bien podría aplicarse a cualquier otra distribución. La idea es activar el soporte para Framebuffer, el cual permite al kernel mostrar gráficos en consolas de texto. Además sirve para otras cosas, como ejecutar servidores X sin aceleración o reproducir videos en la consola (en ASCII, por supuesto).

El tutorial tiene además un valor didáctico que me gusta, ya que vamos a tocar cosas en el Kernel, algo bastante interesante.

Ventajas

Las ventajas de hacer esto, y por lo que yo lo hice, son:

• Te proporciona una muy bonita consola (de hasta 128 colores + más de 48 líneas con 1280×800, al menos en mi laptop) cuando estás trabajando sobre las TTY (sin entornos gráficos).
• Te pone el logo de Linux mientras carga el sistema, una maravilla. Los que usen usplash se reirán de mi, pero bueno, prefiero el pingüino y saber que está pasando cuando mi sistema inicia.

Compilando el kernel con las opciones adecuadas

En este punto, he de suponer que tienes algo de experiencia con el kernel. Sino, estás de suerte porque me gusta explicar todo muy bien. Lo primero es abrir una consola y situarnos en el directorio donde tengamos las fuentes de Linux, y posteriormente ejecutamos la herramienta de configuración del Kernel:

Una vez hecho esto, debemos activar algunas opciones (dentro de Device Drivers):

(*) Graphics Support
    (*) Enable firmware EDID
    (*) Support for Frame buffer devices
        (*) VESA VGA graphics support
    (*) Console display support
        (*) Video mode selection support
        (*) Frame buffer console support
    (*) Logo Configuration
        (*) Bootup logo

Ten en cuenta que deben estar compilados dentro del kernel (*) y no como módulos (M). Una vez que hayamos configurado correctamente nuestro kernel, lo compilamos y copiamos al directorio /boot, por ejemplo:

Identificar qué resoluciones podemos usar con Framebuffer

Para identificar qué resolución es la más adecuada para nuestro equipo, lo más sencillo es instalar la herramienta hwinfo (si no la tienes ya instalada):

En Ubuntu/Debian:

En Gentoo:

En Arch:

En Fedora:

Una vez instalado, ejecutas el comando:

Lo que tienes que hacer es identificar el valor del Mode; en mi caso es 0×0361…

Configurando el GRUB

Una vez identificado el valor del Mode, no queda más que pasarle a nuestro kernel las opciones adecuadas. Abrimos con nuestro editor de texto favorito el archivo /boot/grub/menu.lst, y añadimos el parámetro vga=modo al final de la línea del kernel. Por ejemplo, en mi caso luce así:

title Gentoo
root (hd0,9)
kernel /boot/kernel root=/dev/sda10 vga=0x0361

¡Reiniciamos, y listo!

Soy un amante de Linux, y como muchos, hace tiempo soñé con una masificación de este sistema operativo. Imaginaba que cada vez más personas utilizarían software libre, y participaban en una verdadera comunidad. Y aunque Debian es mi distro favorita, he visto que Ubuntu está haciendo que ese sueño se haga latente y se acerque a la realidad.

Por tanto, en este blog hablo mucho sobre Ubuntu, me gusta recomendar software, en señar algunos tips, y escribir uno que otro mini tutorial. Todo esto pensando en ofrecer lo mejor al usuario nuevo que venga de Windows, y que espera encontrar una verdadera comunidad amigable y calorosa.

Artículos destacados

• Graba tu escritorio con VLC
• Activar usuario root en Ubuntu
• Manejar tu cuenta Gmail desde la consola
• Webmin, administra tu Linux vía web
• Unir y partir PDF
• 3 maneras de mantener seguros tus archivos
• pngcrush, optimiza tus imágenes PNG
• Partir archivos en Linux
• 10 maneras de acelerar el arranque en Linux
• 10 hábitos de productividad en Linux
• Mover directorio /home a otra partición
• Cómo ayudar a otros a migrar a Gnu/Linux
• ¿Qué es eso de Linux? ¿Porqué usar Linux?

Por supuesto, escribo mucho más acerca de Ubuntu, pero los links de arriba son los que considero más relevantes, y espero sea de ayuda.

No está de más recomendar, lo que para mi son, los tres pilares de información para Ubuntu en español:

• Ubuntips
• Be linux my friend
• UbuntuLife