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!

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.A modo de preámbulo, les voy a contar que mis servidores son todos Debian Lenny (stable) y usamos Rails 2.3.x.

Como primera medida, vamos a definir en Puppet lo necesario para que Ruby y Rails estén instalados, ya que son el sistema operativo de nuestra aplicación web.

Para poder instalar Rails 2.3.x desde el instalador de gemas, tenemos primero que instalar rubygems y rubygems1.8, pero Debian Lenny no trae la versión 1.3.1 que es la necesaria, por lo tanto acá es el único lugar donde vamos a hacer un poco de trampa, y vamos a instalar el paquete que podemos bajar desde la versión experimental acá y acá.

¿Cómo instalar un paquete que no está en la distribución actual? Mi solución seguro no fue la mejor, pero anduvo! Lo que hago es vía Puppet envío el paquete al servidor en cuestión y después le digo que lo instale usando dpkg, de esta manera:

# Instalamos rubygems 1.3.1 desde paquetes de experimental, ya que Lenny no lo tiene
# La versión 1.3.1 es necesaria para rails 2.3.x

class rubygems {
    file {
        "/usr/src/rubygems1.8_1.3.1-1_all.deb":
            source => "puppet://puppet.marketingsur.com/files/packages/rubygems1.8_1.3.1-1_all.deb",
            owner => root,
            group => root,
            mode => 0644;
        "/usr/src/rubygems_1.3.1-1_all.deb":
            source => "puppet://puppet.marketingsur.com/files/packages/rubygems_1.3.1-1_all.deb",
            owner => root,
            group => root,
            mode => 0644;
    }

    package {
        "ruby1.8":
            ensure => installed;
        "ruby1.8-dev":
            ensure => installed;
        "make":
            ensure => installed;
        "rubygems1.8_1.3.1":
            source => "/usr/src/rubygems1.8_1.3.1-1_all.deb",
            provider => dpkg,
            ensure => installed,
            require => File["/usr/src/rubygems1.8_1.3.1-1_all.deb"];
        "rubygems_1.3.1":
            source => "/usr/src/rubygems_1.3.1-1_all.deb",
            provider => dpkg,
            ensure => installed,
            require => [ Package["ruby1.8"], Package["rubygems1.8_1.3.1"],
                         File["/usr/src/rubygems_1.3.1-1_all.deb"] ];
    }
}

Con esto ya puedo definir la clase que me va a mantener instalado rails desde gemas:

# Instalamos rails desde gems porque la versión Debian es muy vieja
class rails {

    include rubygems

    package {
        "rails":
            provider => gem,
            ensure => installed,
            require => Package["rubygems_1.3.1"];
    }
}

Nótese la libertad que Puppet no provee al mantenerse independiente del sistema de paquetes, mediante la palabra clave provider puedo decirle que instale paquetes desde otras fuentes, permitiendonos seguir tratando a ese recurso como un paquete abstracto.

Hasta aquí tenemos entonces el lenguaje ruby 1.8 instalado, y rails 2.3.x listo para ser usado.

Mongrel Cluster

Mongrel es una biblioteca Ruby que se usa para armar servidores web, está diseñada para tener buena performance sirviendo contenido dinámico, pero no estático… es por eso que lo último se lo dejamos a Nginx, como explico más abajo.

Volviendo a mongrel, la distribución Debian tiene un paquete llamado mongrel-cluster que nos deja todo bastante listo para usar, con scripts de inicio y apagado de los clusters, por lo que el trabajo adicional que hay que hacer es relativamente poco.

Primero armamos una clase para instalar el software y mantener funcionando el servicio:

class mongrel {
    include rails

    package {
        "mongrel-cluster":
            ensure => installed,
            require => Package["rails"];
    }

    service {
        "mongrel-cluster":
            ensure => running,
            enable => true,
            hasrestart => true,
            hasstatus => true,
            require => Package["mongrel-cluster"];
    }
}

Luego escribimos la definición que va a permitir dar vida a varios clusters mongrel:

define mongrel-cluster-app ( $ipaddr="127.0.0.1",
                             $appdir="",
                             $port=8000,
                             $servers=3) {
    $root = $appdir ? {
        "" => "/var/www/${name}",
        default => "${appdir}",
    }

    include mongrel

    file {
        "/etc/mongrel-cluster/sites-available/${name}.conf":
            owner => root,
            group => root,
            mode => 0644,
            content => template("mongrel/cluster-app.conf.erb"),
            require => Package["mongrel-cluster"],
            notify => Service["mongrel-cluster"];

        "/etc/mongrel-cluster/sites-enabled/${name}.conf":
            ensure => "/etc/mongrel-cluster/sites-available/${name}.conf",
            require => File["/etc/mongrel-cluster/sites-available/${name}.conf"],
            notify => Service["mongrel-cluster"];
    }
}

