Sistemas Informaticos on Marco Antonio Blanco

Truco Linux: Cómo actualizar el contenido de ficheros de texto automáticamente con sed

Fri, 07 Nov 2014 10:21:34 +0000

Los administradores de sistemas Linux nos enfrentamos constantemente al problema de tener que cambiar un valor en varios ficheros de configuración a la vez, los cuales tienen siempre el formato de texto plano. Por ejemplo, si cambiamos la IP o el nombre de un equipo, hay que recorrerse todo el directorio /etc en busca de ficheros que contengan una referencia al dato antiguo y cambiarla por el nuevo. Esto, que evidentemente es un proceso tedioso si hay que hacerlo a mano, podemos afortunadamente automatizarlo con una de las herramientas de procesamiento de texto que Linux incluye de serie y que ha heredado de Unix: sed.

sed es una utilidad de línea de comandos y nos permite con una sintaxis muy sencilla sustituir una cadena de texto por otra, que incluso permite utilizar expresiones regulares para aplicar la sustitución a patrones de cadenas. La operación más básica de sed tendría la siguiente forma:

# sed 's/antigua/nueva/g' fichero_original > fichero_nuevo

Si no queremos crear un fichero nuevo sino cambiar el existente, incluimos el parámetro -i:

# sed -i 's/antigua/nueva/g' fichero_original > fichero_nuevo

Veamos entonces el ejemplo mencionado de tener que sustituir el nombre del sistema por uno nuevo. Para ello, realizaremos una búsqueda en /etc y modificaremos los ficheros que contengan la cadena a cambiar.

# grep -r -H equipo1 /etc | cut -f 1 -d ":" | xargs sed -i 's/equipo1/equipo2/g'

En la línea anterior combinamos varios comandos Linux para prepara la lista de ficheros a procesar y obtener el resultado deseado con sed:

grep hace una búsqueda recursiva (-r) en el directorio /etc e imprime los nombres de lo ficheros coincidentes (-H).
cut extrae la primera columna (-f) indicando : como separador de las mismas (-d).
xargs recibe la lista de ficheros y se le pasa a sed uno a uno (si no sed actuaría sobre toda la lista a la vez, lo cual no puede hacer).
Finalmente sed realiza la sustitución.

Este truco es también muy útil para los desarrolladores web, por ejemplo para actualizar plantillas o código fuente. Un aviso: hay que asegurarse de que la cadena a sustituir SÓLO aparece en los ficheros que nos interesan, ya que podemos sufrir el efecto secundario de cambiar lo que no deberíamos.

Espero que os sea de utilidad. Hasta el truco de la semana que viene.

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.

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.

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: 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.

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.

Reestructuración de un sistema informático

Fri, 11 Jan 2013 13:12:59 +0000

Tal y como hemos anunciado hoy en nuestra web corporativa, la Federación Andaluza de Empresas Cooperativas de Trabajo Asociado (FAECTA) nos ha adjudicado la gestión de su sistema informático en los próximos dos años. Aparte de la alegría que supone, esta concesión implica además una gran cantidad de trabajo al inicio del proyecto, ya que el primer paso que damos en un servicio de asistencia informática es el de la reestructuración de los activos TIC del cliente en busca de una estabilidad, robustez, seguridad y eficiencia que permita traducir el uso de las herramientas informáticas en un aumento de la productividad de la entidad y en un notable descenso de las incidencias técnicas. Veamos en las siguientes líneas cómo lo llevamos a cabo en Activa Sistemas.

Existe un procedimiento previo indispensable e ineludible para llevar a buen puerto la reestructuración: la realización de una profunda auditoría del sistema informático que incluya un detallado inventario hardware y software y que permita descubrir las fortalezas y carencias del mismo a nivel de funcionalidad, rendimiento y seguridad. Con esta información en nuestro poder se procede a redactar una serie de medidas y propuestas a desarrollar para potenciar y proteger las fortalezas y resolver las carencias.

Aunque a priori es imposible saber con lo que uno se va a encontrar en un sistema informático con el que se tiene contacto por primera vez, es igualmente cierto que suele haber una serie de puntos a resolver y de medidas a tomar comunes a todos los proyectos (al menos esa es nuestra experiencia hasta la fecha).

