Tutoriales on Marco Antonio Blanco

Nos quedamos sin Adobe Reader en Linux, ¿y ahora qué?

Wed, 22 Oct 2014 16:45:33 +0000

El pasado mes de Septiembre, Adobe nos dio la “mala” noticia de que Linux dejaba de ser una de las plataformas en las que su lector de PDF Reader tuviese soporte. Y lo digo entre comillas porque en el fondo no es tan mala noticia. De hecho, que Adobe elimine una herramienta privativa, sobrecargada y con tantos problemas de seguridad es en realidad una gran noticia para los usuarios Linux. Sobre todo si tenemos en cuenta que contamos con muy buenas alternativas libres como oKular (KDE) o Evince (GNOME).

Es cierto que ninguna de estas opciones cubren el 100% de las capacidades de Reader, como las animaciones o los modelos 3D empotrados, pero eran precisamente estas complejidades las que hacían de Reader una herramienta pesada e insegura. Aún así, hay una característica por la que sí echaríamos de menos a Reader: los formularios. Desgraciadamente, en España se realizan muchísimos trámites administrativos a través de plataformas telemáticas basadas, entre otras cosas, en documentos PDF empotrados en el navegador en los que hay que rellenar una serie de campos. Si Adobe abandona a los usuarios de Linux, ¿qué hacemos ahora para tener acceso a estos servicios públicos a los que tenemos derecho?

Afortunadamente, existe una solución basada en software libre sencilla de echar a andar. Consiste en utilizar el plugin MozPlugger para Firefox y combinarlo con Evince, que ofrece un mejor soporte de los formularios PDF que oKular, de forma que los documentos PDF aparezcan empotrados cuando así lo requiera un sitio web. Como es habitual, daré las instrucciones para Debian y derivadas, aunque son fácilmente adaptables a cualquier otra distribución Linux.

Empezamos instalando el software que necesitamos, es decir, MozPlugger y Evince. En el caso de Squeeze, Jessie y posteriores, ambos paquetes se encuentran en los repositorios oficiales:

# apt-get install mozplugger evince
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
...

Sin embargo, en el caso de Wheezy, la actual estable, no contamos con un paquete oficial, así que tendremos que descargarnos la versión para Squeeze de nuestra arquitectura e instalarla a mano, lo cual funciona sin problemas.

# dpkg -i mozplugger_1.14.1-1_amd64.deb
Seleccionando el paquete mozplugger previamente no seleccionado.
(Leyendo la base de datos ...)
Desempaquetando mozplugger (de mozplugger_1.14.1-1_amd64.deb) ...
Configurando mozplugger (1.14.1-1) ...

Una vez instalados los paquetes necesarios, procedemos a configurar mozplugger para que utilice Evince como su lector de PDF por predeterminado, que dependen de la versión de Debian que tengamos instalada.

En Jessie o posteriores editamos el fichero /etc/mozpluggerrc.d/62-documents.conf y buscamos la sección que se refiere a los documentos PDF:

application/pdf:pdf:PDF file
application/x-pdf:pdf:PDF file
text/pdf:pdf:PDF file
text/x-pdf:pdf:PDF file
 ACROREAD()
 repeat noisy swallow(Xpdf) fill needs_xembed: xpdf -g +9000+9000 "$file"
 repeat noisy swallow(okular) fill needs_xembed: okular "$file"
 repeat noisy swallow(epdfview) fill needs_xembed: epdfview "$file"
 GV()
 repeat noisy swallow(evince) fill needs_xembed: evince "$file"

Entonces insertamos en primera posición una nueva línea referente a Evince para que así se convierta en el lector PDF empotrado predeterminado:

application/pdf:pdf:PDF file
application/x-pdf:pdf:PDF file
text/pdf:pdf:PDF file
text/x-pdf:pdf:PDF file
 repeat noisy swallow(evince) fill: evince "$file"
 ACROREAD()
 repeat noisy swallow(Xpdf) fill needs_xembed: xpdf -g +9000+9000 "$file"
 repeat noisy swallow(okular) fill needs_xembed: okular "$file"
 repeat noisy swallow(epdfview) fill needs_xembed: epdfview "$file"
 GV()
 repeat noisy swallow(evince) fill needs_xembed: evince "$file"

Finalmente tenemos que ejecutar un script que traslada los cambios realizados al fichero principal de configuración en /etc/mozpluggerrc:

# /usr/sbin/update-mozpluggerrc
Purging current configuration...
Generating mozpluggerrc...
Merging /etc/mozpluggerrc.d/20-header.conf ...
Merging /etc/mozpluggerrc.d/40-global_defs.conf ...
Merging /etc/mozpluggerrc.d/60-video.conf ...
Merging /etc/mozpluggerrc.d/61-audio.conf ...
Merging /etc/mozpluggerrc.d/62-documents.conf ...
Done.

En el caso de Wheezy y Squeeze lo único que hay que hacer es editar directamente el fichero /etc/mozpluggerrc según las instrucciones anteriores.

Ahora iniciamos Firefox (si ya lo teníamos abierto será necesario cerrarlo y abrirlo de nuevo) y configuramos las opciones de visualización de PDF. En el menú de Firefox, elegimos la opción de Preferencias y seleccionamos la sección de Aplicaciones. En el cuadro de búsqueda introducimos la cadena “pdf” y elegimos “mozplugger” en el desplegable. Tras pulsar en el botón “Cerrar”, ya tendremos activo Evince como visor PDF empotrado predeterminado. Para hacer pruebas, podemos elegir cualquier documento PDF que incluya formularios.

Cambiando el lector de PDF predeterminado en Firefox

Los usuarios de otros navegadores se habrán dado cuenta que esta solución sólo funciona con Firefox y navegadores compatibles con el API de plugins de Netscape. De hecho, Chrome sustituyó su mecanismo de conexión de plugins hace unas pocas versiones, lo que impide que sus usuarios disfruten no sólo de MozPlugger, sino de otras tecnologías como Java. En este caso, la única solución posible es utilizar Firefox para esos sitios web en los que sea necesario utilizar formularios PDF empotrados.

Para finalizar debo advertir que el soporte de los formularios PDF de Evince no es perfecto y que es muy probable que tarde o temprano nos encontremos con un documento que no podamos rellenar, pero menos da una piedra. Espero que probéis esta receta y que compartáis vuestras impresiones.

Obteniendo informacion del sistema desde consola e IRC con inxi

Wed, 08 Oct 2014 10:33:55 +0000

No hace mucho publiqué una serie de artículos sobre cómo obtener información del hardware de un sistema Linux en producción sin necesidad de pararlo. Recientemente me he topado con otra herramienta que nos sirve para esta tarea: inxi, un script que recaba información completa sobre el hardware y el software más importante de un sistema y lo muestra en consola o, si así lo configuramos, a través de IRC.

La instalación de inxi es muy sencilla y en su web oficial se encuentran las instrucciones para las distribuciones Linux más populares, si no se encuentra instalado ya de serie como es el caso de Linux Mint y otras.

Para su instalación en Debian, tendremos que seguir pasos diferentes dependiendo de la versión que tengamos instalada. Si usamos Jessie o posterior, tenemos un paquete a nuestra disposición en los repositorios oficiales, por lo que bastará con el siguiente comando:

# apt-get install inxi

Sin embargo, en el caso de Wheezy (la actual versión estable), hay que descargarse el paquete e instalarlo a mano. Primero, accedemos al repositorio de inxi en Jessie y nos lo descargamos del servidor que queramos. Después, instalaremos con este comando:

# dpkg -i inxi_2.1.28-1_all.deb

La forma más sencilla y directa de utilizar inxi es invocarlo directamente sin parámetro alguno:

# inxi
CPU~Dual core AMD A6-5400K APU with Radeon HD Graphics (-MCP-) clocked at Min:1400.000Mhz Max:3600.000Mhz Kernel~3.16-0.bpo.2-amd64 x86_64 Up~16:29 Mem~1798.6/7406.1MB HDD~4000.8GB(19.8% used) Procs~190 Client~Shell inxi~2.1.28

La salida de inxi por defecto es a color, por lo que si nos resulta molesto podemos o bien cambiar el esquema de color utilizado con el parámetro -c, que admite un número de 0 a 32, donde 0 lo desactiva completamente. El otro parámetro genérico es -v, que aumenta el nivel de detalle de la salida de inxi según el valor que le indiquemos entre 0 (mínimo) y 7.

El resto de parámetros están dedicados a obtener información específica sobre componentes hardware concretos, lo que podemos consultar en el manual electrónico (man inxi) de inxi. Por ejemplo, si queremos información sin color sobre la CPU y la tarjeta gráfica:

# inxi -C -G -c0
CPU: Dual core AMD A6-5400K APU with Radeon HD Graphics (-MCP-) cache: 2048 KB 
 Clock Speeds: 1: 1900 MHz 2: 1400 MHz
Graphics: Card: Advanced Micro Devices [AMD] ATI Device 9991
 Display Server: N/A driver: N/A tty size: 177x25 Advanced Data: N/A for root out of X

En cuanto al uso de inxi a través de IRC, basta con que lo integremos con nuestro cliente IRC favorito y recibiremos la información de nuestros sistema a través suyo. En el wiki oficial del proyecto se habla de los clientes IRC más populares. Por ejemplo, para integrar inxi con Konversation en KDE4:

# ln -s /usr/local/bin/inxi /usr/share/kde4/apps/konversation/scripts/inxi

En el poco tiempo que llevo probándolo, inxi me está resultando muy útil y es más que probable que termine definitivamente formando parte de mi “caja de herramientas” de administración de sistemas. Si lo probáis, no dudéis en compartir vuestra experiencia con inxi.

Cómo resolver el bug de BASH en Debian

Wed, 01 Oct 2014 16:23:56 +0000

La noticia más destacada de la semana pasada (yo diría que de los últimos meses) es sin duda la del infame bug de BASH (también conocido como Shell Shock), que permite comprometer remotamente sistemas que tengan instalado este popular intérprete de comandos, como Linux, Unix o Mac OS. Se trata sin duda de una de las vulnerabilidades de mayor impacto en Internet de los últimos años (con el permiso de Heartbleed), tanto por su facilidad de explotación como por su propagación por la Red. Por ello, los administradores de sistemas hemos tenido que ponernos las pilas y parchear rápidamente los sistemas a nuestro cargo para mitigar las posibles consecuencias del bug. Como en Activa Sistemas tenemos a Debian como plataforma favorita, nuestros esfuerzos se han dirigido a resolver Shell Shock en dicha distribución Linux, esfuerzos que queremos compartir con nuestros lectores.

La metodología a seguir para parchear el bug es la misma independientemente de la versión de Debian de cada servidor, que consiste en instalar una versión actualizada de BASH que no contenga el bug, pero el camino para llegar a dichos paquetes actualizados sí que depende de la versión de Debian. Veamos qué hacer en cada caso:

Wheezy y posteriores: En el caso de la versión estable y las versiones en desarrollo e inestable basta con actualizar la base de datos de paquetes desde los repositorios oficiales:

# apt-get update

y, o bien actualizar todo el sistema:

# apt-get upgrade

o bien instalar sólo BASH:

# apt-get install bash

Squeeze: A la anterior versión estable se le otorgó el soporte extendido (LTS: Long Term Support) en Abril de 2014, lo que supone que recibirá actualizaciones de paquetes hasta Febrero de 2016. Esto implica que BASH tiene una actualización para Squeeze en los repositorios LTS. Por lo tanto, lo primero es añadirlos a nuestro sistema, para lo cual tenemos que incluir la siguiente línea en el fichero /etc/apt/sources.list:

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free

A continuación seguimos los pasos para Wheezy y tendremos BASH actualizado en Squeeze.

Lenny y anteriores: En el caso de que tengamos instalada en algún servidor una versión de Debian más antigua que Squeeze (por ejemplo, el típico caso de una máquina virtual instalada expresamente para dar soporte a una aplicación anticuada pero en uso), la única opción que tenemos es la de construir un backport del paquete de BASH para Wheezy. Esto consiste en descargar el paquete fuente y recompilarlo en una versión de Debian idéntica a la que tenemos en el servidor de destino.

Como se puede imaginar, esta operación no está al alcance de cualquiera, ya que implica tener experiencia en la compilación de código fuente y la construcción de paquetes de software. Por eso, hemos construido nuestros propios backports de BASH para Lenny y los hemos puesto a disposición de todo aquél interesado para que los utilicen para actualizar sus sistemas antiguos. Eso sí, los paquetes se ofrecen sin ningún tipo de garantía, por lo que recomendamos su instalación previa en un sistema de prueba antes de proceder al servidor en producción.

Al igual que en el caso de Squeeze, sólo hay que añadir el repositorio al sistema y proceder a la instalación del paquete actualizado.

Sólo queda comprobar si realmente la actualización ha surtido efecto. Para ello, ejecutamos el siguiente comando en una consola:

# env x='() { :;}; echo vulnerable' bash -c 'echo this is a test'

Si no se imprime en pantalla la palabra vulnerable, entonces hemos conseguido parchear el bug de BASH y estaremos a salvo, al menos hasta que se descubra otro ;)

Monitorix, un sencillo sistema de monitorización para servidores Linux

Fri, 11 Jul 2014 12:47:08 +0000

Hace algunos años escribí un artículo sobre la necesidad de monitorizar los sistemas informáticos a nuestro cargo, en el que comentaba que la tarea de implantar un sistema de monitorización no era tan difícil como exigente. Pues bien, existe un software que no sólo es muy fácil de instalar sino que permite elegir el nivel de exigencia que queramos tanto para nosotros como administradores como para el propio software.

El software en cuestión se llama Monitorix, lo desarrolla Jordi Sanfeliu en el lenguaje Perl, es de licencia libre y está disponible para Linux y FreeBSD. Su objetivo es ofrecer un panel de control sencillo, personalizable a través de un único fichero de configuración en texto plano (en algunas distros existe un fichero extra, como veremos más adelante), que permita realizar un detallado seguimiento mediante completas gráficas a los parámetros y servicios del sistema que más nos interesen. Monitorix no sólo nos habla del uso de la CPU, la RAM, la red o el almacenamiento local, sino que está preparado para mantenernos informados del rendimiento de servidores tan populares como Apache o MySQL. Y todo, insisto, a través de gráficas muy completas y a la vez sencillas de interpretar.

Todo el acceso a Monitorix se realiza a través de navegador web, ya que se invoca a través de un CGI que incluye su propio servidor web (se puede integrar con uno ya existente en el sistema) y que consulta las bases de datos generadas por un demonio que está periódicamente recopilando la información que nos interese.

Para ello, Monitorix utiliza bases de datos Round Robin (RRD) como backend para el almacenamiento de los datos recogidos. Esto le permite mantener un histórico del comportamiento del sistema y nos ofrece la posibilidad de consultar la información tanto en tiempo real como del periodo de tiempo que queramos.

Otra característica muy interesante de Monitorix es que se puede configurar una instancia a través de la cual accedamos a todas las demás instaladas en los sistemas monitorizados. De esta forma sólo necesitamos un panel de control para acceder a toda la información de nuestros sistemas. Para ello hay que activar en la configuración de Monitorix el modo multihost en el nodo central e indicarle cuales son los otros sistemas a monitorizar a través suyo. La activación de esta característica es muy sencilla y se detalla claramente en la FAQ del proyecto.

Antes de proceder a explicar cómo instalar Monitorix en Debian, debo aclarar que tenemos dos opciones: instalación manual e instalación mediante repositorio. Qué opción nos interesa más es algo que debemos elegir cada uno en base a nuestras circunstancias particulares, aunque por mi parte tengo claro que para hacer una prueba me quedo con la manual, mientras que para instalar definitivamente no hay nada mejor que usar un repositorio.

Instalación a mano

Empezamos comprobando cuál es la última versión disponible en http://www.monitorix.org/downloads.html y procedemos a la instalación del paquete, sustituyendo (version) por el número que hemos visto en la web de descarga.

Primero descargamos el paquete:

# wget http://www.monitorix.org/monitorix_(version)-izzy1_all.deb

A continuación instalamos software de apoyo:

# apt-get install rrdtool perl libwww-perl libmailtools-perl libmime-lite-perl librrds-perl libdbi-perl libxml-simple-perl libhttp-server-simple-perl libconfig-general-perl libio-socket-ssl-perl

Ahora instalamos el paquete descargado de Monitorix:

# dpkg -i monitorix_(version)-izzy1_all.deb

Y le decimos al sistema que resuelva cualquier depedencia incmplida que pueda haber surgido:

# apt-get -f install

Instalación mediante repositorio

En este caso comenzamos editando la lista de repositorios de nuestra Debian en /etc/apt/sources.list y añadimos el repositorio deb http://apt.izzysoft.de/ubuntu generic universe.

Después añadimos la firma de dicho repositorio importando su clave GPG al sistema:

# wget -O - http://apt.izzysoft.de/izzysoft.asc 2>/dev/null | apt-key add -

Finalmente actualizamos los repositorios e instalamos el paquete:

# apt-get update && apt-get install monitorix

Configuración y puesta en marcha

En Debian, configuramos Monitorix a través del fichero /etc/monitorix/conf.d/00-debian.conf, que sustituye la configuración presente en el fichero principal /etc/monitorix/monitorix.conf, de forma que no tengamos que tocarlo y así la actualización entre versiones sea más sencilla.

Dado que Monitorix trabaja sobre los registros del sistema, en este fichero comprobamos que sus caminos son correctos. Asimismo, en la sección <graph_enable> podemos habilitar y deshabilitar lo que queramos monitorizar. Finalmente, cada parámetro del sistema o servicio a monitorizar tiene su propia sección en la que podemos personalizar su comportamiento.

Tras cualquier cambio en la configuración, basta con reiniciar el servicio para activarlo:

# /etc/init.d/monitorix restart

El servidor web que incluye Monitorix es accesible a través del puerto 8080 (también configurable). Para acceder al recién instalado panel de control, abrimos un navegador y apuntamos a http://<IP>:8080/monitorix/.

Con esto tendremos instalado un potente sistema de monitorización, con información directa y sencilla de interpretar y con un bajo impacto en el sistema.

Espero haberos animado a probar Monitorix. A cambio espero vuestros comentarios.

Acceso SSH sin contraseña a servidores Linux

Mon, 30 Jun 2014 12:16:47 +0000

Existen numerosos escenarios en los que es necesario automatizar tareas entre dos servidores Linux, como por ejemplo cuando queremos enviar código desde un servidor de desarrollo a otro de demo a través del cuál nuestros clientes van a revisar el trabajo desarrollado hasta el momento. Para ello lo mejor es utilizar el protocolo SSH, que permite no sólo crear sesiones interactivas sino también enviar ficheros y ejecutar comandos remotamente de una forma segura frente a terceros malintencionados. Sin embargo, SSH exige algún tipo de autentificación para acceder al servidor remoto, bien mediante contraseña bien mediante certificados. Lo habitual (por sencillo) es utilizar contraseñas, lo que convertiría cada conexión en algo tedioso al tener que autentificarse cada vez. Por ello, voy a contaros cómo generar una relación de confianza entre dos máquinas Linux para que se puedan automatizar tareas a través de SSH sin el uso de contraseñas.

Lo primero que hay que hacer es que ambas máquinas cuenten con soporte SSH. Aunque sólo es necesario el servicio en la máquina remota y lo normal en las distribuciones Linux más populares es que el cliente y el servidor se encuentren en paquetes diferentes, es muy útil contar con ambos en toda máquina que caiga bajo nuestra administración, así que procederemos a instalar los dos. En Debian por ejemplo existe un metapaquete que hace eso precisamente:

# apt-get install ssh

En Linux, el servicio SSH más popular y soportado es OpenSSH, que es justo el que se acaba de instalar en ambas máquinas.

A partir de este momento, llamaremos al servidor cliente S1 y al servidor remoto S2. A continuación, accedemos a S1 como el usuario para el que queremos crear la relación de confianza (usuario1) y generamos las claves de autentificación, sin introducir una frase de paso (passphrase):

usuario1@S1:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario1/.ssh/id_rsa):
Created directory '/home/usuario1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario1/.ssh/id_rsa.
Your public key has been saved in /home/usuario1/.ssh/id_rsa.pub.
The key fingerprint is:
15:7d:0a:de:d8:a2:06:5f:4f:15:92:3b:14:1e:26:60 usuario1@S1

Ahora mediante ssh vamos a crear el directorio ~/.ssh como usuario2 en S2. El directorio puede ya existir, lo que no supone ningún problema:

usuario1@S1:~> ssh usuario2@S2 mkdir -p .ssh usuario2@S2's password:

Finalmente añadimos la nueva clave pública de usuario1 al fichero .ssh/authorized_keys (o .ssh/authorized_keys2 según la versión del servidor SSH) de usuario2 en S2 e introducimos la contraseña de usuario2 por última vez:

usuario1@S1:~> cat .ssh/id_rsa.pub | ssh usuario2@S2 'cat >> .ssh/authorized_keys'
usuario2@S2's password:

Desde este momento, ya es posible acceder a S2 como usuario2 desde S1 como usuario1 sin utilizar contraseña:

usuario1@S1:~> ssh usuario2@S2
usuario2@S2:~>

Ya podemos incorporar a nuestros scripts los comandos de SSH (y otras herramientas que hagan uso de SSH, como rsync) para que las tareas que hayamos automatizado funcionen sin interrupción por el sistema de autentificación.

Sobra decir que esto NUNCA se debe hacer para el usuario root, ya que si cae una máquina en manos malintencionadas, se produce un efecto dominó con el resto de servidores con los que tenga una relación de confianza mediante SSH sin contraseña. De hecho, NUNCA se debería tener activo el acceso a root mediante SSH. Para ello, lo mejor es utilizar certificados, que es algo que veremos en un futuro artículo.

Espero que esta receta os sea de utilidad en vuestras tareas diarias de administración.

Gestión dinámica del rendimiento de CPUs bajo Linux

Fri, 30 May 2014 11:43:57 +0000

Esta semana hemos tenido la enorme suerte de poder impartir un seminario sobre seguridad para menores en Internet en el Colegio CEU San Pablo de Sevilla. Para ilustrar de forma práctica los conocimientos adquiridos en la sesión, instalamos una pequeña red formada por portátiles de un perfil antiguo (Intel Pentium M 1,6 GHz, 512MB RAM) en los que tenemos instalado Debian Linux con el escritorio XFCE (una pequeña maravilla que saca todo el jugo a equipos poco potentes).

