El blog de Lucas

…y es por eso que en Capital Federal están organizando una fiesta especial para celebrar el día del Administrador de Sistemas!

Lástima que estoy levemente lejos, pero pienso que ningún SysAdmin capitalino que se precie, debería faltar a semejante evento.

Un buen SysAdmin es aquel que es invisible a sus usuarios, y eso es una maldición ya que nadie aprecia realmente el trabajo de un SysAdmin y sólo nos dedican pensamientos (de enojo) cuando las cosas van mal, es por eso que el próximo Viernes 31 de Julio, si estás leyendo esta página, al menos sentí gratitud porque lo estás haciendo gracias al buen trabajo de uno o más SysAdmins.

Si querés realmente demostrar tu aprecio hacia nosotros, lo que podés hacer es simple: aparecete en la fiesta y pagale unas buenas birras al SysAdmin que te parezca!

Dejo un video alusivo para sensibilizar a la población…

PD: Gracias Nelson por la noticia!

GNU/Linux, SysAdmin sysadmin day

Hace algunas semanas me puse a investigar un poco sobre el despliegue de aplicaciones hechas con Ruby on Rails, ya que en mi laburo vamos a comenzar a desarrollar algunas apps en esta plataforma, y quería tener cocinado el tema de infraestructura antes que sea necesario ponerlas en producción.

Leyendo variados artículos en la blogósfera, he visto que una buena dupla como software “plataforma base de Rails” es el uso de Mongrel y Nginx, siendo el primero el servidor de aplicaciones y el último el frontend HTTP. Esta combinación nos permite instalar una aplicación web en un servidor de recursos no muy abundantes, y aún así servir a una buena cantidad de usuarios concurrentes. Obvio que no he hecho métricas propias, pero Internet está lleno de este tipo de análisis.

El problema entonces se divide en dos:

• Instalar el software base necesario en los servidores
• Realizar el despliegue (deploy) de la aplicación en si

En este artículo vamos a ver cómo hago yo para mantener el software base (mongrel, nginx, gemas, …) instalado y configurado en los servidores que correspondan. Esta tarea la hago con Puppet, una herramienta que en un artículo anterior he comentado que me permite administrar una gran cantidad de servidores sin tener que volverme un esclavo. Leer más…

GNU/Linux, Internet, SysAdmin capistrano, puppet, ruby on rails

Una de las grandes decepciones que he tenido en los últimos tiempos, es ver cómo Amarok: el mejor software de gestión de música de todos los tiempos, ha pasado a la mediocridad cuando llegó la versión 2.x.

Si bien hoy en día uso como notebook personal una Macbook con su sistema operativo y gestor de música de fábrica, el Amarok 1.4 sigue siendo el mejor gestor que he usado y la segunda decepción que tuve fue cuando vi que Ubuntu 9.04 Jaunty trae la versión de Amarok 2.x, nombre clave: bonito, barato…pero malo.

Me ha tocado hacer un orgulloso downgrade a la versión 1.4, y lo pude hacer gracias a la inteligencia colectiva que promueve la blogósfera, así que paso a describir las simples instrucciones para que todo aquel que esté sufriendo el Amarok 2.x, pare de sufrir!

Primero agregamos una fuente de paquetes al apt, ejecutar estos comandos desde un Terminal en el entorno gráfico:

gksu gedit /etc/apt/sources.list.d/amarok.list

…agregando la siguiente línea:

deb http://ppa.launchpad.net/bogdanb/ppa/ubuntu jaunty main

Luego, agregamos la clave del paquete a nuestro anillo:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com \
0x1d7e9dd033e89ba781e32a24b9f1c432ae74ae63

Y por último, desinstalamos amarok 2.x para darle la bienvenida al 1.4:

sudo apt-get update
sudo apt-get remove amarok
sudo apt-get install amarok14

Eso es todo. Más simple, imposible.

Realmente, el amarok 2.x parece un insulto a los usuarios de Amarok, quizás deberían dejarlo para comenzar la release 3.x, nombre clave: la anterior era una joda!