Elaboración de políticas de uso y seguridad de los activos TIC. Su importancia radica en que sin estos documentos es prácticamente imposible conseguir la deseada estabilidad del sistema informático que permita aumentar la productividad y disminuir los costes de mantenimiento. Es fundamental que las políticas estén avaladas por la gerencia de la entidad para que tengan validez operativa y que no entren en conflicto con la normativa vigente para que tengan validez legal (por ejemplo, un error muy común es incluir penalizaciones a los usuarios por el mal uso del sistema, algo que corresponde realmente al reglamento interno, los estatutos de la entidad y la legislación vigente).
Saneamiento de la red local a nivel físico, tanto cableado como inalámbrico. La base de un sistema informático es su red local física y, si esta se encuentra en mal estado o no da el rendimiento adecuado, todo el sistema se resiente drásticamente. Por ello hay que asegurarse de que todos los nodos de la red cuentan con el acceso de calidad y ancho de banda que requieren para llevar a cabo sus funciones, preferiblemente cableado, relegando el acceso inalámbrico a los casos justificados.
Renovación del parque de puestos de trabajo. Para que un ordenador de escritorio sea realmente productivo como herramienta de trabajo, es imprescindible que su ciclo de vida no supere los cinco años (al meno, a día de hoy). Por algo será que en España las normas contables consideran que su amortización está completa a los tres años…
Implantación de un sistema de seguridad perimetral y de gestión de las comunicaciones. Con el aumento año tras año de las ciberamenazas, cada vez es más imprescindible con un sistema que no sólo gestione el acceso a Internet (y que incluso lo acelere en la medida de lo posible) sino que además permita conectar de forma segura y privada a usuarios remotos y que nos defienda de problemas externos, desde el spam hasta intrusiones, pasando por malware y contenido no deseado.
Implantación de un servidor centralizado de usuarios, datos y aplicaciones. He visto problemas y carencias de todo tipo, pero el que más me horroriza y que hace que me eche las manos a la cabeza es cuando me encuentro que la empresa no tiene servidor de ningún tipo y que toda la información se encuentra repartida en los distintos puestos de trabajo. Con un servidor central es posible controlar el acceso de usuarios a ficheros, la gestión de recursos compartidos e incluso permitirnos una intranet para el acceso desde cualquier sitio al correo, la agenda, las tareas, etc.
Implantación de un sistema de copias de seguridad.La gente no se lo cree, pero las desgracias ocurren y, una vez que se producen, es demasiado tarde y sólo queda lamentarse y asumir las consecuencias si no se han tomado las medidas oportunas. Por ello, al igual que se contratan diversos seguros para proteger los activos de una empresa, también hay que implantar un completo sistema de salvaguarda de la información de la entidad, contemplando desde los dispositivos de copia en sí (por ejemplo, un NAS o un espacio virtual en la nube) hasta la política adecuada a las necesidades locales.
Homogeneización de sistemas operativos, aplicaciones y herramientas. Un parque muy heterogéneo de programas, tanto a nivel de sistema operativo como de aplicaciones, conlleva ciertos problemas como una gestión compleja del sistema y una mayor probabilidad de fallos y averías. Sólo hay que pensar en mantenimiento, actualizaciones, incompatibilidades, etc., para darnos cuenta de lo crítico de este punto. Una sugerencia que podemos hacer en este punto es la de migrar a software libre y, si es posible, incluso a Linux.
Unificación de los servicios de Internet. Es demasiado común encontrarse con que la web corporativa está alojada en un proveedor y el correo electrónico en otro (usualmente, la misma empresa de telecomunicaciones que provee del acceso a Internet). Aparte de la complicación en la gestión que ello supone, implica un mayor gasto que si se unificara todo bajo un mismo proveedor y servicio de alojamiento.
Actualización del sitio web corporativo. Si poco caso se le echa al alojamiento, lo mismo podemos decir del contenido, es decir, el sitio web en sí. Una vez instalado por primera vez, las empresas suelen olvidarse del él, lo que agrava el gasto que supone el alojamiento. Para que un sitio web sea efectivo, es vital mantenerlo vivo, ya sea a nivel de contenidos para mejorar el posicionamiento en buscadores, a nivel de funcionalidades para ofrecer un mejor servicio a los visitantes como a nivel de motor para facilitar su gestión y resolver problemas de funcionamiento y seguridad.
Elaboración de un plan formativo de los usuarios para renovar y poner al día sus conocimientos TIC. Si se desea disminuir el número de incidencias técnicas y aprovechar los recursos TIC al máximo, es evidente que los usuarios deben estar capacitados para ello. Un plan formativo adecuado a las necesidades de la entidad y diseñado de forma dinámica y efectiva es una garantía de éxito.
Implantación de nuevos servicios y funcionalidades. Una vez resuelto todo lo básico, es el momento de mirar al futuro y de proponer novedades y mejoras TIC que supongan un salto cualitativo en la productividad de la entidad: software libre, cloud computing, teletrabajo, movilidad, etc.