Aparte de utilizar un escritorio ligero, es posible obtener el máximo rendimiento posible a portátiles tan antiguos gracias al escalado dinámico de la frecuencia de la CPU, una técnica que permite equilibrar el consumo de energía frente a la frecuencia del procesador según las necesidades del usuario. En Linux, esta gestión se realiza a través de los CPU governors, unos esquemas que indican al núcleo cómo debe llevar a cabo estos ajustes. En este artículo vamos a ver cómo realizar nosotros mismos esta gestión dinámica de la frecuencia de nuestras CPUs, que podemos aplicar a cualquier tipo de sistema, no sólo en portátiles.

Como es habitual en el resto de mis artículos, la plataforma Linux de referencia es Debian. Aún así, lo que cuento en las siguientes líneas se puede hacer igual o muy parecido en otras distribuciones populares. Evidentemente, vamos a trabajar directamente con el hardware, así que sólo el superusuario tiene los privilegios necesarios para lo que vamos a ver a continuación.

En primer lugar, hay que activar el soporte de la gestión dinámica de la frecuencia de la CPU. Para ello, si no lo está ya, instalamos el software necesario:

# apt-get install cpufrequtils
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias 
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes extras:
 libcpufreq0
Se instalarán los siguientes paquetes NUEVOS:
 cpufrequtils libcpufreq0
...
Seleccionando el paquete libcpufreq0 previamente no seleccionado.
(Leyendo la base de datos ... 254034 ficheros o directorios instalados actualmente.)
Desempaquetando libcpufreq0 (de .../libcpufreq0_008-1_amd64.deb) ...
Seleccionando el paquete cpufrequtils previamente no seleccionado.
Desempaquetando cpufrequtils (de .../cpufrequtils_008-1_amd64.deb) ...
Procesando disparadores para man-db ...
Configurando libcpufreq0 (008-1) ...
Configurando cpufrequtils (008-1) ...
[ ok ] Loading cpufreq kernel modules...done (powernow-k8).
[ ok ] CPUFreq Utilities: Setting ondemand CPUFreq governor...CPU0...CPU1...done.

Como vemos en el ejemplo, la plataforma hardware que uso en el ejemplo tiene la arquitectura AMD64 y cuenta con dos procesadores (realmente es sólo uno pero con dos núcleos), que son detectados automáticamente al terminar la instalación del software.

Toda la gestión ser realiza a través del directorio /sys/devices/system/cpu/cpuX/cpufreq, donde X es el número de orden la CPU que queremos gestionar. Veamos lo que nos encontramos para el primer procesador:

# cd /sys/devices/system/cpu/cpu0/cpufreq
# ls -l
total 0
-r--r--r-- 1 root root 4096 may 30 affected_cpus
-r--r--r-- 1 root root 4096 may 30 bios_limit
-r-------- 1 root root 4096 may 30 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 may 30 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 may 30 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 may 30 cpuinfo_transition_latency
-r--r--r-- 1 root root 4096 may 30 related_cpus
-r--r--r-- 1 root root 4096 may 30 scaling_available_frequencies
-r--r--r-- 1 root root 4096 may 30 scaling_available_governors
-r--r--r-- 1 root root 4096 may 30 scaling_cur_freq
-r--r--r-- 1 root root 4096 may 30 scaling_driver
-rw-r--r-- 1 root root 4096 may 29 scaling_governor
-rw-r--r-- 1 root root 4096 may 30 scaling_max_freq
-rw-r--r-- 1 root root 4096 may 30 scaling_min_freq
-rw-r--r-- 1 root root 4096 may 30 scaling_setspeed
drwxr-xr-x 2 root root 0 may 30 stats

Se puede apreciar que, excepto stats que es un directorio, el resto de contenido son ficheros que se pueden consultar y modificar para realizar la gestión dinámica de la frecuencia. Veamos qué governors tenemos disponibles, cuál es el que está actualmente configurado y activo en este procesador y cuál es su frecuencia actual (en Hz):

# cat scaling_available_governors
userspace powersave conservative ondemand performance 

# cat scaling_governor
ondemand

# cat cpuinfo_cur_freq
1000000

Es decir, que el procesador está configurado para que modifique su frecuencia de forma dinámica según las necesidades del sistema en cada momento (el governor ondemand). Muy parecido es el governor conservative, que cambia la frecuencia de forma más gradual en vez de saltar directamente a la velocidad de CPU necesaria, lo que lo hace más idóneo para sistemas alimentados por batería. Los governors performance y powersave configuran la CPU a la máxima y mínima frecuencia de forma estática, respectivamente, y el governor userspace permite que los usuarios y procesos con privilegios de superusuario puedan modificar dinámicamente la velocidad del procesador.

Supongamos que queremos utilizar el governor performance. Nada más sencillo:

# echo performance > scaling_governor

# cat scaling_governor
performance

# cat cpuinfo_cur_freq
2200000

Ya tenemos la CPU a pleno rendimiento (y gastando más energía, claro).

En el directorio /sys/devices/system/cpu/cpuX/cpufreq tenemos más ficheros para consultar más datos sobre nuestras CPUs y alterar su comportamiento, pero también podemos hacerlo a través de una sencilla herramienta de línea de comandos:

# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
 driver: powernow-k8
 CPUs which run at the same hardware frequency: 0 1
 CPUs which need to have their frequency coordinated by software: 0 1
 maximum transition latency: 109 us.
 hardware limits: 1000 MHz - 2.20 GHz
 available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
 available cpufreq governors: userspace, powersave, conservative, ondemand, performance
 current policy: frequency should be within 1000 MHz and 2.20 GHz.
 The governor "performance" may decide which speed to use
 within this range.
 current CPU frequency is 2.20 GHz (asserted by call to hardware).
 cpufreq stats: 2.20 GHz:18,75%, 2.00 GHz:2,63%, 1.80 GHz:15,07%, 1000 MHz:63,55% (3424)
analyzing CPU 1:
 driver: powernow-k8
 CPUs which run at the same hardware frequency: 0 1
 CPUs which need to have their frequency coordinated by software: 0 1
 maximum transition latency: 109 us.
 hardware limits: 1000 MHz - 2.20 GHz
 available frequency steps: 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
 available cpufreq governors: userspace, powersave, conservative, ondemand, performance
 current policy: frequency should be within 1000 MHz and 2.20 GHz.
 The governor "performance" may decide which speed to use
 within this range.
 current CPU frequency is 2.20 GHz (asserted by call to hardware).
 cpufreq stats: 2.20 GHz:18,75%, 2.00 GHz:2,63%, 1.80 GHz:15,07%, 1000 MHz:63,55% (3424)

Mediante cpufreq-info -h podemos consultar la lista de parámetros disponibles para poder elegir la información concreta que queremos obtener en cada momento. También contamos con las utilidades cpufreq-set para modificar el comportamiento de la CPU y cpufreq-aperf para calcular la frecuencia media en un periodo de tiempo (atención: no todas las CPUs admiten esta consulta). Ambas herramientas admiten el parámetro -h para obtener la lista de opciones que ofrecen.

Sin embargo, todos los cambios que hagamos se pierden en el momento en que reiniciemos el equipo. Por tanto hay que utilizar un mecanismo que nos permita mantener nuestras modificaciones entre reinicios. Si sólo queremos establecer un governor concreto, basta con que lo especifiquemos en el fichero /etc/default/cpufrequtils (si no existe, lo creamos) insertando el siguiente contenido:

GOVERNOR="performance"

Si queremos modificar otros parámetros de la CPU, como la frecuencia de inicio, es necesario instalar el paquete sysfsutils:

# apt-get install sysfsutils
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias 
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes extras:
 libsysfs2
Se instalarán los siguientes paquetes NUEVOS:
 libsysfs2 sysfsutils
...
Seleccionando el paquete libsysfs2:amd64 previamente no seleccionado.
(Leyendo la base de datos ... 254004 ficheros o directorios instalados actualmente.)
Desempaquetando libsysfs2:amd64 (de .../libsysfs2_2.1.0+repack-2_amd64.deb) ...
Seleccionando el paquete sysfsutils previamente no seleccionado.
Desempaquetando sysfsutils (de .../sysfsutils_2.1.0+repack-2_amd64.deb) ...
Procesando disparadores para man-db ...
Configurando libsysfs2:amd64 (2.1.0+repack-2) ...
Configurando sysfsutils (2.1.0+repack-2) ...
[ ok ] Setting sysfs variables....

y modificar el fichero /etc/sysfs.conf adecuadamente. Dicho fichero incluye suficientes ejemplos como para que sea sencilla la tarea de incluir nuestras propias modificaciones. Tras guardar los cambios, los activamos con /etc/init.d/sysfsutils start.

En definitiva, gracias a los governors los administradores de sistemas Linux contamos con una herramienta potente y flexible para optimizar el rendimiento de uno de nuestros recursos más preciados: las CPUs de los sistemas a nuestros cargo.

Fail2ban, protección frente a ataques de fuerza bruta a servidores

Mon, 05 May 2014 14:08:04 +0000

Dentro de las preocupaciones que tenemos los que gestionamos servidores que ofrecen servicios a través de Internet destaca sin duda su seguridad a la vez que aseguramos su funcionamiento continuo. Uno de los ataques más recurrentes y habituales que sufren estos servidores es el de fuerza bruta, que consiste en la prueba sistemática y continua de un servicio hasta que se descubre una vulnerabilidad o hasta que se consigue que el servicio (en algunos casos incluso el propio servidor) deje de funcionar. Ante este tipo de ataques se utiliza una medida sencilla y efectiva, como es la utilización de algún sistema de control o filtrado de paquetes (por ejemplo, el conocido TCP Wrapper o el no menos popular iptables, el cortafuegos del núcleo de Linux). A través de alguna de estas herramientas podemos bloquear las direcciones IP de las que proceden los ataques. Sin embargo, son muchos los servicios a controlar y las IPs a bloquear al cabo de un tiempo. Afortunadamente, contamos con una gran herramienta que permite la automatización de esta línea de defensa: Fail2ban.

Se trata de un sistema de prevención de intrusiones que funciona no sólo en Linux sino en cualquier sistema POSIX que incluya un interfaz a un sistema de control de paquetes como los que he comentado antes, lo que quiere decir que funciona en otros sistemas como FreeBSD y Mac OS X. Además, como está escrito en Python, bastaría desplegar el código fuente y ejecutarlo para “echarlo a andar”. Sin embargo, es mucho mejor y más sencillo instalarlo a través de los repositorios oficiales de nuestra distribución Linux de elección.

En el caso de Debian, basta con:

# apt-get install fail2ban

Mientras que en el caso de Red Hat y sus derivativas se instala con:

# yum install fail2ban

Fail2ban funciona monitorizando los ficheros de registro del sistema en busca de entradas concretas y actuando en consecuencia a través de la ejecución de scripts que llevan a cabo las acciones deseadas por el administrador. Por ejemplo, si se detectan demasiados intentos erróneos de acceso al servidor FTP, se puede bloquear la IP desde la que se han realizado y enviar un email al administrador notificando el evento. Este bloqueo se realiza habitualmente mediante la adición de reglas en el cortafuegos y/o al fichero hosts.deny de TCP Wrapper. Además, se le puede indicar a Fail2ban que desbloquee la IP tras cierto periodo de tiempo, lo que nos sirve para evitar que conexiones legítimas (imaginemos un cliente de correo reinstalado al que se le introduce mal la contraseña del usuario) queden bloqueadas definitivamente. Generalmente, basta un bloqueo temporal para detener un ataque de fuerza bruta. Por defecto, 3 intentos fallidos (parámetro maxretry) en los últimos 10 minutos (parámetro findtime) provocan que una IP sea bloqueada otros 10 minutos (parámetro bantime).

Una vez instalado, Fail2ban nos ofrece una serie de configuraciones estándares para los servicios más habituales (apache, postfix, ssh, etc.), por lo que sólo tenemos que editar el fichero /etc/fail2ban/jail.conf y activar los filtros que nos convengan (basta con cambiar enabled = false por enabled = true en el filtro correspondiente). Estos filtros se definen a mediante expresiones regulares Python y se almacenan en ficheros dentro del directorio /etc/fail2ban/filter.d, por lo que es relativamente sencillo crear nuevos y adaptar los existentes. De igual modo, las acciones se guardan en el directorio /etc/fail2ban/action.d, en un formato propio de Fail2ban (muy sencillo) a través del cual se especifican los comandos a ejecutar y otros parámetros necesarios para un correcto funcionamiento de cada acción. Por cierto, a la combinación de un filtro y una acción se le conoce con el nombre de “jail” (cárcel). De ahí el nombre del fichero de activación de filtros.

Cada vez que realicemos un cambio en los ficheros de configuración de Fail2ban es necesario reiniciarlo, como es habitual en cualquier servicio:

# service fail2ban restart

Desgraciadamente, no hay sistema perfecto y Fail2ban presenta dos importantes carencias: no protege ante ataques distribuidos y no incluye soporte IPv6. Aún así, Fail2ban supone una gran ayuda y una línea más en la defensa de nuestros servidores expuestos en Internet.

Conversión de máquinas virtuales VMWare a Xen

Tue, 08 Apr 2014 10:56:48 +0000

A la hora de implantar una nueva aplicación de servidor es imprescindible realizar un detallado estudio de la misma que incluya entre otras cosas pruebas de funcionamiento y requerimientos técnicos. En estos casos lo habitual es generar un entorno sandbox en el que instalar la aplicación y llevar a cabo el estudio sin miedo a “estropear nada”. Sin duda, la mejor opción para obtener un entorno aséptico es el uso de la virtualización.

De hecho, es muy habitual que los proveedores de las aplicaciones ofrezcan máquinas virtuales preinstaladas para que sólo tengamos que lanzarlas y realizar el estudio. Sin embargo, la mayoría de dichas VM de prueba están basadas en VMWare debido a la popularidad que éste tiene en entornos corporativos. Personalmente, prefiero utilizar Xen como solución de virtualización en servidores porque, aparte de que es software de licencia libre, ofrece un impresionante conjunto de funcionalidades y capacidades que nos permiten virtualizar prácticamente cualquier sistema operativo bajo cualquier circunstancia técnica.

La escasa disponibilidad de VM de prueba en formato Xen no me ha impedido utilizarlas, ya que lo que hago es traducirlas desde el formato de VMWare. La receta que sigo para ello es lo que quiero compartir en el artículo de hoy. Antes de nada, debo apuntar que sólo he migrado VMs basadas en Linux. Si alguien necesita hacerlo con VMs basadas en Windows (le deseo suerte), un buen punto de partida previo es éste artículo de Microsoft.

Para ello, vamos a necesitar tener instalado el paquete qemu en nuestro servidor. En Debian es tan sencillo como:

# apt-get install qemu

Lo siguiente es comprobar el formato concreto de la imagen de la VM origen (vmdk o raw), cuyo fichero tiene extensión vmdk:

# qemu-img info Test1.vmdk
image: Test1.vmdk
file format: vmdk
virtual size: 82G (88081432576 bytes)
disk size: 2.0G

En este caso el formato de la imagen es el nativo de VMWare, así que debemos proceder a su conversión.

qemu-img convert Test1.vmdk -O raw Test1.img

Veamos un ejemplo con una imagen en formato raw:

# qemu-img info Test2.vmdk
file format: raw
virtual size: 82G (88081432576 bytes)
disk size: 2.0G

En este caso, basta con que renombremos la extensión a img:

# mv Test2.vmdk Test2.img

Ahora toca guardar la imagen en su directorio correspondiente:

# mkdir -p /home/xen/domains/test1/
# mv Test1.img /home/xen/domains/test1/

Para terminar, tenemos que generar el fichero de configuración de la nueva VM, que guardaremos en /etc/xen. En nuestro ejemplo, el fichero se llamará /etc/xen/Test1.cfg y tendrá el siguiente contenido:

disk = [ 'file:/home/xen/domains/test1/Test1.img,xvda,w' ]

Las imágenes VMWare suelen venir acompañadas de un fichero con extensión vmx, que contiene información sobre el hardware virtualizado de la VM. Suele ser muy interesante consultarlo y copiar a la configuración de la máquina Xen aquellas características que nos puedan ser de utilidad. En nuestro ejemplo, nos encontramos lo siguiente:

# less Test1.vmx
...
memsize = "2048"
numvcpus = "2"
...

Y lo trasladamos al fichero Test1.cfg de Xen así:

memory = '2048'
vcpus = '2'

Estamos preparados para arrancar la nueva máquina Xen:

# xm create -c Test1.cfg
Using config file "/etc/xen/Test1.cfg".
Started domain Test1
...

En caso de que todo vaya bien, podemos incluir en el fichero de configuración más información, como el nombre de la máquina, la configuración de red o el comportamiento de la VM ante el cierre del sistema:

name = 'test1.ejemplo.com'
vif = [ 'ip=192.168.10.55' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Por último, una vez estemos satisfechos con el resultado, deberíamos incorporar esta nueva máquina a la gestión de dominios de Xen:

# xm new Test1.cfg
Using config file "Test1.cfg".

Un último apunte antes de terminar. A veces nos podemos encontrar con imágenes VMWare que están divididas en varios ficheros. En ese caso procederemos a convertir cada fichero antes de unirlos en una sola imagen Xen final. Por ejemplo:

# ls
Test3-s001.vmdk Test3-s004.vmdk Test3.vmdk
Test3-s002.vmdk Test3-s005.vmdk Test3.vmx
Test3-s003.vmdk Test3-s006.vmdk 
# for i in `ls *[0-9].vmdk`; do qemu-img convert $i -O raw ${i/vmdk/raw} ; done
# cat *.raw >> Test3.img

Espero que esta receta os sea de utilidad a la hora de probar nuevas aplicaciones y servicios para vuestros servidores. Espero vuestros comentarios.

Optimización del tamaño de ficheros PDF en Linux

Fri, 14 Mar 2014 13:09:19 +0000

Este artículo va a ser más corto de lo habitual ya que lo voy a dedicar a un truco que he descubierto después de mucho investigar cómo conseguir que mis PDFs pesen menos con herramientas de Linux. Vaya por delante que no se trata de una receta mágica que reduce el tamaño de los ficheros sin coste a cambio, ya que la única forma de hacerlo es disminuyendo la calidad del contenido (similar a cuando aumentamos la compresión en un JPG).

Antes de dar con este truco he probado con numerosas herramientas populares en Linux, como ImageMagick o PDFtk, y con diversos servicios online de conversión, como Compress PDF, pero el mejor resultado me lo ha dado sin duda el venerable y fiable Ghostscript. Para quien no lo conozca a estas alturas, Ghostscript es un renderizador software de ficheros PostScript y PDF que se encuentra presente en los sistemas Unix desde finales de los 80.

Evidentemente, antes de proceder a utilizar Ghostscript es necesario tenerlo instalado en nuestro Linux, aunque lo habitual es que venga de serie. En el caso de Debian, es tan sencillo como:

# apt-get install ghostscript

Ya podemos proceder a utilizarlo siempre que queramos y sin necesidad de privilegios de administrador, ya que al fin y al cabo se trata de una herramienta para usuarios. Eso sí, hay que utilizarlo desde la línea de comandos, así que tendremos que abrir una consola de texto desde el menú de nuestro escritorio gráfico.

Llegó el momento de compartir el truco. La línea de comandos a utilizar para optimizar el tamaño de un PDF es la siguiente:

$ gs -dSAFER -dBATCH -dNOPA#USE -q -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -sDEVICE=pdfwrite -dPDFSETTINGS="perfil_pdf" -sOutputFile="fichero_optimizado" "fichero_original"

Ghostscript necesita de tres parámetros personalizables para trabajar según nuestras necesidades. El primero es "perfil_pdf", que indicará un perfil de calidad predefinida. De menor a mayor calidad, los valores de "perfil_pdf" son screen, default, ebook, printer y prepress. El segundo parámetro es "fichero_optimizado" y se trata del nombre (podemos incluir también el camino) del fichero resultado una vez reducido su tamaño. Por último, tenemos "fichero_original", que evidentemente es el nombre (también se puede indicar el camino) del fichero PDF que queremos optimizar.

Con esto podemos conseguir resultados espectaculares, como un caso en el que he conseguido reducir un PDF de 62Mb a sólo 5MB con el perfil “ebook” y apenas pérdida de calidad. Sin embargo, cada fichero PDF es un mundo (no es lo mismo un fichero sólo de texto que otro que incluya una buena carga gráfica) y nos podemos encontrar casos en los que incluso aumente de peso. Todo es cuestión de probar.

Antes de terminar, un comentario sobre los conversores online. No soy muy partidarios de ellos porque suelen tener límites en el tamaño del PDF a optimizar, te insertan una marca de agua y nadie te asegura la confidencialidad del fichero subido. Pero también es cierto que te pueden sacar de un apuro en un momento de urgencia. Todo es valorar las ventajas y los inconvenientes.

Espero que este truco os sea de utilidad (al final me ha quedado un artículo largo…).

Virtualización en escritorios (y IV): KVM/QEMU

Fri, 07 Mar 2014 13:12:02 +0000

Hace tiempo que tenía pendiente terminar esta serie de artículos dedicados a la virtualización en escritorios y como en el artículo anterior mencionaba esta técnica como una herramienta útil en el proceso de migración de un sistema informático a Linux, la ocasión era inmejorable para publicar unas líneas sobre una solución 100% libre y que viene de serie en el propio núcleo de Linux: KVM

KVM son las siglas de Kernel-based Virtual Machine y se trata de un módulo del núcleo de Linux que permite a un programa de usuario utilizar las capacidades de virtualización por hardware que incluyen diversos procesadores. En resumen, KVM convierte el núcleo de Linux en un hipervisor. Actualmente, KVM soporta los procesadores Intel y AMD más recientes (a través de un segundo módulo especializado del núcleo), así como una serie de plataformas menos populares en nuestros escritorios, como PowerPC, S/390 y ARM. Se incluyó por primera vez en el núcleo de Linux en la versión 2.6.20, publicada en Febrero de 2007.

KVM y QEMU emulando varios sistemas

A través de KVM es posible ejecutar múltiples máquinas virtuales corriendo imágenes sin necesidad de adaptación de numerosos sistemas operativos, incluyendo Linux, Windows, BSD, Solaris y Android. De este modo, cada máquina virtual cuenta con su propio hardware virtualizado: disco, red, vídeo, audio, etc.

Sin embargo, KVM no realiza ningún tipo de emulación, por lo que es necesario un interfaz en espacio de usuario que permita la creación y uso de las máquinas virtuales. La mejor opción en este sentido es QEMU, un emulador y virtualizador de máquinas genérico de licencia libre.

Cuando se utiliza junto con KVM, QEMU consigue un rendimiento cercano al nativo a través de la ejecución del código de la máquina virtual en el procesador de la máquina física. Así, es incluso posible ejecutar Mac OS X con una versión especialmente modificada de QEMU. Como curiosidad, añadiré que QEMU es compatible con otras soluciones de virtualización, como Xen

La puesta en marcha de la pareja KVM/QEMU es muy sencilla en Debian. En primer lugar procedemos a la instalación de las herramientas de espacio de usuario, ya que como he comentado antes el soporte de virtualización KVM ya viene de serie con el núcleo de Linux:

# apt-get install qemu-kvm libvirt-bin

En este momento ya tendríamos instalado QEMU listo para su uso con KVM, aunque sólo a través de herramientas de línea de comandos. Si queremos un buen interfaz gráfico de gestión, algo muy recomendable en el manejo de máquinas virtuales en un escritorio, mi recomendación es instalar AQEMU, que nos ofrece un interfaz muy al estilo de Virtualbox:

# apt-get install aqemu

Ventana principal de AQEMU

La primera vez que ejecutamos AQEMU nos presentará en pantalla un asistente de configuración, cuyo primer paso es elegir el idioma del interfaz (desgraciadamente no tenemos el Español como opción). En el segundo paso se nos pregunta por el directorio en el que residirán las máquinas virtuales (podemos dejar el valor por defecto a menos que se trate de un sistema de ficheros remoto o removible), si queremos utilizar el modo “Gestor de dispositivos” (recomiendo su activación) y queremos experimentar con un visor VNC empotrado en la ventana principal de AQEMU (aquí recomiendo que no, es demasiado inestable aún).

El siguiente paso nos pregunta por los “emuladores” que tenemos instalados. Pulsamos en “Search” y AQEMU buscará (y encontrará) las herramientas de KVM y QEMU. Si estamos de acuerdo con el resultado, continuamos con el siguiente paso en el que se va a configurar QEMU. Pues bien, lo mejor es dejarlo todo en sus valores por defecto y finalizar el asistente, con lo que se nos presentará la venta principal de AQEMU. Si queremos ejecutar de nuevo el asistente, tenemos la opción en el menú “File”, al igual que podemos cambiar la configuración directamente a través de las opciones “General Settings” y “Advanced Settings”.

AQEMU y los 3 sistemas más populares

Ahora es cuestión de utilizar el asistente de creación de máquinas virtuales (segundo icono por la izquierda en la barra de herramientas) para generar la primera. Cuando se nos pregunte qué emulador vamos a utilizar, probaremos primero con KVM. Si hay problemas de compatibilidad, entonces probamos de nuevo con QEMU.

Con esto tendremos KVM a pleno rendimiento (nuna mejor dicho) en nuestro escritorio. Como se puede ver, se trata de una solución relativamente sencilla de instalar y utilizar y que además es libre. En su contra tiene que QEMU ofrece pocos drivers de dispositivos multimedia y que no incluye aun soporte para el modelo de arranque UEFI. Aún así, se trata de una opción muy a considerar cuando necesitemos virtualizar sistemas para utilizarlos en nuestros escritorios. Espero que la probéis y compartáis vuestras experiencias.

Cómo migrar a Linux tras el fin del soporte de Windows XP

Thu, 27 Feb 2014 13:24:57 +0000

Nos encontramos a poco más de un mes para que Microsoft finalice el soporte activo del venerable Windows XP. La solución que se propone desde Redmond es, evidentemente, migrar a una versión superior de su sistema operativo. Sin embargo, el cambio no es tan sencillo ni tan falto de obstáculos como Microsoft pretende. Tanto Windows 7 como 8.1 tienen requerimientos hardware superiores y presentan incompatibilidades con programas y periféricos que funcionan bien en XP, por no hablar de los cambios en el paradigma de escritorio que presenta la última versión de Windows. Ante este panorama, es el momento de plantearse seriamente una migración a un entorno basado en Linux y software libre.

Un sistema informático tipo

Como en cualquier cambio en un sistema informático, es crucial realizar una cuidadosa planificación del proceso que contemple fases y tiempos de realización, donde se tengan en cuenta aspectos tan importantes como la futura organización de la red, el software a utilizar, la formación de los usuarios y el soporte posventa. en este articulo voy a centrarme en las dos primeras cuestiones.

Respecto a la organización de la red, podemos aprovechar la migración para implantar un modelo centralizado de gestión de usuarios (OpenLDAP) y sistemas de ficheros (NFS, Samba). Este modelo nos ofrece la máxima flexibilidad (es muy fácil añadir nuevos elementos a la red, sea cual sea el sistema operativo que corran), el mejor rendimiento y los menores costes de mantenimiento.

Una vez centralizada la gestión del sistema informático, Linux nos ofrece varias posibilidades interesantes, compatibles entre sí y combinables en un mismo ecosistema, para la gestión de las estaciones de trabajo. Contamos por supuesto con el modelo clásico (fat client), en el que el sistema operativo y las aplicaciones se instalan en la propia estación. Si reducimos los requerimientos de mantenimiento a la vez que aumentamos la dependencia de la red y los servidores, tenemos los puestos de trabajo sin disco duro (diskless clients) que arrancan el sistema operativo por red pero siguen utilizando los recursos locales (CPU, RAM, etc.) para la ejecución de las aplicaciones de usuario. Si damos un paso en este sentido, nos encontramos con los clientes ligeros (thin clients) que funcionan como una simple ventana a las capacidades de los servidores centrales. Linux cuenta con soporte de serie para este último modelo a través del proyecto LTPS.

La elección del modelo adecuado dependerá de las necesidades del usuario, de las características del hardware de los puestos de trabajo y de la cuantía de la inversión que estemos dispuestos a llevar a cabo. En cualquier caso, una vez centralizada la gestión de la red (algo indispensable en cualquier sistema informático) cambiar de un modelo a otro es relativamente sencillo.

Intranet en pleno funcionamiento

En cuanto a la migración de las aplicaciones de usuario, Linux ofrece numerosas alternativas nativas al software habitual en una red Windows. Incluso podemos plantearnos migrar algunas de estas aplicaciones a formato web, como por ejemplo el correo electrónico, la agenda de direcciones y el calendario a una completa intranet.

Puede darse el caso de que no encontremos una alternativa satisfactoria en Linux a una aplicación imprescindible. Se me vienen a la cabeza ejemplos como el de un diseñador que necesite de Photoshop porque necesita funcionalidades que GIMP no ofrezca o el de la típica aplicación de gestión a medida que se encuentra en la empresa desde los tiempos de Windows 95. En ese caso Linux nos ofrece tres opciones que permiten integrar la aplicación en la nueva infraestructura basada en software libre: WINE, virtualización y acceso remoto.

Lista de programas Windows instalados

WINE es lo que podríamos llamar un “emulador de Windows” (aunque técnicamente es una implementación de las funciones de Windows) que permite ejecutar en Linux software nativo de Windows. Con un desarrollo de más de 15 años a sus espaldas, sus responsables han llegado a recrear fallos específicos de Windows de los que depende el funcionamiento de muchas aplicaciones. Dado que WINE viene de serie en las distribuciones Linux actuales y que la lista de programas compatibles es muy extensa, es sin duda la primera opción a probar al integrar aplicaciones Windows en una red Linux.

Virtualizando con Virtualbox

En el caso de que WINE no nos sirva, tenemos la posibilidad de acomodar la aplicación “rebelde” en una máquina virtual en la que aprovechemos alguna de esas licencias de Windows XP que en breve dejarán de sernos útiles. Para ello tenemos entornos de virtualización tan completos como QEMU o Virtualbox, que nos van a ofrecer una capacidad tan interesante como la de aislar XP de forma que nunca se comunique con el mundo exterior ahora que su soporte finaliza, minimizando el riesgo de que un malware lo alcance. Además, podemos generar imagenes periódicas de la máquina virtual (VM), de forma que si finalmente se infecta podamos volver atrás a un estado limpio conocido.

Si necesitamos que más de un usuario tenga acceso a la VM, tenemos restricciones de licencia o la aplicación es muy cara, podemos optar por el acceso remoto a la misma. Bien a través del protocolo RDP que Windows XP ofrece de forma nativa o bien a través de un servidor VNC (de licencia libre), los usuarios podrán acceder al escritorio XP virtualizado y utilizar la aplicación desde sus escritorios Linux, dentro de las limitaciones de licencia de la propia aplicación.

En definitiva, con una buena planificación y unos objetivos claros y definidos, una migración a Linux no es tan complicada y traumática como podría parecer. Quedan pocos días para que Windows XP se despida de nosotros y es el momento de decidirse a dar el salto a Linux y el Software Libre. Algunos de nuestros clientes lo han hecho ya, ¿por qué no tú?

Cómo recuperar ficheros de discos defectuosos bajo Linux

Thu, 20 Feb 2014 14:38:50 +0000

En un artículo anterior describía unos procedimientos para comprobar la salud de los discos duros de un sistema Linux. El objetivo de dicho artículo era descubrir si los discos presentaban algún tipo de problema físico, recomendando su sustitución lo antes posible. Sin embargo, ¿qué hacemos si queremos recuperar ficheros que tienen partes de los mismos residiendo en sectores defectuosos? Veámoslo, teniendo en cuenta que la información que se encuentre en dichos sectores tiene una alta probabilidad de ser irrecuperable. En este caso, al menos podemos intentar recuperar el contenido accesible, que podemos editar a posteriori.

El método consiste en realizar una copia del fichero con tolerancia a fallos, de forma que cuando se produzca un error de lectura el procedimiento siga adelante y recupere al final la información que sí ha podido leer sin problemas. Para ello contamos con una herramienta clásica de UNIX, el comando dd, tan útil como peligroso si no lo utilizamos bien.

En el caso que nos ocupa, tendremos que indicarle a dd el fichero a recuperar, el destino en el que guardaremos el contenido recuperado y que debe realizar la copia con tolerancia a errores de lectura. El comando completo, que hay que ejecutar como root, sería el siguiente:

# dd if=/home/usuario/fichero of=/media/usbdrive/fichero_limpio conv=noerror,sync

Como se puede ver, la salida se realiza en un dispositivo diferente al disco defectuoso (por ejemplo, un pendrive) para evitar males mayores.

Una vez terminada la copia, sólo resta desechar el disco y sustituirlo por otro en buenas condiciones. POr cierto, debido a los errores de lectura, la copia con dd puede tardar bastante tiempo en llevarse a cabo, sobre todo dependiendo del tamaño del fichero original y de la cantidad de sectores defectuosos por los que hay que pasar. En definitiva, que hay que armarse de paciencia.

Si no queremos deshacernos del disco problemático (por ejemplo, forma parte de un RAID, no tenemos recambio a mano o simplemente lo queremos reutilizar), existe una opción que hay que utilizar como último recurso, ya que se trata de un procedimiento que elimina la información del sector y que tiene un alto grado de riesgo destructivo para todo el sistema de ficheros. Se trata de forzar la relocalización dinámica de sectores defectuosos, algo que los discos suelen llevar a cabo de forma automática por su cuenta pero que en esta ocasión vamos a obligarle a hacer.

Para ello contamos con la herramienta hdparm, la cual ya mencionamos en el artículo anterior. Pero antes de comenzar con la relocalización, comprobaremos si el disco ya ha reasignado sectores en el pasado. Hay que tener en cuenta que cada disco duro ofrece un número máximo de sectores de reserva y que si se ha agotado este procedimiento será inútil. El comando es el siguiente:

# smartctl -a /dev/sda | grep -i reallocated
 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0

Si nos fijamos en el último dato, vemos que está a cero, lo que indica que nunca se han relocalizado sectores en el disco. En el ejemplo del artículo anterior, la cuenta estaba en 10640, una mala noticia sin duda.

El siguiente paso es confirmar que el supuesto sector defectuoso tiene realmente problemas de lectura. Siguiendo en el ejemplo del otro artículo, el comando es como sigue:

# hdparm --read-sector 2307480536 /dev/sda

/dev/sda:
reading sector 2307480536: FAILED: Input/output error

Efectivamente, el sector es defectuoso, así que podemos proceder a relocalizarlo:

# hdparm --write-sector 2307480536 /dev/sda

/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

# hdparm --write-sector 2307480536 --yes-i-know-what-i-am-doing /dev/sda

/dev/sda: re-writing sector 2307480536: succeeded

Como comentaba más arriba, hdparm nos avisa de que se trata de una operación peligrosa porque estamos escribiendo en el disco duro a bajo nivel saltándonos los mecanismos estándares de escritura de bloques del sistema de ficheros residente.

Si la operación anterior tiene éxito, podemos comprobar el resultado:

# hdparm --read-sector 2307480536 /dev/sda

/dev/sda:
reading sector 2307480536: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
...
(siguen muchas líneas con ceros a continuación)

# smartctl -a /dev/sda | grep -i reallocated
 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 1

Vemos que el sector vuelve a estar disponible para su uso y que la cuenta de sectores relocalizados ha aumentado en uno.

Ahora sólo es cuestión de decidir si seguimos con el disco adelante, lo reutilizamos para datos menos importantes o lo tiramos a la basura directamente.

Comprobando la salud de los discos duros en un sistema Linux

Fri, 22 Nov 2013 13:13:29 +0000

En los últimos meses nos hemos visto en la tesitura de tener que sustituir discos duros defectuosos en diversos servidores cuyo mantenimiento caen bajo nuestra responsabilidad, algunos con acceso local y otros sólo con acceso remoto por encontrarse geográficamente en otros países. Afortunadamente todos esos servidores corren Linux, lo que facilita enormemente la tarea de detectar fallos en discos duros, proceder a su parada y sustituirlos por otros nuevos, integrándolos transparentemente en el RAID que solemos implementar en nuestros servidores.

¿Cómo se detecta que un disco es defectuoso? La primera pista nos la va a dar un cambio drástico en el servidor: bajada de rendimiento, problemas de acceso a ficheros, servicios caídos, etc. Es en ese momento cuando debemos pasar a comprobar la salud de los discos duros del sistema y descubrir cuál (o cuales) es el que tiene problemas.

La forma más directa y sencilla de comprobar si un disco duro está teniendo problemas es consultar el registro de los mensajes del núcleo con el comando dmesg. Ahí buscaremos referencias a errores de acceso a disco, problemas en las operaciones de lectura/escritura, menciones a relocalización de sectores, etc.

# dmesg | less
...
ata2.00: failed command: READ FPDMA QUEUED
ata2.00: cmd 60/08:00:d8:5b:89/00:00:89:00:00/40 tag 0 ncq 4096 in
 res 41/40:08:d8:5b:89/00:00:89:00:00/00 Emask 0x409 (media error)
ata2.00: status: { DRDY ERR }
ata2.00: error: { UNC }
sd 1:0:0:0: [sdb] Unhandled sense code
sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 89 89 5b d8 00 00 08 00
end_request: I/O error, dev sdb, sector 2307480536
...

En el ejemplo vemos que el disco problemático es sdb. Igualmente sencillo es comprobar si se ha caído algún disco del RAID del servidor:

# cat /proc/mdstat 
Personalities : [raid1] 
md3 : active raid1 sda4[2] sdb4[1](F)
 1839220031 blocks super 1.2 [2/1] [U_]

De nuevo comprobamos que sdb es el culpable. Sin embargo, al tratarse de servidores, la forma más adecuada de detectar fallos en los discos es mediante la prevención a través de un sistema de monitorización al que incorporemos los controles necesarios, normalmente basados en la tecnología S.M.A.R.T. que se encuentra presente en los discos duros desde hace ya muchos años.

El soporte S.M.A.R.T. en Linux se consigue a través del paquete smartmontools, que permite controlar y monitorizar sistemas de almacenamiento utilizando dicha tecnología. De hecho, se incluye un demonio que nos avisa inmediatamente si se producen errores en alguno de los discos monitorizados.

Una vez identificado el disco defectuoso procedemos a comprobar su salud mediante smartctl, una herramienta de línea de comandos incluida en smartmontools. Con esta utilidad podremos no sólo obtener detallada información sobre el disco, sino además llevar a cabo completos tests que nos mostrarán si es defectuoso y cuál es el defecto concreto. Veamos unos ejemplos.

Para obtener información sobre un disco tenemos a nuestra disposición varios parámetros. Si queremos información sobre el hardware:

# smartctl -i /dev/sdb
=== START OF INFORMATION SECTION ===
Device Model: ST...
Serial Number: W...
Firmware Version: C...
User Capacity: 3,000,592,982,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Fri Nov 22 12:33:54 2013 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Podemos ampliar estos datos con la información SMART del disco duro con el parámetro -a. Si en cambio usamos -x, la salida del comando incluirá la información que no proviene de SMART.

# smartctl -a /dev/sdb
=== START OF INFORMATION SECTION ===
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
 was never started.
 Auto Offline Data Collection: Disabled.
Self-test execution status: ( 121) The previous self-test completed having
 the read element of the test failed.
...
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
 1 Raw_Read_Error_Rate 0x000f 107 098 006 Pre-fail Always - 186855524
 3 Spin_Up_Time 0x0003 093 093 000 Pre-fail Always - 0
 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 8
 5 Reallocated_Sector_Ct 0x0033 092 092 036 Pre-fail Always - 10640
 7 Seek_Error_Rate 0x000f 083 060 030 Pre-fail Always - 219208774
...

Si alguno de los anteriores comandos falla, podemos añadir el parámetro -T permissive (e incluso -T verypermissive) para intentar que smartctl ignore los errores que pueda y obtenga toda la información posible del disco.

Pasemos a lo realmente interesante: la realización de tests en los discos duros. La primera y más sencilla opción que tenemos a nuestra disposición es el parámetro -H, que nos informa de la salud SMART del disco.

# smartctl -H /dev/sdb
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Esta opción sólo indica que la salud es mala cuando el disco ya ha fallado o va a fallar en las próximas 24 horas. Podemos ver en el ejemplo que, a pesar de que sdb es defectuoso, se nos informa de que la salud SMART del disco es buena.

Para detectar el problema del disco en detalle contamos con el parámetro -t, que a su vez admite un argumento que indica el tipo de test a realizar: offline, short, long y conveyance. Todas estas pruebas se pueden realizar con el sistema en producción, a menos que usemos el parámetro -C, que las ejecuta en modo cautivo (no tiene efecto en tests de tipo offline). Este modo sirve para realizar las pruebas más rápidamente y tiene especial utilidad cuando la máxima prioridad es comprobar la salud del disco. La explicación en detalle de cada uno de estos tests se encuentra en el manual electrónico de smartctl.

Excepto en el mencionado modo cautivo, los tests se realizan en segundo plano, por lo que no obtenemos ninguna información por pantalla a menos que la pidamos explícitamente con el parámetro -l selftest. Dado que esto sólo nos muestra un instante del progreso del test, es interesante combinarlo con el comando watch, que por defecto realiza la tarea que le asignemos cada dos segundos. Veamos un ejemplo:

# smartctl -t short /dev/sdb
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after ...

Use smartctl -X to abort test.

# watch smartctl -l selftest /dev/sdb
Every 2,0s: smartctl -l selftest /dev/sdb

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 15073 2307480536

¡Eureka, hemos encontrado el defecto del disco sospechoso! Se trata de un error de lectura en al menos un sector del disco, siendo el primero detectado el especificado en la salida de smartctl. Ahora sólo queda cambiarlo por uno nuevo y llevar el defectuoso al fabricante a que nos lo cambie (si está en garantía, claro). Por cierto, en el ejemplo vemos cómo se nos informa de que podemos abortar cualquier test con smartctl -X.

Como curiosidad, si necesitamos conocer el modelo y número de serie del disco para el trámite con el fabricante, podemos obtenerlos con este sencillo comando (además de con smartctl -i):

# hdparm -i /dev/sdb | grep SerialNo
 Model=ST..., FwRev=C..., SerialNo=W...

¡Suerte con los discos duros!

Comprobando el hardware de un servidor Linux sin abrirlo: pequeñas utilidades de línea de comandos (y IV)

Tue, 22 Oct 2013 10:36:53 +0000

Para terminar esta serie de artículos sobre herramientas software para conocer el hardware de un servidor que esté en producción sin pararlo ni abrirlo, quiero dedicar este artículo a enumerar una serie de sencillas utilidades de línea de comandos que sólo hacen una tarea pero la hacen de una manera muy especializada y eficiente, lo que las convierten en realmente útiles para el administrador de sistemas.

lspci

lspci es una herramienta que lista todos los dispositivos PCI presentes en el sistema.

# lspci
00:00.0 Host bridge: Intel Corporation Device 0150 (rev 09)
00:01.0 PCI bridge: Intel Corporation Device 0151 (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Device 0162 (rev 09)
00:14.0 USB Controller: Intel Corporation Device 1e31 (rev 04)
00:16.0 Communication controller: Intel Corporation Device 1e3a (rev 04)
00:1a.0 USB Controller: Intel Corporation Device 1e2d (rev 04)
00:1c.0 PCI bridge: Intel Corporation Device 1e10 (rev c4)
00:1c.4 PCI bridge: Intel Corporation Device 1e18 (rev c4)
00:1d.0 USB Controller: Intel Corporation Device 1e26 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Device 1e4a (rev 04)
00:1f.2 SATA controller: Intel Corporation Device 1e02 (rev 04)
00:1f.3 SMBus: Intel Corporation Device 1e22 (rev 04)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)

Gracias a la gran cantidad de parámetros que admite, podemos controlar el nivel de detalle y la forma de presentar la información que nos devuelve lspci. Por ejemplo, -k nos indica el módulo del kernel que gestiona cada dispositivo, -t nos muestra los dispositivos en un árbol, -m saca la información en un formato fácilmente analizable por scripts y -v nos da información detallada sobre cada dispositivo (podemos poner hasta tres v para aumentar el nivel de detalle).

# lspci -k
00:00.0 Host bridge: Intel Corporation Device 0150 (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: agpgart-intel
00:01.0 PCI bridge: Intel Corporation Device 0151 (rev 09)
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation Device 0162 (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 84ca
00:14.0 USB Controller: Intel Corporation Device 1e31 (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation Device 1e3a (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
...

# lspci -t
-[0000:00]-+-00.0
+-01.0-[01]--
+-02.0
+-14.0
+-16.0
+-1a.0
+-1c.0-[02]--
+-1c.4-[03]----00.0
+-1d.0
+-1f.0
+-1f.2
\-1f.3

lsusb

lsusb realiza un trabajo similar pero con el subsistema USB y los dispositivos conectados.

# lsusb
Bus 002 Device 002: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

lsusb cuenta con un menor número de parámetros que modifican su salida pero son igualmente útiles. Por ejemplo, -t nos muestra los dispositivos en un árbol, -v nos da información detallada y -s y -d muestran sólo los dispositivos especificados por bus y dispositivo o por identificador de fabricante, respectivamente.

# lsusb -d 046d:c50e -v
Bus 002 Device 002: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc50e Cordless Mouse Receiver
...

ethtool

ethtool sirve para mostrar o cambiar la configuración de los interfaces de red. Esta herramienta necesita de al menos un argumento para trabajar (el interfaz de red a consultar) y de parámetros que indiquen qué información requerimos.

# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes

# ethtool -i eth0
driver: forcedeth
version: 0.64
firmware-version:
bus-info: 0000:00:08.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

# ethtool -S eth0
NIC statistics:
tx_bytes: 266807800
tx_zero_rexmt: 333342
tx_one_rexmt: 0
tx_many_rexmt: 0
tx_late_collision: 0
...

# ethtool -t eth0
The test result is PASS
The test extra info:
link (online/offline) 0
register (offline) 0
interrupt (offline) 0
loopback (offline) 0

dmesg

dmesg es un comando que nos muestra el contenido del registro del núcleo, lo que implica que al comienzo se encuentra toda la información relativa a la detección del hardware. Personalmente recomiendo su invocación de la siguiente manera para no mostrar las marcas de tiempo del núcleo y paginar la exhaustiva información que se nos va a mostrar en pantalla:

# dmesg -t | less
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 3.9-0.bpo.1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.9.6-1~bpo70+1
Command line: BOOT_IMAGE=/boot/vmlinuz-3.9-0.bpo.1-amd64
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
...
NX (Execute Disable) protection: active
SMBIOS 2.3 present.
DMI: /M55S-S3, BIOS FB 01/10/2007
No AGP bridge found
...
ACPI: RSDP 00000000000f6260 00014 (v00 GBT )
ACPI: RSDT 00000000cfff3000 00038 (v01 GBT NVDAACPI 42302E31 NVDA 01010101)
...
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
ehci-pci: EHCI PCI platform driver
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 21
forcedeth 0000:00:08.0: setting latency timer to 64
forcedeth 0000:00:08.0: ifname eth0
...

/proc

Para terminar el artículo, quiero hablar de /proc, que no es una herramienta en sí, sino el sistema de ficheros a través del cual se puede interactuar con el núcleo en vivo. Por tanto, podemos utilizar los comandos habituales tanto para consultar información como para modificarla al vuelo. Veamos varios ejemplos de uso de /proc para conocer el hardware del sistema.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping : 9
microcode : 0x12
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq est ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes avx f16c rdrand hypervisor lahf_lm ida arat epb xsaveopt pln pts dtherm fsgsbase smep erms
bogomips : 6800.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

# cat /proc/meminfo
MemTotal: 19554776 kB
MemFree: 156468 kB
Buffers: 239696 kB
Cached: 18424088 kB
SwapCached: 5088 kB
Active: 9483528 kB
Inactive: 9367064 kB
Active(anon): 152516 kB
Inactive(anon): 34384 kB
Active(file): 9331012 kB
Inactive(file): 9332680 kB
Unevictable: 20 kB
Mlocked: 20 kB
SwapTotal: 33553332 kB
SwapFree: 33537992 kB
...

# cat /proc/partitions
major minor #blocks name

2 0 4 fd0
11 0 1048575 sr0
8 0 156289847 sda
8 1 1951744 sda1
8 2 97655808 sda2
8 3 56680448 sda3

Conclusión

Existen muchas más herramientas, como free, top, uname, lsmod, fdisk, etc. La lista es sencillamente interminable. Basta con hacer una sencilla búsqueda por Internet para encontrar pequeñas joyas como las que he comentado en este artículo, consultar su manual y añadirlas a nuestra “caja de herramientas” particular.

Con esta serie de artículos espero haber facilitado un poquito el día a día a mis colegas administradores de sistemas. Espero vuestros comentarios.

Comprobando el hardware de un servidor Linux sin abrirlo: OCS Inventory (III)

Thu, 19 Sep 2013 13:58:58 +0000

Las herramientas de las que he hablado hasta ahora en esta serie de artículos eran utilidades de línea de comandos dirigidas a descubrir de forma puntual qué hardware tiene un sistema en producción sin pararlo. Si lo que buscamos es algo más complejo más allá de una simple consulta de vez en cuando, que nos permita elaborar y mantener el inventario hardware y software de los sistemas a nuestro cargo, una gran opción es sin duda OCS Inventory.

Se trata de un completo entorno de gestión (de licencia libre) de los activos TIC de cualquier organización. Cuando se publicó por primera vez en 2001, OCS Inventory permitía la creación automatizada del inventario del hardware. A día de hoy ha evolucionado tanto que inventaria también el software, realiza escaneos de red e incluso permite la instalación distribuida de software. También incluye un sistema de plugins que permite ampliar las capacidades de serie de OCS Inventory. Aunque la lista de plugins disponibles no es muy extensa, ofrece la suficiente utilidad como para tenerlos en cuenta.

OCS Inventory se compone de tres elementos: un servidor, los agentes y las herramientas de distribución de software. El servidor es el elemento principal del entorno, gestionando la información y poniéndola a disposición de los administradores del sistema. Existen versiones tanto para Linux (y otros Unix) como para Windows.

Sin embargo, el servidor no serviría de nada sin los agentes, pequeños componentes software que se instalan en los dispositivos que queremos inventariar y gestionar a través del servidor y que nutren a éste con toda la información que puedan descubrir sobre el sistema en el que están instalados. Por la naturaleza de su función, en el caso de los agentes existen versiones para todos los sistema operativos más populares, incluyendo los de los smartphones y tablets (excepto iOS).

Por último se encuentran las herramientas de distribución de software, con versiones para Linux, Windows y MacOS, que permiten de una manera sencilla la instalación remota y controlada de programas en equipos que corran dichos sistemas operativos. Es sin duda una gran ayuda para los administradores de redes y una de las capacidades más celebradas de OCS Inventory.

Su instalación es realmente sencilla. Basta con dirigirnos a la sección de descargas de la web oficial y obtener las versiones adecuadas a los sistemas que vamos a gestionar. Sin embargo, lo más sencillo para instalar un servidor OCS Inventory es utilizar una distribución Linux en cuyos repositorios esté disponible.

Por ejemplo, en Debian empezaríamos con el servidor:

# apt-get install ocsinventory-server

y seguiríamos con la consola de administración, que se puede instalar en el mismo equipo que el servidor o en otro de nuestra elección:

# apt-get install ocsinventory-reports

Si accedemos mediante navegador a http://servidor_consola_admon/ocsreports , podremos proceder a configurar la consola de administración, indicando entre otras cosas dónde se encuentra el servidor de OCS Inventory.

Sólo restaría instalar los agentes en los equipos a monitorizar. En el caso de Debian sería así:

# apt-get install ocsinventory-agent

Durante la instalación debemos elegir http como método para generar el inventario e introducir el nombre o dirección IP del servidor OCS cuando se nos solicite.

Con esto OCS empezará de inmediato a escanear nuestra red y a recibir todo tipo de datos sobre la configuración de nuestros sistemas. Esta información se muestra poco después en la consola de administración. A partir de ese momento, OCS se encarga de mantener actualizada la información mediante escaneos periódicos, cuya frecuencia podemos configurar.

En definitiva, OCS Inventory se convierte en un importante aliado para los administradores de sistemas en sus tareas diarias. Es sencillo de instalar y a cambio ofrece un gran valor. Evidentemente no está pensado para consultas puntuales de información, ya que para ello están los comandos revisados en los artículos anteriores, pero sin duda OCS no debería faltar en ninguna red gestionada por buenos profesionales.

Móntate tu propio servidor de música doméstico con Raspberry Pi, Icecast2 y MPD

Mon, 19 Aug 2013 12:58:41 +0000

El propósito principal cuando adquirí mi Raspberry Pi era convertirlo en un completo centro multimedia, un anhelo de muchos años que gracias al Pi he podido satisfacer a bajo coste. Por eso elegí Xbian como la distribución a instalar, ya que no sólo está especializada en ofrecer una gran experiencia con XBMC (sin duda el mejor media center libre) sino que permite evolucionar la plataforma a nuestro gusto gracias a que está basada en Debian.

Así, he podido cumplir la semana pasada con otro de mis objetivos con mi Pi: montar mi propia radio doméstica y poder escuchar música en cualquier parte de mi casa, todo ello con software libre y sin tener que realizar una fuerte inversión (¿he oído Sonos?).

Para ello vamos a utilizar dos componentes software que como ya he dicho son de licencia libre y que son fácilmente instalables en Debian. Por un lado se encuentra Icecast2, un servidor de streaming de audio que soporta el protocolo SHOUTcast y que es capaz de recibir flujos de música desde diversos tipos de fuentes, incluyendo retransmisiones en vivo que nosotros mismos emitamos o servicios populares como Spotify. Por otro lado tenemos a MPD, un reproductor de música en modo servidor.

El objetivo por tanto es configurar MPD para que reproduzca los ficheros de audio de un directorio concreto, envíe dicha reproducción a Icecast2 y que éste se encargue de generar un streaming de audio en nuestra red doméstica al que podremos acceder desde cualquier cliente compatible con el protocolo SHOUTcast, incluyendo smartphones via WiFi..

La instalación del software en Xbian (y cualquier otra derivación de Debian) es muy sencilla:

# apt-get install mpd mpc icecast2

Como se puede ver, aprovechamos la instalación de software para incluir MPC, un cliente de línea de comandos para controlar todos los aspectos de la ejecución de MPD, desde la gestión de listas de reproducción hasta la duración del fundido entre canciones. Para conocer todas las posibilidades de MPC, nada mejor que consultar su manual electrónico:

# man mpc

Durante la instalación de Icecast2 se nos preguntará por un nombre de servidor y por una serie de contraseñas para ciertos usuarios y operaciones: source (acceso de las fuentes de audio), relay (acceso de la replicación de streams desde otros servidores) y admin (acceso de administración de Icecast2). La fortaleza de estas contraseñas queda a nuestra discreción, pero en este momento la que más nos interesa es la de source, ya que es la que va a utilizar MPD para enviarle la reproducción de ficheros de audio a Icecast2.

Para nuestro propósito, con esto ya está listo Icecast2. Si queremos modificar más aspectos de su configuración o simplemente rehacerla (por ejemplo, cambiar una contraseña), basta con que editemos el fichero /etc/icecast2/icecast.xml y procedamos a reiniciar el servidor:

# /etc/init.d/icecast2 restart

Es el turno de configurar MPD, el cual seguramente habrá mostrado un aviso al finalizar la instalación y haberse iniciado:

listen: bind to '[::1]:6600' failed: Failed to create socket: Address family not supported by protocol (continuing anyway, because binding to '127.0.0.1:6600' succeeded)

No debemos preocuparnos ya que este mensaje significa que no tenemos activo IPv6 en nuestro Pi, lo cual no impide que MPD se haya iniciado y esté en pleno funcionamiento. De todas formas, si queremos activar el soporte IPv6 en nuestra Xbian, basta con incluir la cadena ipv6 en /etc/modules. También podemos probar a cargar el módulo a mano desde la línea de comandos:

# modprobe ipv6

La configuración de MPD es algo mas compleja, ya que tendremos que indicarle tanto la fuente de ficheros de audio como el destino de su reproducción (en nuestro caso, el servidor Icecast2). Para ello tendremos que editar el fichero /etc/mpd.conf.

Por defecto, la fuente de ficheros (indicada por la variable music_directory) apunta al directorio /var/lib/mpd/music. Mi recomendación es dejarla tal como está y crear enlaces simbólicos dentro de dicho directorio que apunten a los directorios en los que tengamos nuestros ficheros de música, aunque se trate de dispositivos removibles (como discos USB).

Lo siguiente es configurar el destino de la reproducción, Para ello comentaremos todas las secciones audio_output e incluiremos la siguiente:

audio_output {
 type "shout"
 name "Mi radio domestica"
 description "Stream MPD desde mi Raspberry Pi"
 host "localhost"
 port "8000"
 mount "/mpd"
 password "contraseña_source_de_icecast2"
 bitrate "128"
 format "44100:16:2"
 encoding "mp3"
}

En este ejemplo, estamos indicándole a MPD que envíe la reproducción de ficheros al servidor Icecast2 que está escuchando en el puerto 8000 de la misma plataforma (nuestro Pi), utilizando /mpd como punto de montaje (más sobre esto a continuación). Dicha reproducción se codificará al vuelo en formato mp3 a 44100Hz, 16 bits, 2 canales y un bitrate de 128k. Aquí el parámetro realmente importante es password, en el que indicaremos entre comillas la contraseña que usamos para el usuario source de Icecast2.

Además habilitaremos la siguiente sección audio_output, con al finalidad de que MPD arranque de todas formas aunque el servidor Icecast2 no esté disponible:

audio_output {
 type "null"
 name "My Null Output"
}

Terminamos la configuración de Icecast2 modificando la variable bind_to_address, a la que asignaremos el valor localhost. Tras guardar los cambios, sólo queda reiniciar ambos servidores:

# /etc/init.d/icecast2 restart
Restarting icecast2: Starting icecast2
Detaching from the console
icecast2.
# /etc/init.d/mpd restart
[ ok ] Stopping Music Player Daemon: mpd.
[ ok ] Starting Music Player Daemon: mpd.

Ahora vamos a comprobar que MPD está en correcto funcionamiento:

# mpc outputs
Output 1 (Mi radio domestica) is enabled
Output 2 (My Null Output) is enabled

Si alguna de las salidas apareciera deshabilitada, bastaría con ejecutar el siguiente comando:

# mpc enable

Vamos a alimentar nuestro servidor MPD con música. Lo más sencillo es utilizar MPC para esta tarea.

# mpc update --wait (escanea el directorio de ficheros de audio)
# mpc ls | mpc add (añade las canciones encontradas a la lista de reproducción por defecto)
# mpc playlist (muestra el contenido de la lista de reproducción que acabamos de crear)
...
# mpc play (comienza la reproducción)
...

Podemos seguir “jugando” con MPC a través de comandos como status, random, repeat, crossfade, shuffle, etc., pudiendo utilizar MPC desde otro ordenador con sólo incluir el parámetro -h junto con la IP del Pi. Las posibilidades son muchas para que la reproducción quede a nuestro gusto. Además, MPD va a recordar el estado en el que lo hayamos dejado, por lo que aunque reiniciemos el Pi, MPD continuará la reproducción por donde la dejamos.

Es el momento de conectarnos a Icecast2 con un cliente compatible. En http://www.icecast.org/3rdparty.php tenemos una lista completa tanto de clientes de control (para sustituir a MPC) como de reproductores compatibles. Para escuchar nuestra recién instalada radio doméstica, tenemos que indicarle al reproductor que se conecte a la URL http://ip_raspberry_pi:8000/mpd.m3u. Como vemos, el punto de montaje definido antes se utiliza en la URL para acceder a nuestra radio, que se está transmitiendo por nuestra red doméstica y a la que puede tener acceso cualquier dispositivo conectado a la misma, desde ordenadores hasta altavoces inalámbricos, pasando por tablets y smartphones.

A partir de aquí las posibilidades son infinitas. Por ejemplo, podemos conectar flujos de terceros (con software como DarkIce), replicar esta instalación en nuestra empresa para implantar un hilo musical a bajo coste o utilizar un servidor virtual en Internet para tener nuestra radio disponible en cualquier sitio (imaginad conectar nuestra radio privada al equipo de audio de nuestro coche mediante el Bluetooth de nuestro smartphone).

Espero que lo probéis y que compartáis vuestras experiencias y otras ideas que se os ocurran para mejorar esta receta.

Comprobando el hardware de un servidor Linux sin abrirlo: dmidecode (II)

Fri, 09 Aug 2013 12:17:56 +0000

La segunda herramienta que nos va a permitir conocer la configuración del hardware de un sistema en producción sin tener que pararlo ni abrirlo es dmidecode. Al igual que hwinfo, se trata de una utilidad de línea de comandos. Sin embargo, en vez de sondear el hardware, dmidecode analiza la información almacenada en la BIOS en las tablas DMI y la muestra en pantalla.

Para instalar dmidecode en un sistema Debian, basta con seguir el procedimiento habitual:

# apt-get install dmidecode

La forma de utilizar dmidecode es muy sencilla y similar a la de hwinfo, es decir, invocamos el comando junto con un argumento que nos permitirá obtener la información concreta deseada. Evidentemente, si ejecutamos dmidecode sin argumentos, obtendremos toda la información disponible:

# dmidecode
SMBIOS 2.7 present.
109 structures occupying 3956 bytes.
Table at 0x000EB6C0.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
 Vendor: American Megatrends Inc.
 Version: 0915
 Release Date: 07/27/2012
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 8192 kB
 Characteristics:
 PCI is supported
 BIOS is upgradeable
...

dmidecode tiene dos parámetros para seleccionar la información a mostrar, --string y --type. El primero obtiene el valor de la cadena DMI indicado por la palabra clave que hay especificar. Por ejemplo, para conocer la marca del procesador:

# dmidecode --string processor-manufacturer
Intel

Al contrario que hwinfo, sólo podemos utilizar un valor a la vez. La lista de palabras clave admitidas se puede consultar en el manual electrónico de dmidecode:

# man dmidecode

El parámetro --type muestra las entradas en la BIOS del tipo que especifiquemos, donde el tipo es o bien un número (pudiendo indicar más de uno separados por comas) o bien una palabra clave (de una lista que es distinta a la utilizada por --string). Por ejemplo, para conocer información sobre el sistema y la placa base:

# dmidecode --type 1,2
SMBIOS 2.7 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
 Manufacturer: System manufacturer
 Product Name: System Product Name
 Version: System Version
 Serial Number: System Serial Number
 UUID: XXX
 Wake-up Type: Power Switch
 SKU Number: SKU

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
 Manufacturer: ASUSTeK COMPUTER INC.
 Product Name: P8H77-M PRO
 Version: Rev X.0x
 Serial Number: XXX
 Features:
 Board is a hosting board
 Board is replaceable
 Chassis Handle: 0x0003
 Type: Motherboard
 Contained Object Handles: 0

Y para saber más sobre el chasis del servidor:

# dmidecode --type chassis
SMBIOS 2.7 present.

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
 Manufacturer: Chassis Manufacture
 Type: Desktop
 Lock: Not Present
 Version: Chassis Version
 Serial Number: Chassis Serial Number
 Asset Tag: Asset-1234567890
 Boot-up State: Safe
 Power Supply State: Safe
 Thermal State: Safe
 Security Status: None
 OEM Information: 0x00000000
 Height: Unspecified
 Number Of Power Cords: 1
 Contained Elements: 0

Al igual que antes, la lista de tipos numéricos y palabras clave admitidas se puede consultar en el manual electrónico de dmidecode.

Como curiosidad, el paquete dmidecode incluye otras herramientas, destacando biosdecode, que analiza la memoria de la BIOS y muestra las estructuras de las que tiene conocimiento.

Para terminar dos advertencias. La primera es que dmidecode sólo muestra lo que la BIOS conoce, por lo que si se trata de un sistema de esos en los que la BIOS es muy espartana, es posible que no obtengamos todo lo que queremos conocer (típico de un sistema de marca). La segunda es que hay que tener cuidado al utilizarlo en un sistema en producción (aunque este sea su objetivo). Todo lo que suponga sondear el hardware está sujeto a una probabilidad (mínima) de provocar problemas en la plataforma y su caída.

Comprobando el hardware de un servidor Linux sin abrirlo: hwinfo (I)

Mon, 08 Jul 2013 13:43:00 +0000

Existen situaciones en las que es necesario conocer en detalle el hardware del que se compone un servidor del que no tenemos información pero que está en producción y que por tanto no se puede detener para abrirlo y ver sus “tripas”. Un caso muy típico es cuando es necesario ampliar la memoria RAM y no sabemos ni qué tipo admite su placa base ni cuantas ranuras están ya ocupadas. Si se trata de un servidor basado en Linux, tenemos varias herramientas a nuestra disposición para esta tarea. La primera de la que voy a hablar, por su sencillez de uso, es hwinfo.

Se trata de una utilidad de línea de comandos que es necesario ejecutar como administrador ya que de otra forma no tendremos los privilegios necesarios para acceder a la información del hardware. Para instalarlo en Debian basta con ejecutar:

# apt-get install hwinfo

Si se invoca directamente hwinfo sin ningún parámetro, veremos como se pone inmediatamente a detectar el hardware del servidor, tras lo cual muestra en pantalla un informe completo sobre el mismo. Como esta información suele ser muy extensa, lo más apropiado es redirigir la salida estándar a un fichero:

# hwinfo > /tmp/$(date +%Y%m%d)-$(hostname)-hardware.txt

De este modo obtendremos un fichero de texto plano que contiene el informe detallado del hardware del sistema y cuyo nombre está compuesto por la fecha y el nombre del servidor. Para consultarlo, podemos abrirlo así:

# less /tmp/20130708-servidor-hardware.txt

El informe por defecto es como digo muy extenso, por lo que también podemos optar por su versión resumida:

# hwinfo --short
cpu: 
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 2000 MHz
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz, 800 MHz
keyboard:
 /dev/input/event14 USB Keykoard
 /dev/input/event0 AT Translated Set 2 keyboard
mouse:
 /dev/input/mice Pixart Imaging USB Optical Mouse
 /dev/input/mice SynPS/2 Synaptics TouchPad
graphics card:
 nVidia GeForce 8600M GT
...

En el caso de que sólo nos interese conocer los detalles de ciertos componentes hardware, podemos restringir la consulta mediante el uso de una serie de palabras clave cuyo listado podemos obtener en el manual electrónico mediante el comando man hwinfo.

Por ejemplo, si quiero conocer información sobre el procesador:

# hwinfo --cpu
01: None 00.0: 10103 CPU 
 [Created at cpu.304]
 Hardware Class: cpu
 Arch: Intel
 Vendor: "GenuineIntel"
 Model: 6.15.13 "Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz"
 ...

Y si quiero detalles sobre la RAM:

# hwinfo --mem
1: None 00.0: 10102 Main Memory 
 [Created at memory.61]
 Hardware Class: memory
 Model: "Main Memory"
 Memory Range: 0x00000000-0xbe053fff (rw)
 Memory Size: 3 GB
 Config Status: cfg=new, avail=yes, need=no, active=unknown

Estos parámetros se pueden combinar en un sólo comando e incluso con --short para obtener un informe resumido:

# hwinfo --short --cpu --network
cpu: 
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
network:
 wlan0 Dell Wireless 1390 WLAN Mini-Card
 eth0 Broadcom BCM4401-B0 100Base-TX

En todo el tiempo que llevo usándolo, hwinfo se ha mostrado muy estable y nunca ha producido problemas en los sistemas en los que lo he ejecutado. Sin embargo, si sospechamos que algún componente hardware pueda estar defectuoso, considero una temeridad utilizar una herramienta como hwinfo, ya que podríamos provocar un “kernel panic” y la más que probable caída del servidor.

Según consta en el manual de hwinfo, tiene un problema: no es capaz de detectar todo el hardware. Por eso, lo complementaremos en futuros artículos con otras herramientas igualmente interesantes.

MultiCD, integración de varias ISOs en un pendrive USB

Fri, 21 Jun 2013 11:12:14 +0000

En el artículo sobre Unetbootin comenté que su mayor carencia era que sólo podía grabar una única imagen ISO en el dispositivo USB. Dada la gran utilidad que tendría el poder integrar varias imagenes en un único pendrive, he estado buscando una herramienta que lo permitiese hasta que he dado con MultiCD, la cual sin ser perfecta cumple con creces con este objetivo.

MultiCD es un shell script (por lo tanto, sólo sirve para Linux) con un funcionamiento muy sencillo: lee cada ISO que queramos integrar, construye el menú principal que nos permitirá acceder a cada imagen y finalmente genera una nueva ISO con toda la información anterior. Ya es cuestión nuestra el volcarla al pendrive, pero para ello recomiendo el mismo mecanismo que en el caso de la instalación de distros en Raspberry Pi. Evidentemente, podemos también quemarla en un CD o DVD, dependiendo del tamaño final resultante.

Su instalación es muy sencilla. Basta con acceder al enlace de descarga en GitHub que figura en la web oficial de MultiCD (el enlace a tuxfamily.org no funciona) y pulsar en el botón que aparece en la columna de la derecha con la leyenda “Download ZIP”. Una vez terminada la descarga, descomprimimos en un directorio de nuestra elección y nos aseguramos que el script principal tiene los permisos de ejecución adecuados.

# chmod 755 multicd.sh

Ahora basta con copiar o enlazar las imágenes ISO a integrar al directorio de instalación de MultiCD y ejecutar el script.

# ./multicd.sh

Antes de proceder a ejecutar el script por primera vez debemos asegurarnos de que contamos con los paquetes mkisofs o genisoimage para la generación de la ISO final.

La ejecución de MultiCD la podemos hacer tanto como usuario root como usuario estándar, ya que el script se encarga de utilizar las herramientas adecuadas en cada caso. Mi recomendación es probar primero como usuario no privilegiado y pasar a root únicamente si no nos queda más remedio.

MultiCD sólo es capaz de integrar aquellas ISO para las que tiene un plugin preparado a tal efecto (cada plugin es igualmente un shell script que se encarga de gestionar las particularidades de cada imagen), pero la lista de ellos es enorme y cubre las necesidades de prácticamente cualquier usuario. Esta lista se puede consultar en la web de MultiCD, pero incluso hay ISOs soportadas que no aparecen en la misma, por lo que la mejor manera de saber qué está soportado es consultar el listado de scripts del directorio plugins.

Si al ejecutar MultiCD no se incluye alguna de las imágenes seleccionadas, sólo tenemos que consultar en la lista de ISOs de la web cómo espera MultiCD que se llame dicha imagen y renombrarla adecuadamente.

Desgraciadamente, en mis pruebas he descubierto que muchos de ellos no están actualizados para reconocer las últimas versiones de la ISO correspondiente (como es el caso del utilísimo Ultimate Boot CD o del apreciado Kaspersky Rescue Disk), lo que disminuye la utilidad de MultiCD. Aún así, me he construido un pendrive de lo más interesante con las siguientes imagenes:

NetbootCD (instalación por red de las distribuciones Linux más populares)
SuperGrubDisk2 (inicio de sistemas Linux con arranque defectuoso)
Rescatux (reparación del arranque de sistemas Linux)
System Rescue CD (Linux en vivo para el mantenimiento de sistemas)
Clonezilla (clonación de sistemas)
AVG Antivirus
Memtest86+ (comprobación de RAM; incluido de serie)

En definitiva, MultiCD es una herramienta muy útil para los que nos dedicamos a la gestión de sistemas informáticos. Os animo a probarla y a que compartáis vuestras impresiones.

Instalar KDE 4.10 en Debian Wheezy

Mon, 03 Jun 2013 19:30:21 +0000

Soy usuario del escritorio KDE desde prácticamente los inicios del proyecto. Considero que es un gran entorno de trabajo, usable y que potencia la productividad. Pero también soy un convencido de Debian como sistema operativo, lo que significa que debo conformarme con versiones de KDE relativamente antiguas. Aunque entiendo y comparto la filosofía de Debian en el tema del software incluido en cada edición de la distro, estoy en desacuerdo con que piezas de software tan importantes como el escritorio no reciban actualizaciones más a menudo, ya que condenan al usuario a no disfrutar de las continuas mejoras que el equipo KDE incluye en cada nueva iteración.

Dado que Debian Wheezy ha salido con KDE 4.8 (con un año de antigüedad), fue para mí una gran noticia descubrir a través del blog Diariodebian una forma de instalar KDE 4.10 en la reciente edición estable de Debian. Sin embargo, las instrucciones del artículo no me han funcionado bien del todo, así que he creado mi propio recetario para conseguir que KDE 4.10 se instale y funcione correctamente en mi Debian 7.0. Eso sí, estas instrucciones sólo sirven para la arquitectura amd64.

El truco de este recetario consiste en utilizar los paquetes de KDE 4.10 que ZevenOs Neptune incluye en sus repositorios. Se trata de una distro basada en Debian Wheezy, por lo que sus paquetes deberían ser compatibles. De ahí que podamos echar mano de su KDE 4.10 para nuestra Debian 7.0. Asimismo, advierto que estas instrucciones son para realizarlas como administrador del sistema (root) desde la línea de comandos. Aquellos que prefieran los entornos gráficos, pueden sustituir algunos de estos pasos con su gestor de software favorito.

El primer paso consiste en añadir los repositorios correspondientes de ZevenOs Neptune al fichero /etc/apt/sources.list, donde se almacena la lista de repositorios desde los que instalamos el software de nuestro sistema. Abrimos el fichero con nuestro editor de elección y añadimos las siguientes líneas:

# ZevenOs Neptune (KDE 4.10)
deb http://proindi.de/zevenos/neptune/repo/ sid main
deb http://proindi.de/zevenos/neptune/kde-repo/ sid main

tras lo cual actualizamos la base de datos de paquetes:

apt-get update

Ahora, dependiendo del estado de nuestra Debian, tomaremos un camino u otro. En el caso de que no tengamos KDE instalado previamente, procederemos con su instalación desde cero:

apt-get install kde-full kde-l10n-es

con lo que instalaremos KDE 4.10 al completo junto con el soporte para el idioma español. Si en nuestro caso es que ya tenemos una versión anterior de KDE instalada, procederemos a actualizarla de la siguiente manera:

apt-get dist-upgrade

En ambos casos, la instalación se nos va a quejar de que la firma de ciertos paquetes (los de ZevenOs Neptune) es desconocida para el sistema. Esto se debe a que efectivamente no hemos instalado dicha firma, pero por más que la he buscado no la he encontrado, así que tendremos que contestar “sí” a la pregunta de si se continúa con la instalación.

Ya sólo queda reiniciar el PC, tras lo que debería presentarsenos la pantalla de bienvenida de KDM, el gestor de acceso de KDE, lo que significa que podemos empezar a disfrutar de la versión 4.10 de este estupendo escritorio.

En el artículo original se recomienda la instalación de unos paquetes que aseguran una homogeneidad visual entre las aplicaciones ejecutadas bajo KDE independientemente de si se han desarrollado con GTK o Qt, algo con lo que estoy totalmente de acuerdo:

apt-get install gtk3-engines-oxygen gtk2-engines-oxygen

Eso es todo. Espero que probéis KDE 4.10 y me contéis qué tal os ha ido.

UNetbootin, creando dispositivos USB en vivo desde imagenes ISO

Mon, 08 Apr 2013 10:30:51 +0000

Mientras escribía el artículo anterior sobre Berryboot, se me vino a la cabeza otra herramienta que tiene algún punto en común con ella: UNetbootin. Se trata de una sencilla aplicación que permite crear dispositivos USB en vivo a partir de imágenes ISO de distribuciones Linux y otras herramientas autoarrancables desde una unidad óptica. Al igual que Berryboot, UNetbootin nos permite elegir de una lista predefinida qué distro queremos en nuestro pendrive, tras lo cual procederá a descargarsela e instalarla en el dispositivo USB. Aquí acaban las similitudes con Berryboot, ya que los objetivos, finalidad, plataforma hardware y formas de trabajar de ambas herramientas son diferentes (por ejemplo, UNetbootin sólo permite una distro por dispositivo, al contrario que Berryboot).

La forma de trabajar con UNetbootin es muy sencilla. Basta con dirigirnos a su web oficial y descargarnos el binario correspondiente a nuestro sistema operativo (existen versiones para Linux, Windows y MacOSX). Antes de proceder a ejecutarlo debemos haber conectado y montado el dispositivo USB de destino. Una nota de seguridad: aunque se trata de software libre y nos lo estamos bajando de una web de confianza como Sourceforge, se trata de la descarga de un binario y no está de más que tenga cuidado extra, sobre todo teniendo en cuenta que se trata de un software que exige permisos de administrador para su funcionamiento.

UNetbootin recién iniciado

La ventana de UNetbootin nos muestra dos opciones: o bien elegimos la imagen a instalar del desplegable superior (donde descubriremos una lista impresionante de posibilidades) o bien proveemos nuestra propia imagen ISO (si a alguien se le ocurre probar cosas “diferentes”, como una versión de Windows, y tiene éxito que por favor nos lo haga saber en los comentarios). En cualquier caso, una vez realizada la selección, debemos elegir la unidad de destino del desplegable inferior. Aquí, como he comentado en artículos anteriores, debemos tener especial cuidado ya que se trata de una herramienta destructiva por naturaleza y podemos dañar el contenido de otros dispositivos si no ponemos atención (de hecho, UNetbootin nos deja incluso elegir discos duros). Finalmente, sólo queda pulsar en el botón de “Aceptar” y esperar a que acabe el proceso.

Una de las mayores ventajas de UNetbootin (aparte del ahorro en CDs y DVDs) es que nos permite trabajar de forma sencilla con equipos que carecen de unidad óptica, como es el caso de los netbooks. De este modo es posible probar e instalar una distro Linux o realizar tareas de mantenimiento con algunas de las herramientas de diagnóstico y detección de antivirus que UNetbootin permite utilizar. Sin duda, se trata de una utilidad de gran valor.

Berryboot, múltiples distros para Raspberry Pi en una sola tarjeta SD

Thu, 14 Mar 2013 11:42:32 +0000

Siguiendo con el tema del artículo anterior, existe una herramienta muy interesante que permite instalar varias distribuciones para Raspberry Pi en la misma tarjeta SD, algo muy útil si estamos cortos de tarjetas. El proyecto se llama BerryBoot y su instalación y uso son muy sencillos como vamos a ver a continuación.

Lo primero es como siempre descargarnos el software de la página oficial. A continuación lo descomprimimos y procedemos a instalarlo en nuestra tarjeta SD tal y como describí en el artículo anterior. Una vez lista la tarjeta, la insertamos en el RPi y lo arrancamos. Una vez iniciado, BerryBoot arrancará un instalador que dará formato a la tarjeta SD y nos presentará en pantalla un menú desde el que podremos elegir las distros que queramos instalar desde Internet. Evidentemente, cuando el asistente nos pregunte, le indicaremos la tarjeta como medio de instalación.

Cuando hayamos terminado la instalación de las distros que nos interesan y arranquemos de nuevo el RPi, nos encontraremos un menú de inicio que nos permitirá elegir la distro que queramos iniciar en ese momento. Esto obviamente nos obliga a tener un teclado y un ratón conectados al RPi, pero es el precio a pagar para poder tener varias distros en una misma tarjeta y poder probarlas.

Es posible añadir otras distros que BerryBoot no conozca al menú de arranque y, aunque se trata de un proceso complejo, basta con seguir paso a paso el recetario que aparece en la página oficial para personalizar nuestra tarjeta SD.

Para terminar, quiero hacer hincapié en que debemos contar con una tarjeta SD con suficiente espacio para todas las distros que queramos instalar. Esto podrá parecer evidente, pero es muy fácil que no caigamos en la cuenta y si no lo planificamos previamente al final tendremos que repetir el proceso desde el principio. Lo suyo es contar con una tarjeta de 32GB, pero si no es posible 16GB se me antojan como el mínimo imprescindible.

Espero vuestro comentarios sobre vuestra experiencia con BerryBoot.

Instalación de distros en Raspberry Pi

Tue, 05 Mar 2013 13:40:17 +0000

Desde que tengo mi Raspberry Pi no he dejado de probar distintas aplicaciones, con mayor o menor éxito dependiendo del grado de madurez del proyecto, demostrando lo útil que es el dispositivo gracias a su diseño y bajo coste. Hasta ahora, la distribución para RPi que más me ha gustado y que más utilizo es XBian, gracias a la cual mi RPi se ha convertido en un potente y completo centro multimedia. De hecho, me estoy planteando comprarme otro RPi para seguir probando cosas e inventando nuevos proyectos. Tras esta experiencia, quiero comentar en este artículo como instalar cualquier distribución para RPi sin problemas.

Lo primero que tenemos que hacer es descargarnos la imagen de la distro a instalar, la cual tendrá la extensión .img y estará comprimida para facilitar su descarga. A continuación descomprimimos la imagen y procedemos a volcarla a la tarjeta SD que introduciremos en el RPi. Para ello vamos a utilizar el comando dd, que sirve para copiar información desde una fuente a un destino byte a byte. Dado que en Linux todo es un fichero, la potencia de dd es tremenda, ya que nos va a permitir volcar el contenido de la imagen de una distro a un dispositivo extraíble como es la tarjeta SD.

Sin embargo, parafraseando el conocido anuncio, esta potencia sin control es muy peligrosa y podemos convertir a dd en una herramienta destructiva si no elegimos bien el destino del comando. Así que antes de volcar vamos a ver cómo elegir adecuadamente el dispositivo que representa a nuestra tarjeta SD.

Antes de seguir, debo comentar que cada proyecto RPi tiene unos requerimientos mínimos de espacio, por lo que la tarjeta SD que elijamos debe cubrir dicha cantidad. No todos las distros tienen las mismas necesidades, e incluso nos las podemos encontrar que les basta con 1GB, pero lo habitual es irnos a 8GB o más. Asimismo, es importante elegir una clase elevada de tarjeta, preferiblemente clase 10, ya que eso nos asegura una transferencia de datos mínima y un rendimiento adecuado en el RPi. Hay más información a este respecto en la Wikipedia.

Con la tarjeta sin insertar, ejecutamos el siguiente comando:

# cat /proc/partitions

lo que nos dará un resultado similar a éste:

major minor #blocks name

 8 0 156289847 sda
 8 1 1951744 sda1
 8 2 97655808 sda2
 8 3 56680448 sda3
 11 0 1048575 sr0

Lo que hemos hecho es preguntarle directamente al núcleo de Linux por los dispositivos de almacenamiento y sus particiones que el sistema operativo haya detectado. Aunque existen otros métodos (por ejemplo, usando el comando fdisk -l), éste es sin duda el más fiable. En el ejemplo, tenemos un disco duro (sda) con tres particiones y una unidad óptica (sr0).

Ahora insertamos la tarjeta SD en nuestro ordenador y consultamos de nuevo al núcleo por los dispositivos y sus particiones, con lo que obtendremos algo tal que así:

major minor #blocks name

 8 0 156289847 sda
 8 1 1951744 sda1
 8 2 97655808 sda2
 8 3 56680448 sda3
 11 0 1048575 sr0
 8 64 975360 sde
 8 65 975295 sde1

Como vemos, existe una diferencia clara: ahora existe un dispositivo nuevo (sde) con una partición. Pues bien, ése es el que representa a nuestra tarjeta SD y el que debemos usar en el comando dd. Por cierto, en vez de sde el sistema podrá elegir sdb, sdc, etc, según la disponibilidad de identificadores de dispositivos. En mi caso, al usar un lector multitarjeta, es lógico que el sistema me haya asignado sde.

En el caso de que nuestro Linux haya montado automáticamente la tarjeta SD debemos proceder previamente a desmontarla desde el propio entorno gráfico. Una vez lista la tarjeta, ejecutamos el siguiente comando:

# dd if=distro.img of=/dev/sde

A partir de este momento, el sistema se pondrá a volcar el contenido de la imagen de la distro para RPi en nuestra tarjeta SD. En el parámetro if indicamos el fichero de la imagen y en el parámetro of el dispositivo de la tarjeta SD. Aquí se puede apreciar el peligro de dd si indicamos incorrectamente el dispositivo de salida. ¿Qué ocurriría si pongo sda en vez de sde? Pues que más que probablemente destruya mi sistema operativo. Por eso, hay que revisar concienzudamente el comando dd antes de ejecutarlo para estar seguros de que no cometemos un grave error.

Una vez terminado dd, forzamos el vaciado de los buffers intermedios con este comando:

# sync

y ya podemos extraer la tarjeta SD de nuestro ordenador, insertarla en el RPi y probar la distro.

Con estas instrucciones sólo queda elegir la distro que queremos probar, ya sea de propósito general como Raspbian o especializada como XBian (centro multimedia), PiMame (emulador arcade) o IPFire (cortafuegos). Espero vuestras experiencias con Raspberry Pi y algunos de estos proyectos.

Desura, la alternativa a Steam

Tue, 26 Feb 2013 19:11:44 +0000

Tras dedicar el anterior artículo a Steam y su instalación en Debian Wheezy me dí cuenta de que a Desura sólo le había dedicado una breve mención en otro artículo dedicado al renacimiento del mercado de juegos para Linux. Para los que no sepan lo que es, se trata de una plataforma de distribución digital de juegos creada en 2009 por un grupo de desarrolladores australianos.

Aunque no es exclusiva de Linux, Desura facilita enormemente la adquisición y gestión de juegos en formato digital, eliminando muchos de los problemas que los usuarios noveles se encuentran a la hora de instalar programas en Linux que no están integrados en sus respectivas plataformas de gestión de software. Dado que Desura ha sido la pionera en la distribución digital de juegos comerciales en Linux y lleva por tanto más tiempo disponible que Steam en el sistema del pingüino, es de recibo que dedique un artículo a hablar de sus bondades y de cómo instalarlo en Linux.

Desura en acción

En cuanto a funcionalidad, Desura ofrece lo mismo que Steam (o debería decirlo al revés, ya que éste es el novato en Linux): un entorno de comercio electrónico, un sistema de gestión de software, una comunidad de usuarios y una plataforma para desarrolladores. Sin embargo, aquí acaban las similitudes. Desura tiene una serie de ventajas sobre Steam que lo convierten en un serio competidor para la plataforma de Valve y en mi primera elección como plataforma comercial de juegos.

1. Versión para 64 bits. Desura cuenta con versiones tanto para 32 como para 64 bits, lo que implica un óptimo rendimiento de la plataforma y permite utilizar versiones de los juegos propios de la arquitectura de la distro que tengamos instalada. Steam sólo cuenta con una versión para 32 bits, lo que obliga a utilizar versiones de 32 bits de ciertas librerías del sistema y a duplicar el espacio ocupado por las mismas, aparte de un inferior rendimiento general del entorno.

2. Instalación sencilla en cualquier distribución Linux moderna. Mientras que Steam sólo está disponible de serie para las últimas ediciones de Ubuntu (aunque se puede instalar en otras distribuciones a través de ciertas triquiñuelas), Desura es un paquete que sólo depende de sí mismo para funcionar, lo que permite su instalación (que además es muy sencilla como veremos a continuación) en cualquier plataforma Linux relativamente reciente (de unos años para acá).

3. Demos. Desura incluye demos en algunos de los títulos de su catálogo, lo que permite la prueba antes de comprar los juegos y nos habilita para invertir nuestro dinero de la mejor manera posible.

4. Juegos libres y freeware. Además de juegos comerciales, Desura ofrece la posibilidad de instalar y jugar tanto a algunos títulos libres como a juegos comerciales gratuitos. Así, no es necesario gastarse un euro para disfrutar de Desura. A día de hoy, Steam sólo ofrece un título gratuito.

5. Mods gratuitos. Finalmente, en lo que a tipos de software se refiere, Desura ofrece también mods, es decir, modificaciones de títulos existentes que amplían la experiencia de juego. Además, todos son gratis.

6. Actualización y reparación de juegos. Cuando se publica una nueva versión de un juego de nuestra lista, Desura nos avisa y nos permite actualizarlo con un sólo click. Igualmente, si un juego no funciona adecuadamente, Desura nos permite reparar su instalación, ofreciéndonos varias opciones dependiendo del problema.

7. Enorme catálogo de juegos. Esta ventaja es evidentemente fruto de que Steam acaba de aterrizar en Linux, pero Valve va a tener que trabajar muy duro para acercarse a la gran oferta actual de Desura, algo a lo que no es ajena la incorporación de juegos libres y mods a su catálogo.

Web oficial de Desura

Sin embargo, no todo es tan bonito ni tan perfecto en Desura. Por mi parte puedo afirmar que sufre de cierta inestabilidad que hace que se cierre inesperadamente en plena instalación, actualización o reparación de juegos. No es algo grave, ya que basta con abrir de nuevo Desura, pero si bastante molesto por lo recurrente del problema. Espero que lo resuelvan antes o después.

Para instalarlo basta con descargarnos el software de la web oficial de Desura, que se encargará de detectar la arquitectura de nuestra distribución, 32 ó 64 bits, y ofrecernos la descarga adecuada. El paquete viene en formato .tar.gz, por lo que procederemos a copiarlo a un directorio temporal de nuestra elección y a descomprimirlo allí. Por cierto, no es necesario realizar estar operaciones como administrador del sistema, por lo que podemos instalar Desura como nuestro usuario estándar (algo recomendable por otro lado).

# cp desura-x86_64.tar.gz
# tar xzvf desura-x86_64.tar.gz

Ahora sólo queda iniciar el ejecutable que incluye el paquete y Desura se pondrá a continuación a descargar el resto de los ficheros necesarios para funcionar, tras lo cual se inicia el entorno en sí mismo. Esto además instalará un icono de arranque en nuestro escritorio y en nuestro menús.

# ./desura

Lo primero que se muestra en pantalla es el formulario de autentificación. Si no contamos con usuario en Desura, es el momento de crearnos uno. A continuación entramos en la plataforma y ¡a disfrutar de juegos de calidad para Linux! Espero vuestras experiencias.

Instalando Steam en Debian Wheezy

Tue, 19 Feb 2013 11:12:20 +0000

La noticia más destacada de la semana pasada en el mundo Linux fue sin duda la de la publicación de la primera versión estable del cliente de Steam (la popular plataforma de distribución digital de juegos de Valve) para el sistema del pingüino. A pesar de que sólo existe versión para las últimas ediciones de Ubuntu, es posible instalarlo en Debian Wheezy (no es posible en Squeeze por la falta de algunas librerías) con algún que otro truco. Yo hace tiempo que me instalé la beta y lo cierto es que es un gusto disfrutar de mis juegos (por ejemplo, los de los Humble Bundle) cómodamente a través de un completo interfaz como Steam.

De las distintas opciones que he probado para instalar Steam en mi Wheezy, hay una que me ha funcionado sin problemas y que voy a comentar a continuación. Pero antes, si como yo utilizamos un sistema de 64 bits, es imprescindible activar antes el soporte multiarquitectura, ya que Steam sólo está disponible para 32 bits. Como siempre, estas instrucciones hay que llevarlas a cabo como administrador del sistema.

Los comandos para activar la arquitectura i386 en un sistema amd64 son los siguientes:

# dpkg --add-architecture i386
# apt-get update

Para instalar Steam vamos a utilizar un tutorial preparado por un usuario llamado Cyb.org, en el que utiliza tanto un par de scripts preparados por él mismo como otro desarrollado por un usuario llamado Kano. Sin embargo el tutorial es algo confuso e incompleto en alguno de sus pasos, así que trataré de que el procedimiento quede lo más claro posible.

Empezaremos descargando el script de Kano así:

# wget http://kanotix.com/files/fix/install-steam-wheezy.sh

A continuación le daremos permisos de ejecución:

# chmod 755 install-steam-wheezy.sh

Y procedemos a ejecutarlo, lo que terminará con la instalación de un cliente Steam adaptado a nuestra Debian:

# ./install-steam-wheezy.sh

Los siguientes pasos hay que llevarlos a cabo como nuestro usuario del sistema. Antes de cerrar la sesión de administrador, procederemos a dar permisos a nuestro usuario en el sistema de gestión de permisos sudo. Para ello, ejecutamos el comando visudo y añadimos en el editor que se abre a continuación la siguiente línea:

nombre_usuario ALL=(ALL:ALL) ALL

Esta línea sólo nos hará falta hasta que terminemos la instalación. A cotinuación nos salimos de la sesión de administrador y, como nuestro usuario estándar del sistema, nos descargamos el siguiente script:

wget http://dl.dropbox.com/u/29081229/Steam/debian_install.sh

Le damos también permisos de ejecución como antes y lo ejecutamos. Con esto ya estará lista una versión más moderna de la librería libc6 de la que viene en Wheezy y que es necesaria para Steam. Sólo queda descargarse el script que nos va a permitir ejecutar Steam sin problemas:

wget http://dl.dropbox.com/u/29081229/Steam/debian_steam.sh

Igualmente, le damos permisos de ejecución y lo arrancamos, con lo que el cliente Steam se iniciará, se autoactualizará y terminará pidiendo nuestro usuario y contraseña en el sistema de Valve. Una vez comprobado que todo está bien, no debemos olvidar que hay que eliminar de sudo la línea que insertamos antes. Sólo quedaría crearnos un icono en nuestro escritorio o en nuestro menús que invocara Steam a través del último script descargado. Hay que recordar que no debemos utilizar el icono que el propio Steam nos instala, ya que no funcionará.

Personalmente me encontré con un error en el propio Steam al iniciarlo por primera vez, en el que se quejaba de que no encontraba la librería steamui.so. Realmente el problema era que no contaba con todas las librerías i386 necesarias, así que me bastó con instalar el paquete ia32-libs para resolver el problema.

A pesar del tutorial, reconozco que se trata de un proceso complejo. Lo suyo sería que Valve publicara una versión para Debian, pero ya que no es así al menos este tutorial nos asegura el poder disfrutar de buenos juegos en nuestro Linux. ¡A pasarlo bien!

Virtualización en escritorios (III): VMWare

Tue, 12 Feb 2013 10:43:31 +0000

Continuamos con la serie de artículos dedicada a la virtualización en escritorios con el repaso a otra de las soluciones más populares del mercado. En esta ocasión se trata de VMWare, uno de los pioneros en esto de la virtualización de sistemas, siendo al igual que Virtualbox una de las opciones más sencillas de instalar y utilizar, aunque con el inconveniente de que se trata de una solución completamente privativa con versiones tanto de pago como gratuitas.

VMWare fue desarrollado por VMware Inc., que presentó al público en Mayo de 1999 un producto para escritorios, VMWare Workstation. Posteriormente entró en 2001 en el mercado de servidores con VMware GSX Server y VMware ESX Server. En 2004, la empresa se convirtió en filial de EMC Corporation.

Los productos de VMWare se ejecutan sobre Linux, Windows y Mac OS X sobre procesadores Intel, y es capaz de alojar a una gran cantidad de sistemas virtualizados. En el ámbito que nos ocupa, el de los escritorios, VMWare ofrece un producto gratuito llamado VMWare Player, que no solo ejecuta máquinas virtuales sino que también es capaz de crearlas. Su instalación es tan sencilla como descargarse de la web oficial el instalador correspondiente al sistema operativo anfitrión de nuestra elección y proceder a su ejecución. En el caso de Debian, es más que interesante seguir las instrucciones del wiki oficial del proyecto.

La existencia de una versión gratuita para escritorios convierte a VMWare en una opción muy asequible para los usuarios incluso de entornos corporativos, ya que su licencia así lo permite. Además, el formato que utiliza para los discos virtuales es gestionable incluso desde herramientas de licencia libre. Por último, existen numerosas máquinas virtuales con aplicaciones instaladas disponibles para su descarga en Internet, lo que hace ganar puntos a VMWare como opción interesante para nuestros escritorios.

VMWare basa su funcionamiento en la virtualización parcial del hardware, es decir, emula ciertas partes de la plataforma hardware sobre la que corre el sistema huésped, como el adaptador de vídeo, la tarjeta de red y los controladores de disco, mientras que pasa directamente al hardware real las llamadas a ciertos componentes, como los dispositivos USB, serie y paralelo. Esto implica una alta portabilidad entre anfitriones, siendo posible pausar una VM en un sistema, copiarla a otro y seguir allí su ejecución como si nada hubiese pasado. Asimismo, el rendimiento es generalmente superior al de soluciones de virtualización completa, aunque esto depende del uso que se le dé a la virtualización.

Al igual que en el caso de Virtualbox, quiero daros un consejo a la hora de crear nuevas máquinas virtuales. Cuando tengamos que crear el almacenamiento de la VM y se nos pregunte por el tipo de asignación del espacio, debemos asegurarnos de que sea dinámico y no fijo, de forma que no perdamos en el disco físico todo el espacio reservado para la VM mientras no esté en uso.

A pesar de las virtudes de VMWare y de tratarse de un producto robusto y estable con numerosas posibilidades, para mí chirría el hecho de que se trata de un producto privativo, por lo que prefiero otras soluciones que son tan completas como VMWare pero de licencia libre como KVM, que revisaremos en un artículo próximo. En cualquier caso, espero vuestras experiencias con VMWare.

Conversion de videos a HTML5 en Debian Wheezy

Mon, 28 Jan 2013 11:28:44 +0000

Estamos actualmente inmersos en un proyecto web consistente en la migración del actual motor al gestor de contenidos TYPO3. Se trata de una web con una importante carga de vídeos (unos 5 GB), los cuales están codificados como DivX, con la consiguiente complicación a la hora de asegurarse de que se visualizan correctamente en todas las plataformas de navegación actuales. Dado que existen algunas en las que esto ya no es posible (sobre todo en tablets y smartphones), la solución que planteamos era tirar de estándar y convertir toda la base audiovisual a HTML5, lo cual no es la panacea como comentaré más adelante, pero que al menos nos asegura que los vídeos podrán visualizarse adecuadamente de aquí a unos años.

Como estamos hablando de más de 150 vídeos, es evidente que la conversión no se podía hacer a mano, así que buscando por Google me encontré en un blog con una solución que podía automatizar el proceso, basada en la herramienta de línea de comandos ffmpeg, una verdadera navaja suiza para la codificación y conversión de material audiovisual.

Se trata de un script para Linux que toma como parámetro de entrada el vídeo a convertir y que produce como salida tres versiones del vídeo (una por cada codec soportado por la etiqueta video), una captura de pantalla en JPG para el parámetro poster y un pequeño código HTML para visualizarlo todo (que en TYPO3 no es necesario pero que no viene mal para otras situaciones). Sin embargo, el script no funcionaba bien del todo por varios motivos: algunos parámetros de invocación de ffmpeg estaban obsoletos, la visualización de los vídeos en las plataforma móviles de Apple no es correcta (como bien apuntaban en los comentarios del blog) y la generación del HTML para la visualización no funcionaba. Así que me puse manos a la obra y resolví los tres problemas (del segundo ya tenía la solución en los comentarios, como ya he dicho), obteniendo este script:

{code type=php}
#!/bin/bash

if [[ $1 ]]
then
filename=$(basename “$1”)
filename=${filename%.*}
directory=$(dirname “$1”)

duration=$(ffmpeg -i “$1” 2>&1 | grep Duration | awk ‘{print $2}’ | tr -d ,)
minutes=${duration%:*}
hours=${minutes%:*}
minutes=${minutes##*:}
seconds=${duration##*:}
seconds=${seconds%.*}

hours=$((hours*3600))
minutes=$((minutes*60))

total=$(expr $hours + $minutes + $seconds)
number=$RANDOM
let “number %= $total”

echo “Generating thumbnail”
ffmpeg -i “$1” -filter:v yadif -an -ss $number -t 00:00:01 -r 1 -y -vcodec mjpeg -f mjpeg “$directory/$filename.jpg” 2>&1
echo “Converting $filename to ogv”
ffmpeg -i “$1” -acodec libvorbis -ac 2 -ab 96k -ar 44100 -b:v 345k “$directory/$filename.ogv”
echo “Finished ogv”

echo “Converting $filename to webm”
ffmpeg -i “$1” -acodec libvorbis -ac 2 -ab 96k -ar 44100 -b:v 345k “$directory/$filename.webm”
echo “Finished webm”

echo “Converting $filename to h264”
ffmpeg -i “$1” -acodec aac -ab 160000 -vcodec libx264 -vpre ipod640 -b:v 345k -threads 0 -pix_fmt yuv420p -f mp4 -strict -2 “$directory/$filename.mp4”
echo “Finished h264”

echo “Writing HTML…”

echo "

" > "$directory/$filename.html"
 echo " " >> "$directory/$filename.html"
 echo " " >> "$directory/$filename.html"
 echo " " >> "$directory/$filename.html"
 echo " Sorry, your browser does not support HTML5 video" >> "$directory/$filename.html"
 echo "

" >> “$directory/$filename.html”

echo “All Done!”
else
echo “Usage: [filename]”
fi

{/code}

Basta con copiarlo y guardarlo en un fichero al que daremos un nombre descriptivo (por ejemplo, convertHTML5) y que deberemos almacenar en una ruta dentro de nuestro camino de ejecución. Personalmente, sugiero /usr/local/bin en base a las recomendaciones del estándar Linux para los sistemas de ficheros. Antes de proceder a su ejecución, debemos asegurarnos de que el script tiene los permisos adecuados:

# chmod 755 /usr/local/bin/convertHTML5

Igualmente, debemos asegurarnos de que las herramientas de apoyo que el script necesita están instaladas en nuestro sistema. En el caso de Debian, necesitamos al menos tener instalada Wheezy para asegurarnos de que las versiones de dichas herramientas son lo suficientemente actuales para que hagan su trabajo adecuadamente. Para ello además deberemos incluir el repositorio Debian Multimedia en nuestra lista en /etc/apt/sources.list:

deb http://oktan.ls.fi.upm.es/debian-multimedia/ wheezy main non-free

Tras actualizar la base de datos de paquetes:

# apt-get update

procedemos a instalar los paquetes necesarios:

# apt-get install ffmpeg x264 yasm lame libvpx1

Ya podemos proceder a convertir automáticamente todos nuestros vídeos, para lo cual lanzaremos un pequeño bucle:

# for i in *.{avi,AVI}; do convertHTML5 $i; done

Si tenemos vídeos en otros formatos diferentes a DivX, como WMV, MPG o MOV, basta con que añadamos sus extensiones a la lista dentro de las llaves en el bucle. ffmpeg es lo suficientemente inteligente para detectar el formato de entrada y actuar en consecuencia.

Como decía más arriba, este script da como salida tres versiones del vídeo original, uno en cada uno de los formatos (MP4, WEBM, OGV) que soporta la etiqueta video de HTML5. El motivo es que la conocida guerra de codecs se saldó con que cada navegador y plataforma soporta un formato diferente, lo que obliga a mantener una versión de cada uno para que todos los usuarios puedan disfrutar del material audiovisual sin importar cómo se conectan al sitio web. Lo único que ha provocado esta falta de entendimiento es que los desarrolladores tenemos que sufrir esta pesadilla y al menos duplicar el espacio dedicado a los audios y vídeos que queramos servir a través de HTML5. Entiendo que es muy positivo sustituir a Flash de una vez por todas, pero no a cualquier precio. De ahí mi comentario inicial de que esta solución no es precisamente una panacea.

En cualquier caso, este script nos está siendo de gran utilidad y por eso lo compartimos, esperando que también sea útil a nuestros lectores. Espero vuestros comentarios y posibles mejoras que se os puedan ocurrir.

Virtualización en escritorios (II): Virtualbox

Fri, 18 Jan 2013 11:10:58 +0000

Tras la presentación de lo que es la virtualización de sistemas, sus ventajas y los casos de uso más habituales, voy seguir esta serie de artículos dedicada a la virtualización en escritorios con el repaso a las soluciones más populares existentes en el mercado. Para ello, empezaré con Virtualbox, una de las opciones más sencillas de instalar y utilizar.

Virtualbox fue originalmente desarrollado por la empresa alemana innotek GmbH, que lo vendió en 2008 a Sun Microsystems, terminando en manos de Oracle con el resto de activos de Sun (como Java, MYSQL, Solaris, etc.) cuando se produjo la famosa adquisición. Se ejecuta en los sistemas operativos más populares y en otros minoritarios, como el propio Solaris o FreeBSD, y es capaz de alojar a una ingente cantidad de sistemas virtualizados, incluyendo OS/2. Su instalación es tan sencilla como descargarse de la web oficial el instalador correspondiente al sistema operativo anfitrión de nuestra elección y proceder a su ejecución, tras lo cual hay que proceder también a descargar e instalar el “VirtualBox extension pack”, que amplía las posibilidades del paquete original con soporte USB 2.0, RDP y arranque PXE. Sin embargo, en el caso de Debian es aún más sencillo como veremos más adelante.

La existencia del “VirtualBox extension pack” se debe a la especial licencia del software. En la actualidad, el núcleo de Virtualbox se distribuye bajo la licencia libre GPLv2, mientras que las características extendidas antes mencionadas sólo están accesibles mediante una licencia privativa para uso y evaluación personal. Esto convierte a Virtualbox en una opción muy asequible para usuarios domésticos y en entornos educativos, pero pierde enteros en entornos corporativos frente a soluciones completamente libres y, en lo referente a costes de licencias, gratuitas.

Virtualbox basa su funcionamiento en la virtualización completa (full virtualization), es decir, en la emulación al 100% de la plataforma hardware sobre la que corre el sistema huésped, de forma que éste nunca accede directamente a los recursos del hardware del anfitrión. Así, es posible instalar prácticamente cualquier sistema operativo sin modificar ni adaptar al entorno virtualizado, a cambio de una apreciable pérdida de rendimiento por la emulación por software del hardware. Sin embargo, los desarrolladores de Virtualbox han hecho un buen trabajo intentando que dicha pérdidad de rendimiento no sea tan grande, sobre todo gracias al uso del soporte de virtualización en hardware que los procesadores modernos traen de serie.

Como comentaba antes, la instalación en Debian es aún más sencilla que en otros sistemas gracias al uso de repositorios. Aunque Virtualbox está disponible en los repos oficiales, yo prefiero utilizar los que Oracle pone a disposición de los usuarios ya que así nos aseguramos tener siempre acceso a la última versión disponible. De hecho, a la hora de escribir este artículo, he comprobado que en Debian tenemos la versión 4.1, mientras que en el repositorio de Oracle contamos con la 4.2, publicada en Septiembre de 2012.

Empezamos por tanto la instalación añadiendo el repositorio oficial de Oracle a nuestra lista, bien a través del Centro de Software o bien editando directamente el fichero /etc/apt/sources.list, operaciones que sólo podemos realizar como administradores del sistema. Utilizaremos esta línea si usamos Squeeze:

deb http://download.virtualbox.org/virtualbox/debian squeeze contrib

o bien ésta otra si usamos Wheezy:

deb http://download.virtualbox.org/virtualbox/debian wheezy contrib

Ahora actualizamos la base de datos de paquetes:

# apt-get update

Y procedemos a instalar Virtualbox:

# apt-get install virtualbox-4.2

Sólo queda darle permisos de acceso a Virtualbox a aquellos usuarios del sistema anfitrión que queramos. Para ello, basta con añadirlos al grupo de usuarios vboxusers, de forma que Virtualbox pueda ejecutarse con pleno acceso a los recursos que necesita cuando es invocado por dichos usuarios. Por ejemplo, si queremos darle permiso al usuario marco, lanzamos el siguiente comando:

# adduser marco vboxusers

Listo. Ahora invocamos Virtualbox desde el icono que se ha debido instalar en nuestros menús y debería aparecer una pantalla como ésta:

Virtualbox recién instalado

En el caso de que la licencia nos lo permita, podemos proceder entonces a instalar el “extension pack”, que descargaremos previamente de la página de descargas de Virtualbox (una única descarga para todas las plataformas). Una vez hayamos cerrado Virtualbox, procedemos a la instalación del paquete como administradores con este comando:

# VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.2.6-82870.vbox-extpack

Alguien me dirá que es más sencillo hacer un simple doble click sobre el fichero del paquete o instalarlo a través del menú de preferencias del propio Virtualbox (y no les falta razón), pero de este modo sólo se instala para el usuario que está instalando el paquete y no para todos los del sistema anfitrión. Además, desde línea de comandos tendremos acceso a cualquier error que se produzca y, aunque parezca increible, podremos actualizar el paquete, algo que no parece posible desde los otros métodos si no desinstalamos primero el existente.

Sólo queda crear nuestras propias máquinas virtuales a través del sencillo asistente que Virtualbox ofrece al pulsar el botón “Nueva” y personalizarlas a través del botón “Configurar”, como se puede ver en la siguiente pantalla:

Virtualbox con una VM creada

Como se puede apreciar en el pantallazo, tengo una máquina virtual (VM) ya creada basada en Debian y que tengo suspendida en plena ejecución, de forma que cuando la inicie seguirá corriendo por donde iba cuando se detuvo.

Un consejo a la hora de crear nuevas máquinas virtuales. El asistente nos preguntará por el almacenamiento de la VM, que debería ser en un fichero alojado en un dispositivo local (trabajar con VMs en red supone una enorme pérdida de rendimiento). Cuando nos pregunte por el tipo de asignación del espacio, debemos asegurarnos de que sea dinámico y no fijo, de forma que no perdamos en el disco físico todo el espacio reservado para la VM mientras no esté en uso.

Si además nos aseguramos de que en la configuración de cada VM estén activas las extensiones de virtualización del procesador, tendremos un sistema de virtualización completo y lleno de posibilidades para nuestro escritorio. Espero vuestras experiencias con Virtualbox.

Probando el rendimiento de discos duros bajo Linux

Fri, 21 Dec 2012 13:59:21 +0000

A principios de 2012 le compré un nuevo disco duro a mi portátil con el único propósito de ampliar el escaso espacio libre que me quedaba en el antiguo. Por cierto, utilicé Clonezilla para la operación de copiar todas la información desde el disco original al nuevo y, mientras que mi sistema Linux salió andando sin problemas, tuve que dedicar varias horas a reparar la licencia de Windows Vista que aún conservo (ya que la pagué con el portátil, me la quedé).

Aunque el tener el doble de espacio es una gozada (pasé de 250 a 500GB), surgió un problema que no me esperaba: el rendimiento del portátil cayó notablemente, lo que en principio era achacable al acceso al nuevo disco. Así que para comprobar la validez de dicha sospecha, esta misma semana he realizado una serie de pruebas al nuevo disco desde Linux. Todas estas pruebas tuve que realizarlas como administrador del sistema ya que de otra forma no tendría los privilegios suficientes para acceder a los recursos necesarios para llevarlas a cabo de manera correcta.

Lo primero que hice fue comprobar el rendimiento del disco a nivel de hardware con el comando hdparm, una herramienta muy completa que permite realizar una gestión completa de nuestros discos duros. Como tal, es igualmente útil como peligrosa para nuestros datos si no la usamos bien.

En el caso que nos ocupa, utilicé dos parámetros simultáneamente para medir el rendimiento del nuevo disco. t nos devuelve la transferencia de datos directa (buffered) y T nos ofrece la transferencia de datos a través de caché (cached). Al combinar ambos parámetros en el mismo comando, se ponderan entre sí y nos ofrecen unos resultados más acordes con la realidad de nuestro dispositivo. Estos fueron mis resultados:

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 2234 MB in 2.00 seconds = 1094.17 MB/sec
 Timing buffered disk reads: 220 MB in 3.00 seconds = 71.56 MB/sec

Este comando hay que repetirlo tres veces para estar seguros de que los datos son estables y, por lo tanto, fiables. Comparando el resultado de las lecturas directas a disco con las especificaciones del fabricante (que hay que recordar que se obtienen en laboratorio en condiciones ideales y que por lo tanto hay que ponderar a la hora de hacer comparaciones con valores obtenidos en situaciones reales), descubrí que las primeras con aproximadamente un 50% de las segundas, lo que concuerda con lo que suele ser habitual. De hecho, hice pruebas con el disco antiguo y tuve resultados similares. Probé también con mi nuevo PC de sobremesa y más de lo mismo. Así que tocaba descartar problemas en el hardware.

El siguiente paso era comprobar el comportamiento de la E/S del disco bajo ciertas cargas, lo cual se puede simular con la herramienta fio. Mientras que hdparm suele venir de serie en cualquier distribución Linux, no es así el caso de fio, que se instala en Debian tan sencillo como así:

# apt-get install fio

El mejor escenario para comprobar el rendimiento de un disco es cuando se producen numerosos accesos aleatorios. Para ello, generé un fichero de simulación como el siguiente, en el que se transfieren 256 MB de datos:

# cat test.fio 
[random-read]
rw=randread
size=256m
directory=/tmp/test

A continuación, creé el directorio de pruebas:

# mkdir /tmp/test

e invoqué fio de la siguiente manera:

# fio test.fio

Esto genera gran cantidad de información, pero lo suficientemente clara como para darme cuenta de que el problema no estaba en la E/S del nuevo disco duro.

El último sospechoso era el sistema de ficheros. Estando seguro de que no tenía ningún fallo estructural (de eso se encarga el propio sistema de ficheros, ext3 en mi caso), pasé a comprobar el rendimiento del sistema de ficheros con la herramienta bonnie++, que nos ofrece completos (y complejos) informes con resultados.

Al igual que fio, bonnie++ no viene de serie en Linux, así que en Debian lo instalamos así:

# apt-get install bonnie++

Para utilizar bonnie++, necesitamos indicarle un directorio en el que pueda escribir sin problemas para poder hacer sus pruebas, así que como quería probar la partición en la que reside el sistema operativo, aproveché el directorio creado anteriormente en /tmp para ello.

# bonnie++ -u root -d /tmp/test

Al igual que con fio, con bonnie++ se obtiene gran cantidad de datos, que de nuevo fueron negativos a la hora de encontrar el culpable del bajo rendimiento del portátil. Tendré que buscar en otro sitio (¿poca RAM? ¿las exigencias de KDE? ¿un nuevo kernel?).

PD: Por cierto, para saber cómo se llama nuestro disco duro y nuestros sistemas de ficheros en nuestra instalación de Linux, basta con invocar el comando df -h.

Back In Time, copias de seguridad personales para escritorios Linux

Mon, 26 Nov 2012 09:41:56 +0000

Hace algún tiempo un conocido mío usuario de Mac me “vaciló” con Time Machine (creo que se llama así), un software que automáticamente guarda copias de seguridad con los cambios realizados desde la salvaguarda anterior (lo que se conoce como copia incremental). Al realizarse de forma transparente para el usuario y ser la recuperación de ficheros muy sencilla, se trata de una herramienta muy útil e indispensable en cualquier escritorio moderno. Siendo los linuxeros como somos, hubiera sido muy raro que no contáramos con nuestra propia alternativa, así que busqué y no tardé en encontrar nuestra propia “cápsula del tiempo”: Back In Time.

Back In Time es, como ya he dicho, una herramienta de copia de seguridad dirigida a los escritorios Linux (aunque se puede utilizar en servidores, existen herramientas más especializadas para dichos entornos como Bacula) que permite realizar copias incrementales de forma sencilla y transparente para el usuario. Como es habitual en Linux, cuenta con una utilidad de línea de comandos que es la que realiza todo el trabajo de gestión de las copias y un cliente gráfico (realmente dos, uno para KDE y otro para GNOME) que hace las veces de interfaz para el usuario.

Su instalación en Debian no puede ser más sencilla, basta con elegir el cliente y ejecutar el comando correspondiente. En el caso del cliente KDE:

# apt-get install backintime-kde

Si preferimos el cliente GNOME:

# apt-get install backintime-gnome

En ambos casos, se instalará automáticamente la herramienta de línea de comandos.

Lo siguiente es configurar adecuadamente Back In Time. Para ello, arrancamos el cliente gráfico y pulsamos sobre el icono de la llave inglesa para modificar nuestras preferencias. Realmente sólo es necesario especificar tres cosas: dónde guardar las copias, qué queremos salvaguardar y cual será nuestra frecuencia de copia (puede ser manual, en el arranque del equipo o cada cierto periodo de tiempo). Tan sencillo como esto. Existen además numerosas opciones que nos permitirán personalizar aún más nuestras copias de seguridad, como el purgado automático de copias antiguas o si se desea continuar con la copia aunque se hayan producido errores, pero para salir andando y contar con un sistema robusto y estable de copias de seguridad sólo hacen falta los tres parámetros mencionados.

No debemos olvidar que, en caso de problemas o de mal funcionamiento del cliente gráfico, contamos con la herramienta de línea de comandos (que es quien realmente hace el trabajo). Una vez me dejó de funcionar el cliente KDE tras una actualización y pude seguir con mis copias sin problemas hasta que se arregló el cliente gráfico gracias a la línea de comandos. Es cierto que es algo más difícil de utilizar, pero al ser capaz de actuar en base a nuestra configuración de Back In Time, basta con lanzar la herramienta y ella solita se encarga de todo.

Un truco final. Podemos mejorar nuestro sistema de copias de seguridad basado en Back In time si lo integramos con algún servicio basado en la nube, como Dropbox, Google Drive, Wuala o el basado en software libre ownCloud. Para ello, sólo tenemos que indicarle a Back In Time que el directorio en el que queremos almacenar las copias de seguridad esté dentro de los directorios a sincronizar del servicio en la nube de nuestra elección. Con esto tendremos un sistema de backups personales a prueba de bombas (o casi).

NUT, el sistema de gestión de SAIs para Linux

Fri, 09 Nov 2012 11:30:17 +0000

Otra cosa que quería hacer con mi nuevo PC doméstico es la de conectarle mi antiguo SAI (que tenía guardado desde que se me ocurrió pasarme a un portátil, algo que mi espalda me ha “agradecido” enormemente) y, aprovechando que tiene una conexión USB, gestionarlo desde el propio PC. Esto es algo que en Activa Sistemas solemos hacer en las implantaciones de servidores pero que curiosamente no he hecho nunca para un equipo de sobremesa. Para esta tarea tenemos en Linux una completísima herramienta de línea de comandos llamada NUT que permite conocer el estado del SAI e informarnos de los posibles eventos que puedan ocurrir, como un corte de suministro eléctrico.

Poner en marcha NUT es realmente sencillo, estando la única dificultad en la elección del driver para controlar el modelo de SAI concreto que tengamos. En Debian, instalar NUT es tan sencillo como utilizar el siguiente comando como administrador:

# apt-get install nut

Lo siguiente es editar una serie de ficheros de configuración, que se encuentran en /etc/nut, para personalizar el funcionamiento de NUT y adaptarlo a nuestras necesidades. El primero de estos ficheros es nut.conf, donde asignaremos el valor standalone a la variable MODE para indicar a NUT que se trata de un SAI local e independiente de red.

El siguiente fichero es ups.conf, en el que tendremos que elegir el driver adecuado para controlar nuestro modelo concreto de SAI. Para ello, añadimos a dicho fichero una sección como la siguiente:

[mi_sai]
 driver = usbhid-ups
 port = auto

El driver correcto lo podemos elegir del fichero /usr/share/nut/driver.list, pero es muy posible que no lo encontremos, ya que las marcas más populares en España no aparecen en dicha lista. Para ello tendremos que tirar de Internet, pero recomiendo probar con los drivers “megatec_usb” y “blazer_usb”, que suelen dar buenos resultados. Podemos comprobar si el driver es el correcto con el siguiente comando:

#/sbin/upsdrvctl start mi_sai

Si NUT se ejecuta adecuadamente, procedemos a pararlo para seguir con la configuración con:

#/sbin/upsdrvctl stop mi_sai

El tercer fichero a editar debería ser upsd.conf, pero como nuestra configuración es “standalone”, no hay que tocarlo. Pasamos entonces a upsd.users, donde se establecen los permisos del servicio NUT. Aquí definimos usuarios, contraseñas y privilegios, por lo que es importante que este fichero esté bien protegido en cuanto a permisos de acceso, aunque ya lo está de serie. Añadimos una sección como ésta:

[monsai]
 password = secreto
 upsmon master

Los usuarios que definamos en este fichero NO son de sistema, son sólo para su uso en NUT y por lo tanto deberían ser diferentes.

El último fichero a editar es upsmon.conf, donde detallamos los sistemas a monitorizar relacionando los usuarios anteriormente definidos con nuestro SAI. Siguiendo con nuestro ejemplo, añadiríamos líneas como la siguiente por cada usuario definido en NUT:

MONITOR mi_sai@localhost 1 monsai secreto master

En este fichero podemos definir asimismo los eventos de los que queremos recibir notificación (y cómo recibir esta notificación) y modificar el comportamiento de la monitorización de nuestro SAI, entre otras cosas.

Una vez finalizada la edición de los ficheros de configuración, ya sólo queda arrancar NUT con el siguiente comando:

/etc/init.d/nut-server start

La única pega que le podría poner a NUT (y que no es realmente culpa suya) es que no encuentro un buen cliente gráfico para trabajar con comodidad con él. Antiguamente utilizaba el fabuloso knutclient, que me permitía controlar diversos SAIs remotos a la vez, pero estaba diseñado para KDE3 y no existe versión compatible con KDE4. Si alguien conoce de algún cliente gráfico que realmente merezca la pena, estaré encantado de que me lo comente.

Habrá quien me recomiende utilizar las herramientas de monitorización que traen los propios SAIs antes que NUT, pero tengo mis motivos para preferir su uso antes que las aplicaciones de los fabricantes, algo de lo que hablaré en un próximo artículo.

Instalar el DNI electrónico español en Debian Wheezy

Fri, 02 Nov 2012 21:10:41 +0000

Recientemente he adquirido un nuevo PC de sobremesa para mi uso doméstico al que he instalado rápidamente mi sistema operativo favorito, Debian Linux. En esta ocasión, en vez de utilizar la versión estable actual (Squeeze), lo he hecho con la versión en desarrollo (Wheezy), ya que prefiero tener el software que uso lo más actualizado posible y de paso ayudo al proyecto Debian si encuentro algún fallo o defecto del que pueda informar.

Dado que se trata del PC de mi casa, es imprescindible para mí contar con soporte del DNI electrónico, de forma que pueda llevar a cabo desde el ordenador personal las aún escasas gestiones telemáticas disponibles en España. Estos son los pasos que he dado para conseguir dicho soporte, que por cierto son indiferentes de la arquitectura de Debian instalada (excepto a la hora de escoger los paquetes de software adecuados). En mi caso, elegí utilizar la arquitectura amd64 (64 bits) ya que mi nueva CPU lo permite.

En primer lugar debemos dirigirnos a la página web del Ministerio del Interior y descargarnos el paquete de soporte del DNI electrónico. Como no hay versión para Wheezy, tendremos que conformarnos con la de Squeeze, lo que nos provocará una serie de inconvenientes que comentaré a continuación junto con su solución. La dirección web para descargar el paquete correspondiente es la siguiente:

http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/distribuciones_linux.html

A continuación debemos descargarnos de Debian los paquetes de los cuales depende el anterior. Aquí surge el primer inconveniente, ya que algunos de dichos paquetes o bien no existen en Wheezy o los que sí existen no son compatibles. Así que debemos descargarnos los de Squeeze en su lugar. Pero antes procederemos a instalar como administrador del sistema los que sí son compatibles:

# apt-get install libpcsclite1 libopenct1 pinentry-qt

Si utilizamos Gnome en vez de KDE como escritorio, cambiamos el paquete pinentry-qt por pinentry-gtk2 (pinentry es el encargado de solicitarnos el PIN de nuestro DNIe cuando lo utilizamos).

Ahora pasamos a descargarnos los paquetes necesarios de Squeeze desde estas direcciones:

y a instalarlos junto con el paquete de DNI electrónico:

# dpkg -i Debian_Squeeze_opensc-dnie_1.4.8-2_amd64.deb opensc_0.11.13-1.1_amd64.deb libopensc2_0.11.13-1.1_amd64.deb mozilla-opensc_0.11.13-1.1_amd64.deb libssl0.9.8_0.9.8o-4squeeze13_amd64.deb

A continuación tenemos que configurar adecuadamente opensc para que utilice la librería libpcsclite1 correcta. Editamos el fichero /etc/opensc/opensc.conf, quitamos el comentario del parámetro provider_library y, según la arquitectura de nuestra Debian, le asignamos el siguiente valor:

32 bits: /usr/lib/i386-linux-gnu/libpcsclite.so.1
64 bits: /usr/lib/x86_64-linux-gnu/libpcsclite.so.1

Durante la instalación de los paquetes se nos informa de que para poder utilizar el DNI electrónico en Firefox, es necesario utilizar la opción “Registrar módulo DNIe PKCS#11” del menú “Aplicaciones -> Oficina”, algo que debemos hacer a continuación y sin el navegador abierto. Para aquellos que se lo estén preguntando, efectivamente bajo Linux sólo hay soporte de DNIe para el navegador Firefox. Una vez arrancado el navegador, procedemos a cerrarlo para que se instale el certificado raíz de la Dirección General de la Policía. Es posible que en este paso se nos solicite guardar el certificado en vez de instalarlo, por lo que a continuación lo importaremos en Firefox a través de “Preferencias -> Avanzado -> Cifrado -> Ver certificados -> Importar”.

Con esto debería ser suficiente para que funcione correctamente el DNI electrónico en Debian Wheezy, pero para estar completamente seguros en primer lugar miramos en “Preferencias -> Avanzado -> Cifrado -> Dispositivos de seguridad” si aparece en la lista “DNIe Modulo PKCS #11”. A continuación, comprobamos que el sistema reconoce sin problemas nuestro lector de tarjetas inteligentes. Para ello, instalamos los paquetes necesarios:

# apt-get install pcscd pcsc-tools

y ejecutamos el siguiente comando:

# pcsc_scan

el cual nos indicará si el lector ha sido reconocido y si hay introducida alguna tarjeta inteligente (como nuestro DNI electrónico). Incluso podemos probar en tiempo real a introducir y extraer el DNI para comprobar que dichas operaciones se detectan adecuadamente.

Ya sólo queda reiniciar la sesión de usuario y, tras acceder de nuevo al sistema, dirigirnos a algún sitio web que requiera del DNI electrónico y utilizarlo. Recomiendo utilizar la página que la propia Dirección General de la Policía facilita para esta comprobación:

http://www.dnielectronico.es/como_utilizar_el_dnie/verificar.html

Si la verificación es positiva, ya podemos utilizar nuestro DNIe con total garantía para realizar nuestras gestiones telemáticas, firmar documentos, etc.

Navegación anónima en Internet con Linux

Thu, 11 Oct 2012 11:23:45 +0000

Con el uso tan intensivo que le damos a Internet en la actualidad, hasta el punto de que nuestra vida diaria está muy integrada en la Red, es fundamental que nos preocupemos de salvaguardar nuestra intimidad de ojos ajenos. Una forma sencilla y completa de conseguirlo es combinando dos programas, Privoxy y Tor, de forma que el uso que le demos a Internet desde nuestro ordenador personal sea anónimo. Como creo que es importante conocer cómo funcionan las cosas para poder decidir si sirven o no, voy a profundizar en el trasfondo de estas tecnologías. Ni que decir tiene que ambas herramientas son de licencia libre.

En primer lugar presentemos a los actores. Privoxy es un proxy, es decir, un software intermediario entre el usuario y un servicio de red. De este modo, el usuario contacta con el proxy y es éste el que conecta con el servicio en nombre del usuario. Esto tiene numerosas aplicaciones, como acelerar la navegación web, filtrar el tráfico inadecuado, centralizar la gestión y el mantenimiento de un servicio o posibilitar la conexión a un servicio que de otra forma sería imposible.

Por otro lado tenemos a Tor, que es tanto una herramienta como una red abierta, diseñadas para ayudar al usuario a defender su privacidad y libertad personales. De este modo Tor permite proteger las comunicaciones de forma que nadie conozca nuestros hábitos de uso de Internet a través de cualquier servicio que dirijamos a través de Tor: navegación web, mensajería instantánea, redes sociales, etc.

Vemos como instalar y configurar ambas herramientas en un ordenador personal que corre Debian o alguna de sus derivaciones. Lo primero es proceder, como administrador del sistema, a instalar los paquetes necesarios:

# apt-get install privoxy tor

Este comando instalará Privoxy y Tor. Aunque existen clientes gráficos como TorK o Vidalia, lo cierto es que desaconsejo su uso por varios motivos: o bien están mal traducidos al español, o bien son complejos de configurar, o lo que es peor interfieren en el funcionamiento de Tor.

Una vez instalados los paquetes, Tor debería estar funcionando directamente. Al tratarse de un proxy SOCKS, para utilizarlo bastaría con configurar los programas que utilicemos en Internet y que entienda dicho protocolo con los siguientes datos:

Proxy SOCKS: 127.0.0.1 (para quien no lo sepa, esta IP siempre representa a nuestro propio equipo)
Puerto: 9050

¿Pero entonces para qué hemos instalado Privoxy? Para que traduzca automáticamente el protocolo HTTP al protocolo SOCKS, es decir, dirigiendo todo nuestra navegación web a través de Tor y consiguiendo así el ansiado anonimato web. Para ello tenemos que indicarle a Privoxy donde está Tor editando como administrador el fichero /etc/privoxy/config y añadiendo la siguiente línea:

forward-socks4a / localhost:9050 . (el punto no es una errata, hay que incluirlo también)

debajo de ésta otra:

listen-address localhost:8118

Sólo queda reiniciar Privoxy para que active la nueva configuración:

# /etc/init.d/privoxy restart

Para probar que ya podemos navegar de forma anónima, cogemos nuestro navegador favorito y lo configuramos para que utilice Privoxy como proxy de acceso a Internet. Por ejemplo, en el caso de Firefox, abrimos las Preferencias y nos dirigimos al apartado Avanzado, donde seleccionamos la pestaña Red. Allí tenemos un botón que nos sirve para configurar cómo Firefox se conecta a Internet. Una vez pulsado, en la ventana que aparece a continuación tenemos que seleccionar la opción “Configuración manual del proxy” y rellenar los campos de la siguiente manera:

Proxy HTTP: 127.0.0.1
Puerto: 8118
Usar el mismo proxy para todo: Sí

Una vez configurada, la pantalla debería quedar así:

Aceptamos y procedemos a comprobar que nuestra navegación ya es anónima conectándonos a https://check.torproject.org/ Si nos sale en pantalla un mensaje en verde diciendo “Congratulations. Your browser is configured to use Tor.”, eso quiere decir que lo hemos conseguido y que estamos usando la red Tor (en nuestro caso a través de Privoxy) para navegar de forma anónima por la Web.

La configuración de otros navegadores y otras herramientas es similar. Basta con probar con los datos ya mencionados, bien mediante Privoxy o directamente con Tor, para que todas nuestras comunicaciones sean realmente privadas.

Sólo una nota final. Tal y como avisan en el proyecto Tor, se trata de software experimental por lo que no debemos confiar en él si lo que buscamos es una anonimato a prueba de bombas.

Espero que esta receta os sea realmente útil, sobre todo para aquellos que tenéis menores en casa en edad de utilizar asiduamente Internet. Me gustaría conocer vuestras experiencias si decidís hacer la prueba con Tor y Privoxy.

PyODConverter, un conversor de formatos ofimaticos

Fri, 05 Oct 2012 13:24:17 +0000

Una de las funcionalidades más interesantes de OpenOffice.org y sus derivados (como LibreOffice) es la de funcionar como servidor. Aunque suene raro que una suite ofimática funcione como servidor, esta capacidad abre un enorme abanico de posibilidades. Algunos ejemplos que se me ocurren de utilidad son los siguientes:

En una migración a Linux puede facilitarnos la conversión de los formatos de nuestros documentos hacia estándares abiertos al poder realizar dicha operación de forma masiva.
Igualmente podemos realizar una conversión masiva de documentos al formato PDF en aquellas ocasiones en las que necesitemos preparar un buen conjunto de ficheros.
Podemos realizar conversiones al vuelo en una pasarela de correo hacia el formato ODT de todos los ficheros adjuntos que nos lleguen.
Como apoyo de un sistema de telepresencia y audio/videoconferencia en el que contemos con una pizarra digital y con compartición de ficheros, tratando así de forma automática y transparente los documentos subidos a la plataforma.

La manera más sencilla de aprovechar la capacidad de OpenOffice.org de funcionar en modo servidor es a través de PyODConverter, una herramienta desarrollada en Python que automatiza la conversión de documentos ofimáticos desde la línea de comandos.

PyODConverter exige dos requisitos básicos para poder funcionar correctamente: que en nuestro sistema estén instalados los módulos UNO de Python y que OpenOffice.org esté corriendo como servicio en el puerto 2002.

Para cumplir el primer requisito, en el caso de Debian es tan sencillo como ejecutar el siguiente comando como administrador del sistema:

# apt-get install python-uno

aunque lo más sencillo es utilizar el intérprete python que OpenOffice.org trae de serie.

En el caso del segundo requisito, basta con ejecutar el siguiente comando para que OpenOffice.org se ejecute como servidor:

# soffice "-accept=socket,port=2002;urp;"

El uso de PyODConverter es muy sencillo. Basta con invocarlo desde línea de comandos indicándole el fichero a convertir y el fichero a obtener. Veamos un ejemplo utilizando el intérprete Python que trae LibreOffice 3.6 de serie para convertir un fichero ODT a PDF:

$ /opt/libreoffice3.6/program/python DocumentConverter.py Informe.odt Informe.pdf

Como se puede ver, PyODConverter deduce los formatos con los que debe trabajar de las extensiones de los ficheros indicados en la línea de comandos.

Finalmente, PyODConverter tiene otra virtud muy interesante: la de poder ser invocado desde otros programas desarrollados en Python. Al funcionar como un módulo Python, se puede utilizar a través de un API muy sencillo, ampliando las posibilidades de nuestros propios desarrollos.

En definitiva, PyODConverter debe sin duda incluirse en nuestra “caja de herramientas” habituales por las enormes posibilidades que nos ofrece a la hora de trabajar con documentos ofimáticos.

Instalar un servidor de ebooks basado en Calibre y Debian Squeeze

Thu, 12 Apr 2012 20:21:25 +0000

Hace tiempo que quería montar un servicio interno para facilitar la gestión y el acceso al ingente fondo bibliográfico con que contamos en la empresa, compuesto principalmente por ebooks de licencia libre y complementado con algunos títulos comprados en conocidas tiendas online.

Buscando al respecto me topé con un interesante artículo que relataba paso a paso la instalación de Calibre en un servidor Ubuntu. Como en Activa Sistemas utilizamos preferentemente Debian en su versión estable (“Squeeze”), adapté un poco las instrucciones, le añadí algo de mi propia cosecha y ahora contamos con un fabuloso servidor de ebooks en nuestra red local.

Para los que no lo conozcan aún, Calibre (del cuál hablé hace tiempo en un artículo anterior) es posiblemente el software de gestión de libros electrónicos más completo del mercado y que cuenta con dos características que lo hacen aún más valioso y destacable frente a la competencia: es software libre y funciona en diversas plataformas. Entre sus numerosas funcionalidades hay una poco conocida pero muy útil si se le sabe sacar provecho: un servidor de contenidos accesible tanto vía web como a través de clientes ODPS y a través del cual es muy sencillo acceder tanto a los libros como a la metainformación que los acompañe. Este servidor de contenidos es fácilmente gestionable desde el propio interfaz gráfico de Calibre, pero en el caso que nos ocupa estamos hablando de un servidor que cuenta únicamente con la consola de texto.

El primer paso es instalar los paquetes de software necesario para que Calibre funcione adecuadamente. Para ello, abrimos una sesión como root en el servidor Debian y ejecutamos el siguiente comando:

# apt-get install xdg-utils imagemagick python-imaging python-mechanize python-lxml python-dateutil python-cssutils python-beautifulsoup python-dnspython python-poppler libpodofo-utils libwmf-bin python-chm

A continuación se lanza la instalación de Calibre, que no se realiza con un paquete Debian, sino descargándolo directamente del sitio web oficial. Este es uno de los pocos casos en que es recomendable hacerlo así. Ejecutamos el siguiente comando:

python -c "import urllib2; exec urllib2.urlopen('http://status.calibre-ebook.com/linux_installer').read(); main()"

y se siguen las instrucciones en pantalla. Recomiendo aceptar los valores por defecto que el instalador nos proponga, sobre todo en lo referente al directorio de instalación (/opt).

Con esto Calibre ya está instalado. Ahora lo que hay que asegurarse es de que es capaz de ejecutarse en un servidor sin consola gráfica y de que se inicia automáticamente en el arranque del sistema. Para ello crearemos un script de arranque al uso:

# nano /etc/init.d/calibre

en el que copiaremos el siguiente contenido:

{code}
#! /bin/sh
### BEGIN INIT INFO
# Provides: calibre
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Controls the Calibre content server
# Description: Controls the Calibre content web server
#
### END INIT INFO
# Original author: Alexandrdos Schillings
# Modifications: K-Light
#
# UPDATES:
# - Added #USERNAME and PASSWORD to DAEMON_ARGS
# - In version 0.7.27+ of calibre, the “auto reload” command has been unbundled from “–develop”
#
# Modifications: Marco Antonio Blanco (04/2012)
#
# UPDATES:
# - Changed “network” for “networking” in Required-Start field so it installs in Debian
#
# Please remove the “Author” lines above and replace them
# with your own name if you copy and modify this script.
# Do NOT “set -e”
# PATH should only include /usr/* if it runs after the mountnfs.sh script
#
#
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC=“Calibre Content Server”
NAME=calibre-server
DAEMON=/usr/bin/$NAME
PIDFILE=/var/run/$NAME.pid

# Edit the CONTENT variable below to point it to your library directory.
# Edit the PORT variable below to change the port the server will run on.
# Edit the MAX_COVER variable below to change the maximum size of a book cover image.
# Edit the #USERNAME variable below to your desired username
# Edit the PASSWORD variable below to your desired password
CONTENT=/home/user/calibre
PORT=8080
MAX_COVER=300x400
#USERNAME=books
PASSWORD=12345678

DAEMON_ARGS="–auto-reload –with-library=$CONTENT –pidfile=$PIDFILE –port=$PORT –max-cover=$MAX_COVER –username=$#USERNAME –password=$PASSWORD –daemonize"
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x “$DAEMON” ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon –start –quiet –pidfile $PIDFILE –exec $DAEMON –test > /dev/null || return 1
start-stop-daemon –start –quiet –pidfile $PIDFILE –exec $DAEMON – $DAEMON_ARGS || return 2
}

#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon –stop –quiet –retry=TERM/30/KILL/5 –pidfile $PIDFILE
RETVAL="$?"
[ “$RETVAL” = 2 ] && return 2

# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon –stop –quiet –oknodo –retry=0/30/KILL/5 –exec $DAEMON
[ “$?” = 2 ] && return 2

# Many daemons don’t delete their pidfiles when they exit.
rm -f $PIDFILE
return “$RETVAL”
}

#
# Function that sends a SIGHUP to the daemon/service
#
case “$1” in
start)
[ “$VERBOSE” != no ] && log_daemon_msg “Starting $DESC” “$NAME”
do_start
case “$?” in
0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;
2) [ “$VERBOSE” != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ “$VERBOSE” != no ] && log_daemon_msg “Stopping $DESC” “$NAME”
do_stop
case “$?” in
0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;
2) [ “$VERBOSE” != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc “$DAEMON” “$NAME” && exit 0 || exit $?
;;
restart)
#
# If the “reload” option is implemented then remove the
# ‘force-reload’ alias
#
log_daemon_msg “Restarting $DESC” “$NAME”
do_stop
case “$?” in
0|1)
do_start
case “$?” in
0) log_end_msg 0 ;;