GNU/Linux, Software Libre

No es noticia nueva que tener una computadora conectada a Internet la deja expuesta a una serie de riesgos de seguridad, y es por eso que los administradores de sistemas, normalmente tomamos una serie de medidas básicas preventivas para evitar un disgusto posterior.

Si bien mis servidores normalmente tienen un nivel de seguridad más que aceptable, los molestos bots de estas personas no dejan de intentar adivinar las claves de mis cuentas para poder acceder con privilegios de administrador a los servidores. Esto me causa un problema, pero no de seguridad, sino que me ocupan los recursos que tengo para otras cosas y a veces hasta producen enlentecimientos notables en los servidores virtuales mas pequeños.

Es por esto que me puse manos a la obra, a averiguar alguna manera de mantener a raya a estos muchachos, y lo que me encontré fue con un software pensado justamente para esto: fail2ban.

Este programa está ya listo para ser instalado y usado en mi distribución favorita (Debian GNU/Linux), y al instalarse comienza a chequear los accesos fallidos de conexión por SSH, dejando 6 intentos y prohibiendo el acceso por IP por 10 minutos. Para prohibir el acceso utiliza reglas de iptables, y su funcionamiento es en modo daemon, un pequeño programa queda corriendo (muy chiquito, sirve hasta en VPS de 256 MB de RAM) revisando los distintos archivos de registros de sistema.

Lo interesante además es que trae una serie de plantillas para poder chequear otros tipos de servicios como FTP, SMTP, Web, etc. todo esto mediante reglas de análisis y acciones acordes, que se pueden personalizar para un uso específico.

En resumen, una muy simpática herramienta para los administradores de sistemas GNU/Linux, fácil de instalar y poner a funcionar, y el beneficio es enorme.

¡Que la disfruten!

GNU/Linux, Internet, SysAdmin bot, fail2ban, iptables, ssh

Hoy me encontré con un problema en un simple script que hice para backupear algunas bases de datos MySQL:

#!/bin/sh
# Hace dumps de MySQL de las BBDDs especificadas

DBS="db1 db2 dbN"
DUMPDIR="/root/mysql-dumps"
ADMIN="alertas@midominio.com"
REPORT="/tmp/mysql-dump-bases-importantes.$$.log"
ERRORS=0
HOSTNAME=`hostname -f`

cd $DUMPDIR

for db in $DBS
do
        /usr/bin/mysqldump -Q $db | gzip -9 > dump-$db-`date +"%F_%T"`.sql.gz
        ERR=$?
        if [ "$ERR" == "0" ]; then
                echo "Dumping database '$db' done OK" >> $REPORT
        else
                echo "Dumping database '$db' FAILED" >> $REPORT
                ERRORS=1
        fi
done

if [ "$ERRORS" == "0" ]; then
        cat $REPORT | mail -s "MySQL Dumps on $HOSTNAME: OK" $ADMIN
else
        cat $REPORT | mail -s "MySQL Dumps on $HOSTNAME: ERRORS" $ADMIN
fi

rm $REPORT

Este script usa mysqldump para sacar una imágen de cada base de datos, y supuestamente guarda en la variable $ERR el valor de salida para enterarnos en caso que haya problemas, y mandar así el mensaje adecuado en el reporte.

El problema que tiene este script es que la variable $? retorna el valor de salida del último comando en un pipe, en mi caso corresponde a la salida del gzip, que siempre sale correctamente (al menos en este script). Entonces ¿cómo nos enteramos que pasó con un comando anterior en la cadena?

Bash (no conozco otros shells) tiene una variable $PIPESTATUS, que es un array con los valores de salida de una serie de comandos encadenados, por lo tanto lo único que hizo falta para corregir este programa, es reemplazar la línea que dice:

ERR=$?

…por lo siguiente:

ERR=${PIPESTATUS[0]}

El subíndice 0 corresponde al primer valor del array, y que coincide con el primer comando de la cadena de comandos.

¡Espero les sirva en algún momento!

GNU/Linux, Programación bash, pipe, status