No nos hemos encontrado aún una empresa u organización que necesite de todas estas medidas porque efectivamente sufra de todas las carencias correspondientes (sencillamente dudo que pudiesen funcionar), pero la mayoría sí que han necesitado de buena parte de estas soluciones. Es entonces de suma importancia que los responsables de la entidad sean capaces de ver que se trata de medidas necesarias (al fin y al cabo, un aprovechamiento óptimo de las TIC supone una enorme ventaja competitiva) y que la inversión sensata en TICs es eso, una inversión y no un gasto.

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.

Por qué es NUT mejor que la solución del fabricante

Mon, 19 Nov 2012 11:01:12 +0000

En el artículo anterior presentaba a NUT como una gran solución de gestión de SAIs para Linux y afirmaba que era mejor que utilizar el software que el propio fabricante del SAI suele incluir de serie, aunque quedó pendiente exponer los motivos para tal afirmación.

1. Se trata de software libre. De este modo, al usar NUT nos evitamos introducir en nuestros sistemas programas que funcionan como verdaderas “cajas negras” y que en cualquier momento pueden dejar de funcionar (por ejemplo, ante una actualización del sistema operativo que cambie una librería).
2. Está en continuo desarrollo. Así, NUT siempre está actualizado, dando soporte cada vez a más modelos de SAI, ofreciendo nuevas y mejoradas funcionalidades y resolviendo los errores que puedan surgir.
3. Es moderno. No sólo la lista de SAIs soportados es impresionante sino que además las capacidades que incluye de serie son más de las que uno podría esperar en su software de este tipo.
4. Trabaja en red. El hecho de que NUT incluya un servicio de red permite gestionar un SAI de forma remota y transparente incluso desde fuera de la red local a través de una VPN.
5. Es una herramienta de línea de comandos. Como es habitual en Unix y Linux, esta característica no sólo permite utilizar el cliente gráfico que uno quiera y se adapte mejor a las necesidades propias, sino que además facilita la integración de NUT en scripts y en herramientas de administración de sistemas.
6. Homogeneidad. Con una sola aplicación e interfaz es posible administrar y gestionar todos los SAIs a nuestro cargo, sin tener que usar una herramienta específica por cada modelo de SAI.

Creo que con esto está todo dicho. NUT no sólo es una gran herramienta, es la MEJOR herramienta de su tipo en Linux.

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.

El teletrabajo, solución a los estragos de la gripe A

Fri, 14 Aug 2009 10:12:52 +0000

En este primer artículo tras la vuelta de las vacaciones he querido hablar de la gripe A, un tema candente que preocupa a todo el mundo, y de cómo la tecnología puede ayudarnos a minimizar su impacto en las empresas y organizaciones ahora que se acerca el Otoño, época en la que se prevee un importante aumento en el número de casos de personas afectadas debido al descenso de las temperaturas y al hecho de que la mayoría de la población se encuentra de vuelta a sus quehaceres diarios.

¿De qué forma nos podemos valer las empresas de la tecnología para enfrentarnos a un brote de gripe A en nuestro lugar de trabajo? La solución pasa por implantar mecanismos que posibilite el teletrabajo a aquellos trabajadores que podrían desarrollar sus tareas fuera de las instalaciones de la empresa, como el personal administrativo, los comerciales, los jefes de departamento o los técnicos de posventa. Al facilitar la ausencia de parte del personal, se reduce el ámbito de contagio de la enfermedad a la vez que dicho personal sigue desarrollando sus laboras remotamente y la empresa no sufre de un paro productivo que podría costarle muy caro. El teletrabajo tiene además otra ventaja, y es que potencia la movilidad en aquellos trabajadores en los que puede ser de gran ayuda a su trabajo (como los mencionados comerciales) al poder utilizarse cualquier dispositivo para conectarse a la empresa, ya sea un ordenador de sobremesa, un portátil, una agenda o un iPhone, como es mi caso.