log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo “Usage: $SCRIPTNAME {start|stop|status|restart}” >&2
exit 3
;;
esac
:
{/code}

Antes de guardar el script debemos asegurarnos de editar adecuadamente las variables CONTENT, PORT, MAX_COVER, #USERNAME y PASSWORD, que especifican respectivamente el directorio donde se encuentra la biblioteca digital, el puerto en el que escucha el servidor de contenidos, el tamaño máximo de las cubiertas de los libros, el usuario para acceder al servidor y su contraseña correspondiente.

A continuación habilitamos el script de arranque con los siguientes comandos:

# cd /etc/init.d/
# chown root.root calibre
# chmod 755 calibre
# insserv calibre
# update-rc.d calibre defaults

Ya sólo queda arrancar manualmente calibre:

# /etc/init.d/calibre start

y comprobar que funciona bien accediendo con un navegador a la siguiente URL:

http://servidor:8080

En ese momento debe aparecer un diálogo solicitando usuario y contraseña, por lo que introduciremos los que indicamos en la configuración del script de arranque. A continuación debe aparecer en la ventana del navegador la página principal de la biblioteca, que en estos momentos debe estar vacía.

Finalmente procederemos a llenar de libros la biblioteca y comprobar que podemos acceder a ellos vía web sin problemas. Lo primero será detener de nuevo el servidor Calibre:

# /etc/init.d/calibre stop

Para introducir libros en la biblioteca es imprescindible el uso del interfaz gráfico de Calibre. Mi recomendación en este sentido es instalar Calibre en un puesto de escritorio, compartir el directorio del servidor donde se va a almacenar la biblioteca a través de NFS (para escritorios Linux) o SAMBA (para escritorios Windows) y configurar Calibre para indicarle que la biblioteca está en dicho directorio compartido. De este modo, no tenemos que mantener dos bibliotecas (una en el servidor y otra en el escritorio que tendríamos que sicronizar a mano, lo cual sería absurdo) y se facilita la gestión de los ebooks.

Una ves populada la biblioteca con los primeros libros y la base de datos de Calibre con la metainformación correspondiente, arrancamos a mano de nuevo el servidor y accedemos al mismo mediante el navegador. Si todo ha ido bien, deberíamos ser capaces de consultar y descargar los libros, tanto desde el propio navegador como desde cualquier cliente ODPS (como Stanza para iPhone).

La única pega que tiene este método es que Calibre sólo acepta un usuario con su contraseña correspondiente, por lo que no podemos diferenciar entre diferentes usuarios. Si en nuestro caso queremos que todo el mundo acceda a la biblioteca digital, entonces lo mejor es dejar vacíos los campos #USERNAME y PASSWORD para acceder directamente a la misma sin autentificación.