Esto configura el cluster mongrel en cuestión, activándolo y escribiendo el archivo de configuración a partir del siguiente simple template:

---
address: <%= ipaddr %>
log_file: log/mongrel.log
port: "<%= port %>"
cwd: <%= root %>/current
environment: production
pid_file: tmp/pids/mongrel.pid
servers: <%= servers %>

Con esto, tenemos el software mongrel-cluster instalado, y el cluster específico que va a ejecutar nuestra aplicación configurado y corriendo, listo para atender los requerimientos de los usuarios cuando le lleguen a través de nginx.

Nginx

Primero vamos a empezar con el webserver, el que se encarga de atender a los requests de los usuarios. Éste es un proyecto Ruso que está ganando popularidad por su gran velocidad y poco consumo de memoria. Mi anterior favorito era lighttpd, pero he tenido varios problemas de uso de memoria, y por lo que vi el proyecto está bastante frenado.

Del lado de Puppet, primero defino una clase que mantiene instalado y corriendo el servidor nginx, nada del otro mundo:

class nginx {
    package {
        "nginx":
            ensure => installed;
    }

    service {
        "nginx":
            ensure => running,
            enable => true,
            hasrestart => true,
            hasstatus => false,
            require => Package["nginx"];
    }
}

Luego, tengo una definición que me permite generar varias configuraciones de sitios basados en nginx y mongrel:

define nginx-railsapp ( $rootdir="",
                        $ipaddr="",
                        $port=80,
                        $mongrels=["127.0.0.1, 8000, 3"] ) {
    $root = $rootdir ? {
        "" => "/var/www/${name}",
        default => "${rootdir}",
    }
    $listen = $ipaddr ? {
        "" => "${port}",
        default => "${ipaddr}:${port}",
    }
    $upstream_name = "mongrel-${name}"

    include nginx

    file {
        "${root}":
            ensure => directory,
            owner => www-data,
            group => www-data,
            mode => 0755;
        "/etc/nginx/sites-available/${name}":
            content => template("nginx/railsapp.conf.erb"),
            owner => root,
            group => root,
            mode => 0644,
            require => Package["nginx"],
            notify => Service["nginx"];
        "/etc/nginx/sites-enabled/${name}":
            ensure => "/etc/nginx/sites-available/${name}",
            require => File["/etc/nginx/sites-available/${name}"],
            notify => Service["nginx"];
    }
}

Esta definición acepta 4 parámetros: el directorio raíz donde va a estar la app, la dirección IP en la que va a atender el webserver, su puerto, y las instancias mongrel que van a darle vida a la aplicación. Noten que por defecto todos los parámetros tienen un valor configurado, por lo que son opcionales.

Otro detalle a tener en cuenta es el parámetro mongrels, se puede ver que es una lista de strings, esa string define una tupla de 3 valores separados por coma, el primero corresponde al IP donde los mongrels atienden, el segundo es el puerto inicial, y el tercer valor la cantidad de instancias.

La receta configura un par de directorios y además el archivo de configuración de la aplicación, que obtiene a partir de un template (railsapp.conf.erb) que incluyo acá abajo:

###
# ATENCION: Archivo de configuración manejado por Puppet!
###

upstream <%= upstream_name %> {
    #fair;
<% mongrels.each do |mongrel| -%>
<% mongrel_ip, mongrel_port, mongrel_qty = mongrel.gsub(' ', '').split(',') -%>
<% mongrel_qty.to_i.times do |n| -%>
    server <%= mongrel_ip %>:<%= mongrel_port.to_i + n %>;
<% end -%>
<% end -%>
}