A pesar de que a primera vista pudiese parecer lo contrario, la implantación de un sistema de teletrabajo en una empresa no es tan complejo como se cree. Basta con decidir en un análisis preliminar los mecanismos de conexión remota a la empresa, que por lo general se realizarán mediante las llamadas “redes privadas virtuales” (también conocidas VPN por sus siglas en inglés y que no son más que el establecimiento de conexiones privadas mediante una combinación de software y hardware a través de líneas públicas de comunicación como Internet), los sistemas de autentificación de los usuarios y los servicios y datos a los que accederán los usuarios remotos.

Como ejemplo, el caso más sencillo consiste en la instalación de un router con capacidades VPN en la empresa al cual se conectarán los usuarios para acceder al correo electrónico, ficheros, software de gestión y otros servicios que la empresa tenga instalados, como un sistema de mensajería instantánea, una intranet o un fax electrónico. El coste de dicho router suele rondar los 250 EUR, a los que habría que sumar los costes de instalación, integración, puesta en marcha y formación del personal, lo que puede suponer unos costes totales de entre 750 y 1.200 EUR.

Sin embargo, esta inversión puede ser inútil si no se tiene en cuenta el aspecto más fundamental cuando se instala un sistema de teletrabajo: la seguridad. Hay que considerar que se está habilitando una “puerta” al exterior de la empresa, lo que puede facilitar el acceso no autorizado a los datos y recursos telemáticos de la misma si no se planifica bien la seguridad de todo el sistema. En un próximo artículo profundizaré en esta cuestión, pero adelantaré que hay tres aspectos a tener en cuenta: la seguridad de la comunicación, la seguridad en el acceso al dispositivo de conexión y la seguridad en el acceso a los datos y recursos de la empresa.

La necesidad de monitorizar un sistema informático

Thu, 22 Jan 2009 18:47:53 +0000

Los objetivos de una infraestructura de monitorización de sistemas informáticos son principalmente la prevención de incidencias y conocer el aprovechamiento de los recursos TIC disponibles. Dado que estos objetivos son importantes en cualquier entidad independientemente de su tamaño, es evidente que toda organización debería contar con su propio sistema de monitorización.

Aunque parezca lo contrario, implementar un buen sistema de monitorización no es una tarea tan difícil como exigente en su ejecución. El primer paso consiste en realizar un análisis detallado del sistema informático a monitorizar para, entre otras cosas, detectar los sistemas críticos (tanto máquinas como servicios) para el buen funcionamiento de la entidad y formular políticas de actuación frente a incidencias en dichos sistemas. Por ejemplo, puede ser interesante asegurarse de que una aplicación web corporativa esté siempre en marcha o estar sobre aviso de emergencias en el sistema de correo electrónico de la organización. Aquellos a los que esto les suene a “plan de emergencias frente a desastres” no andan muy desencaminados.

A continuación se debe redactar el plan de instalación e integración del nuevo sistema de monitorización en nuestro sistema informático, para lo cual es imprescindible respetar estas tres reglas:

Mantener las medidas de seguridad existentes.
Minimizar el impacto en el propio sistema a estudiar.
Minimizar el número de sistemas intermedios entre el sistema de monitorización y los sistemas críticos.

Por cierto, dicho plan estará incompleto si no se contempla qué ocurre o cómo actuar si el sistema de monitorización deja de estar disponible, es decir, hay que contestar a la pregunta ¿quién monitoriza al monitorizador?. Aunque parezca una verdad de Perogrullo, no todo el mundo tiene en cuenta este importante detalle.

El último paso es elegir un buen paquete de software especializado y proceder a su instalación y configuración. Afortunadamente, contamos con fabulosas opciones de licencia libre como Nagios o Zabbix que ofrecen jugosas ventajas frente a sus alternativas comerciales, destacando especialmente su inmensa flexibilidad para poder monitorizar todo lo que queramos en el modo en que así lo necesitemos.