Espero esta guía os sirva para montar vuestro propia biblioteca digital en red y que compartáis con todos vuestros comentarios, ideas y sugerencias al respecto.

Múltiples perfiles de usuario en Google Chrome

Fri, 31 Dec 2010 18:02:58 +0000

Ya han pasado varias semanas desde que me cambié a Google Chrome y poco a poco me voy acercando cada vez más a la funcionalidad y comportamiento de los que disfrutaba en Firefox. Una de las capacidades que más echaba de menos era la de poder utilizar varios perfiles de usuario diferentes en Chrome, incluso simultáneamente, de forma que pudiese dedicar cada perfil a tareas diferentes (navegación, promoción SEO, pruebas, ocio, etc.). Tras investigar el tema he conseguido lo que me proponía, aunque no es tan directo y sencillo como con Firefox. Espero que con la explicación que voy a dar a continuación le resulte más fácil hacerlo a todo aquél que quiera también varios perfiles en Chrome.

Antes de empezar con las instrucciones, es necesario aclarar que Chrome no cuenta con un gestor de perfiles como el de Firefox, sino que parte del trabajo de activación de los mismos hay que hacerlo desde línea de comandos, lo cual dificulta la tarea. Espero que esto no asuste a nadie, ya que mi propósito es precisamente facilitar el uso de perfiles en Chrome. Las instrucciones son para Linux, pero son fácilmente adaptables a otros sistemas operativos.