server {
    listen <%= listen %>;
    server_name <%= name %> www.<%= name %>;
    charset off;

    # this rewrites all the requests to the maintenance.html
    # page if it exists in the doc root. This is for capistrano’s
    # disable web task
    if (-f <%= root %>/system/maintenance.html) {
        rewrite ^(.*)$ /system/maintenance.html last;
        break;
    }

    location / {
        root <%= root %>/current;
        index index.html index.htm;
    }

    # / -> first search for local index.html then go to <%= upstream_name %>
    location ~ ^/$ {
        if (-f /index.html) {
            rewrite (.*) /index.html last;
        }
        proxy_pass http://<%= upstream_name %>;
    }

    # rails caching: searching first for $action.html local pages
    location / {
        if (!-f $request_filename.html) {
            proxy_pass http://<%= upstream_name %>;
        }
        rewrite (.*) $1.html last;
    }

    # serve static files directly
    location ~ .html {
        root <%= root %>/current/public;
    }

    location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov)$ {
        root <%= root %>/current/public;
    }

    # resend everything else to <%= upstream_name %>
    location / {
        proxy_pass  http://<%= upstream_name %>;
        proxy_redirect     off;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

Éste es un archivo de configuración que encontré por ahi y que lo adapté al formato de templates de ERB. Básicamente lo que hace es servir todo lo que sea contenido estático, y para lo dinámico (la aplicación web en si) hace de proxy ruteando los requests a el o los clusters mongrel que hayamos definido. Esto nos permitiría tener varios servidores atendiendo a la aplicación web, para repartir la carga.

El toque final

Luego de definir todos estos recursos, no nos queda más que usarlos. Ésto lo podemos hacer con una clase que defina la aplicación en cuestión, de la siguiente manera:

# midominio.com Web App (proxy balancer + backend)
class midominio-webapp {
    include rails
    include mongrel

    $mongrel_ipaddr = "127.0.0.1"
    $mongrel_port = 8000
    $mongrel_servers = 5

    $needed_gems = ["gema1", "gema2", "gema3"]

    nginx-railsapp {
        "midominio.com":
            ipaddr => "1.2.3.4",
            mongrels => ["${mongrel_ipaddr}, ${mongrel_port}, ${mongrel_servers}"];
    }
    mongrel-cluster-app {
        "midominio.com":
            ipaddr => "${mongrel_ipaddr}",
            port => "${mongrel_port}",
            servers => "${mongrel_servers}";
    }

    package {
        $needed_gems:
            provider => gem,
            ensure => installed,
            require => Package["rails"];
    }
}

Luego esta clase la incluímos en el nodo que corresponda, y listo… al rato tenemos instalada la infraestructura para hostear nuestra aplicación web.

Espero se animen a usar Puppet si aún no lo han hecho. Su sintaxis no es de lo mas hermoso que puede existir, pero los beneficios que trae hacen ese tema algo insignificante.

En la segunda parte vamos a hablar de cómo automatizar la instalación de la aplicación en los servidores, usando Capistrano.

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!

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!

#!/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!

Recordé que varios de mis amigos geeks usan esas terminales que se deslizan desde arriba como si fuera la consola del Quake, y con eso en mente empecé a buscar el software libre disponible para mi flamante Ubuntu 8.10 Intrepid Ibex. Había varias opciones, y obviamente yo buscaba las que estaban basadas en el framework GNOME para mantener la consistencia del escritorio. Es más, si estaba basado en la libvte mucho mejor, ya que me llevo de 10 con la terminal de GNOME.

Opciones hay varias, pero como me pasó con Amarok, ninguna de las opciones reunía todas las características que uso en una terminal (que no son muchas!!!):

1. Múltiples pestañas
2. Colores de fuentes y fondo personalizables
3. Apertura/cierre y cambio de pestañas con combinaciones de teclas
4. Seteo de título de pestaña (con tecla caliente, alias hotkey)
5. Y ahora el gran agregado: una tecla rápida global para mostrar/esconder la terminal

De más está decir que Yakuake cumplió todos estos requisitos y algunos otros más. La gran contra es que tengo otra vez cargado el sistema KDE para una sola aplicación, pero bueno… en este caso es la aplicación principal que me permite ganarme la vida, así que podemos dejarlo pasar por esta vez

Ya que estamos, les recomiendo que lean un post anterior que habla sobre los colores para emular una terminal Hércules, después de varios años de usar ese esquema de color les puedo decir que me sigue pareciendo uno de los más descansados.

El único inconveniente (al menos para mi) es que utiliza las bibliotecas del entorno KDE, y yo como usuario del entorno GNOME, no veo la necesidad de cargar semejante framework en la RAM de mi computadora, tan sólo por un programa… es por eso que cada tanto daba una revisada a los varios programas de gestión de música que hay para GNOME.

Finalmente me convenció Exaile, que cubre mis expectativas con respecto al tipo de uso que le doy a Amarok. Mayormente mis necesidades son que se pueda conectar con Last.fm, pudiendo sugerir música relacionada a la que estoy escuchando y además poder ser controlado por teclas rápidas globales, de modo que estando minimizado yo pueda pausar, adelantar, cambiar el volumen, puntuar, etc.

Exaile tiene la posibilidad de agregarle extensiones, las que me permiten hacer justamente lo que quiero, por fin pude desinstalar las libqt de mi sistema!

Para aquellos que quieran hacer funcionar las teclas rápidas globales con compiz, acá les va un dato: Hay que instalar el compiz-manager y armarlas ahi ya que el plugin solo es para metacity. Ejecutando ‘exaile –help’ van a poder ver la cantidad de acciones que puede realizar una tecla rápida.

Espero les sirva la recomendación!

Nokia Research Center ha desarrollado una implementación de Map/Reduce, una de las herramientas que Google utiliza para el procesado de inmensas cantidades de información.

El funcionamiento de Map/Reduce a grandes rasgos consiste en partir el conjunto de datos en pequeños segmentos y distribuir datos y código de ejecución en diferentes computadoras (Map) para que trabajen en paralelo. El resultado de este procesamiento luego es recuperado e integrado en un solo lugar para su procesamiento final y uso (Reduce). Se puede leer más acerca del tema en el paper publicado por Google.

Nokia Research Center comenzó un proyecto denominado Disco Project, que consiste en un servidor implementado en Erlang que nos permite como usuarios ejecutar scripts en Python (si, leyeron bien!) en forma distribuida y masiva.

En el sitio del proyecto tenemos un lindo tutorial que podemos probar desde nuestra propia PC, si tenemos un CPU multicore y GNU/Linux, claro está

Lo que no es tan bárbaro, a mi modo de verlo, es escuchar música o ver películas en la notebook, ¿por qué? bueno…a menos que tu notebook tenga un buen par de parlantes internos o uses auriculares, la calidad del sonido no será la óptima.

Lo lindo de una PC desktop es que normalmente la tenemos enchufada a algún equipo de audio, o bien a unos parlantes buenos y potentes. Lo no tan lindo es que ver películas sentado en el escritorio no es cómodo, y tener que ir a la PC para cambiar la música cada vez que quieras tampoco.

Con estas experiencias en mente, estaba pensando que una buena alternativa sería poner en mi desktop un servidor de reproducción de audio, en donde yo desde la notebook, quizás vía una interfaz web pudiera manejar la música que suena en el equipo de audio, ya sea que esté en el balcón, en la cama o mi escritorio…pero esto no me resolvía el problema del audio en los videos que suelo ver, y fue por eso que nunca lo implementé.

Hace poco me puse a leer un poquito sobre Zeroconf, por recomendación de un amigo que me dijo que está interesante, y me encuentro con que existen servidores de audio que usan esta tecnología. Zeroconf es un conjunto de protocolos que permiten la configuración automática de varios aspectos de una red, sin la intervención de un administrador o equipo central. Con agrado veo que PulseAudio, un servidor de audio con capacidades de red, tiene un módulo de Zeroconf, y una enorme cantidad de clientes entre los que se incluyen Amarok, Mplayer, Xine, gstreamer, GNOME, etc.

Combinando PulseAudio con Zeroconf en una red WiFi, he logrado que al iniciar mi sesión GNOME, mi notebook descubra automáticamente el servidor PulseAudio en mi PC Desktop (que siempre tengo funcionando) , y de ahí en más tengo la opción de elegir que la música y el audio de los videos salgan por el equipo de audio.

Esto que puede parecer una pavada, en la práctica es una comodidad increíble, recomiendo que lo prueben porque vale la pena. No voy a escribir un tutorial porque al menos en Debian es realmente trivial hacerlo funcionar, pero les dejo un enlace que lo explica muy bien:

http://www.pulseaudio.org/wiki/PerfectSetup

¡Que lo disfruten! Si alguno tiene experiencias similares, sería interesante que las comenten.

En Debian disfrutamos de una herramienta muy útil llamada “update-alternatives”, que nos permite configurar la aplicación favorita a partir de una lista de opciones. Como root nos logueamos y ejecutamos lo siguiente:

computita:~# update-alternatives --config x-www-browser

Hay 2 alternativas que proveen `x-www-browser'.

  Selección     Alternativa
-----------------------------------------------
*+        1    /usr/bin/epiphany
          2    /usr/bin/iceweasel

Pulse <Intro> para mantener el valor por omisión [*] o pulse un número de selección:

Seleccionamos la opción “2″ y listo, mágicamente el icedove comienza a funcionar como debería: abriendo páginas en nuevas pestañas del iceweasel activo.