En primer lugar, es necesario saber que Chrome guarda sus preferencias en el directorio .config/google-chrome dentro del directorio doméstico del usuario. Para crear otros perfiles de usuario, recomiendo guardarlos igualmente en .config, utilizando para el directorio del perfil el nombre google-chrome seguido de un prefijo que distinga el objetivo de dicho perfil. Por ejemplo, si vamos a destinar el perfil a juegos web podemos llamarlo .config/google-chrome-juegos, si lo vamos a dedicar a la promoción SEO lo podemos llamar .config/google-chrome-seo y si lo que queremos es un perfil para realizar pruebas con el navegador (instalación de extensiones y plugins, visita de ciertas páginas web, etc.) podemos llamarlo .config/google-chrome-test, tan sencillo como eso.

Una vez creado el directorio deseado, hay que ejecutar Chrome para indicarle que queremos crear un nuevo perfil en el directorio recién creado. Si hemos utilizado los paquetes oficiales de Google para instalar Chrome en nuestro equipo, el ejecutable debe estar en el directorio /opt/google/chrome. Así, el comando a utilizar para crear nuestro nuevo perfil de pruebas es el siguiente:

/opt/google/chrome/chrome --user-data-dir="$HOME/.config/google-chrome-test" -first-run

Aconsejo ejecutar este comando desde un terminal de consola y no desde la opción “Ejecutar orden” de nuestro escritorio, ya que así podremos detectar si se produce algún problema. Con este comando le estamos indicando a Chrome el directorio a utilizar para el perfil de usuario y que lo inicialice al ser la primera vez que lo usamos. En este momento debería aparecer en pantalla el navegador como si fuera la primera vez que lo usamos. Podemos proceder a personalizarlo si queremos y después lo cerramos antes de seguir

Ya sólo queda crear un acceso directo al mismo para ejecutarlo bajo ese nuevo perfil cada vez que queramos. Podemos hacerlo donde nos sea más cómodo, ya sea el escritorio, los menús o el panel. Cuando lo creemos, hay que introducir en la orden a ejecutar lo siguiente:

/opt/google/chrome/chrome --user-data-dir="$HOME/.config/google-chrome-test"

y darle un nombre que nos permita diferenciarlo del perfil por defecto.

De este modo, podemos crear todos los perfiles que queramos y además ejecutarlos simultáneamente. Cada perfil tendrá sus propias extensiones, marcadores, contraseñas guardadas, preferencias, etc. Así, repartiendo el trabajo entre varios perfiles, evitaremos sobrecargar a Chrome y podremos seguir disfrutando de la rapidez tan gran navegador.

Migración de máquinas virtuales Xen

Fri, 26 Mar 2010 10:29:14 +0000

Esta semana nos hemos visto en la tesitura de tener que migrar unas máquinas virtuales basadas en Xen desde un servidor físico a otro con más recursos. A pesar de que Xen incluye herramientas especializadas para estas tareas, hemos preferido seguir nuestra propia “receta” en previsión de una serie de obstáculos que imaginábamos nos podíamos encontrar durante el proceso de migración. Voy a describir a continuación cuales han sido estos obstáculos y las soluciones que utilizamos en cada caso.

La situación era la siguiente: teníamos que migrar varias máquinas virtuales Xen que contenían sendos portales web desde un servidor físico a otro. Aquí se nos presentaba la primera dificultad. A pesar de que las arquitecturas hardware de los servidores eran prácticamente idénticas, no era así en el caso de los sistemas operativos, ya que el origen tenía instalado Debian 4.0 y el destino Debian 5.0. Habrá quien piense que soy un exagerado y que eso no es tanta diferencia. Nada más lejos de la realidad, ya que las versiones de núcleo Linux y del software de virtualización Xen son diferentes, lo que de algún modo impedía el correcto funcionamiento de la herramienta “xm migrate”, que fallaba inmediata e indefectiblemente con un error críptico cada vez que era invocada desde la línea de comandos del servidor de origen. A pesar de preparar concienzudamente ambos servidores para permitir la migración al vuelo, la herramienta propia de Xen no hacía su trabajo.

La solución fue relativamente sencilla. Todo consistió en hacer lo mismo que se suponía debía hacer “xm migrate” pero a mano y paso a paso. Lo primero era parar la máquina virtual con “xm shutdown”, para proceder a continuación a su copia al servidor destino. Aunque nosotros lo hicimos por SSH, las posibilidades aquí son amplias (FTP, NFS, SMB, USB, etc.). La copia de cada máquina virtual comprendía el fichero imagen del disco principal, el fichero imagen de la memoria de intercambio o swap y el fichero de configuración correspondiente.

Una vez copiados los ficheros al servidor destino, el siguiente paso es arrancar las máquinas virtuales una a una con “xm create”. Sin embargo, no iba a ser tan sencillo, ya que Xen se quejó de que le faltaban el núcleo Linux y el initrd de las máquinas virtuales, que procedimos a copiar desde el servidor origen, con lo que el arranque se produjo después sin más problemas.

Para finalizar, quedaban por ajustar algunas cosas, como la configuración de red de Xen (en el servidor origen se usaba el modo bridge mientras que en el destino estaba activo por defecto el modo NAT), la actualización de los DNS de los portales web con la IP del servidor destino y la configuración del proxy inverso residente en los servidores físicos que gestiona las peticiones realizadas a cada máquina virtual.

De esta historia puede obtenerse una valiosa lección. Aunque cualquier sistema de virtualización, incluyendo Xen, hacen su trabajo a un buen nivel, podemos encontrarnos en cualquier momento una serie de problemas que impidan su adecuada gestión y mantenimiento, más teniendo en cuenta lo delicados y exigentes que son. En este sentido, es fundamental tener unos profundos conocimientos y experiencia en administración de sistemas en general y en el sistema de virtualización de nuestra elección en particular para evitarnos males mayores y salir airosos de cualquier situación.

Planificación de proyectos basados en Typo3

Thu, 28 Jan 2010 21:47:57 +0000

Aunque existen numerosas metodologías para llevar a cabo un proyecto de desarrollo de software, siendo una de las más populares la METRICA v3, todas se pueden resumir en seis fases consecutivas: Análisis, Diseño, Implementación, Pruebas, Puesta en marcha y Garantía. Todas estas fases se realizan de la misma forma independientemente del producto final y de las herramientas utilizadas en su desarrollo excepto en el caso de la Implementación, cuya evolución se ve directamente afectada por el entorno de trabajo y el software a obtener. En este artículo voy a explorar cómo enfocar la fase de Implementación cuando el desarrollo está basado en Typo3.

Para ilustrar cómo se ve afectada la fase de Implementación, baste recordar que al tratarse de un CMS, Typo3 nos va a restringir el tipo de herramientas y de lenguajes de programación a un entorno muy concreto, que evidentemente es el de la Web. Además, la forma de trabajar de Typo3 y sus peculiares características restringen aún más las metodologías y usos disponibles a la hora de acometer el proyecto.

Basándonos en nuestra experiencia, la fase de Implementación de un proyecto basado en Typo3 puede subdividirse en las siguientes tareas, que además pueden llevarse a cabo concurrentemente gracias a la separación de diseño, contenido y lógica de negocio en la que se basa el funcionamiento de este CMS:

- Instalación del motor de Typo3: Esta tarea es la primera que debe hacerse, ya que sin un Typo3 instalado no se pueden empezar las demás tareas. Básicamente consiste en descargarse tanto el motor como la estructura básica (un paquete llamado dummy), descomprimirlos en el servidor de hospedaje y ejecutar el asistente web de instalación. ¡Voilá, ya tenemos un CMS en perfecto funcionamiento! En este sentido debo recomendar el uso de Linux como sistema operativo del servidor, ya que gracias al uso de enlaces simbólicos posibilita el mantenimiento de varios motores a la vez y facilita la actualización de versión, pudiéndose volver atrás en cuestión de minutos si algo falla en el proceso o el resultado no es el deseado.

- Creación del árbol: La siguiente tarea debería ser la de generar el árbol que representará al nuevo sitio web, cuyas ramas se convertirán en los menús y cuyas hojas serán las páginas de contenido. Aunque se recomienda cierta planificación previa, gracias a las posibilidades de edición del panel de control de Typo3 es relativamente sencillo modificar un árbol existente. No olvidar que es posible crear hojas que sean accesibles pero ocultas en los menús e incluso completamente inaccesibles. A partir de aquí ya es posible realizar el resto de tareas de forma concurrente.

- Integración de diseño: Consiste en generar a partir del diseño gráfico que tendrá el nuevo sitio web una plantilla HTML con una serie de marcas de Typo3 intercaladas que le indicarán al motor dónde insertar el contenido a mostrar en el navegador, ya sea estático o dinámico. Quiero destacar que Typo3 es capaz de mantener y utilizar varias plantillas tanto para todo el sitio web como para subzonas específicas del mismo.

- Inserción de contenido: Gracias al editor visual enriquecido que incorpora Typo3, esta tarea es realmente sencilla y se reduce prácticamente tanto a escribir directamente en dicho editor como a copiar y pegar el texto desde otras fuentes, como ficheros ofimáticos propios u otras páginas web. En este sentido el editor visual puede ser tanto una bendición como un engorro, ya que suele respetar el formato original del texto.

- Instalación de extensiones: Una de mis tareas favoritas es la de rastrear el enorme repositorio de extensiones de Typo3 en busca de aquellas que doten de funcionalidades útiles a un nuevo sitio web. La instalación en sí no puede ser más sencilla, ya que consiste simplemente en buscar en el instalador la extensión deseada y pulsar en el botón de instalación. Lo que ya no es tan sencillo es echarla a andar, ya que nos podemos encontrar mil y un problemas, desde aquellas que están pésimamente documentadas a aquellas que están diseñadas para versiones concretas de Typo3 y PHP, pasando por otras que necesitan de tanto trabajo previo y de tal complejidad que la relación esfuerzo-resultado se resentirá gravemente. La experiencia nos dictará finalmente cuales son las extensiones que merecen la pena, terminando en nuestras manos una lista de las favoritas que utilizaremos una y otra vez en nuestros proyectos.

- Desarrollo de personalizaciones: Typo3 tiene muchas características destacables, pero una de las mejores es sin duda las amplias posibilidades de personalización que ofrece gracias a la disponibilidad del código fuente en PHP, de un lenguaje interno propio llamado TypoScript que permite modificar el comportamiento de prácticamente todos y cada uno de los aspectos de Typo3 y a un fabuloso asistente de desarrollo de extensiones llamado “Extension Kickstarter” (es una extensión en sí mismo). Con todas estas herramientas podemos dotar al sitio web de todas aquellas funcionalidades que queramos y que no ofrece ninguna extensión del repositorio, bien desde cero o partiendo de alguna existente.

Siguiendo esta guía, en Activa Sistemas hemos conseguido hasta la fecha llevar a buen puerto los diversos proyectos basados en Typo3 que hemos realizado, en plazo y con la entera satisfacción de nuestros clientes. Es por ello que la recomiendo a todo aquel que se enfrente a un proyecto de similares características, adaptándola a sus propias necesidades.