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.

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!

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.

DNS no es más que una base de datos jerárquica y distribuída que permite a personas de distintos puntos del globo aportar datos de tal manera que los servicios que todos conocemos, funcionen correctamente. Gracias al DNS los servidores de correo electrónico pueden intercambiar mensajes, los navegadores web pueden encontrar los servidores donde pedir las páginas, etc.

Los administradores de sistemas tenemos como tarea, la de configurar los servidores de nombres para que los datos de nuestros dominios sean correctamente publicados en Internet. Lo cierto es que muy pocos administradores de sistemas conocen realmente la manera correcta de configurar un servidor de nombres, y muchas veces caemos en errores que luego sufrimos por cortes de servicio de correos y otros similares.

Por suerte, en GNU/Linux contamos con varias herramientas que nos ayudan a corroborar que la configuración de un dominio está correcta, hoy voy a comentar “zonecheck” una herramienta que tiene la particularidad de no necesitar analizar un archivo de configuración, sino que hace las consultas a los servidores de nombres públicos en Internet.

Zonecheck viene en Debian, así que para aquellos felices usuarios de esta maravillosa distribución de Linux, solo hace falta ejecutar “apt-get install zonecheck” y comenzar a utilizarlo. El comando posee muchas opciones y realmente es conveniente leer con detenimiento su páginal de manual, pero para aquellas personas ansiosas, acá les va un ejemplo:

$ zonecheck -4 -q -vi,x,d fileextensionunknown.com
ZONE  : fileextensionunknown.com.
NS <= : ns1.name.com. [4.79.81.159]
NS    : ns2.name.com. [38.97.225.164]
NS    : ns4.name.com. [38.97.225.165]
NS    : ns3.name.com. [4.79.81.160]

w> The format of the serial number is not YYYYMMDDnn
 | Ref: RFC1912 (p.3)
 |   The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day,
 | nn=revision number).
 `----- -- -- - -  -
 :   The serial 1 doesn't seem to be in the YYYYMMDDnn format.
 `..... .. .. . .  .
=> ns2.name.com./38.97.225.164
=> ns4.name.com./38.97.225.165
=> ns3.name.com./4.79.81.160
=> ns1.name.com./4.79.81.159

w> [TEST delegated domain is not an open relay]: No route to host - connect(2)
=> generic

w> [TEST can deliver email to 'postmaster']: No route to host - connect(2)
=> generic

w> [TEST domain of the hostmaster email is not an open relay]: No route to host - connect(2)
=> generic

f> [TEST can deliver email to hostmaster]: No route to host - connect(2)
=> generic

==> FAILURE (and 7 warning(s))

Zonecheck realiza numerosas pruebas, y nos va diciendo cuales son advertencias, cuales son errores fatales y en algunas ocasiones, cómo solucionarlo.

Además, para aquellos administradores que no usen GNU/Linux, acabo de poner en línea una herramienta web que utiliza zonecheck de fondo, para poder acceder a esta ventaja aún estando en un Windows: Free DNS Report. ¡Que la disfruten!

El mensaje en cuestión significa que el proceso que acabamos de ejecutar intentó reservar algún puerto ya reservado por otro proceso, ¿pero cual será el usurpador de puertos?

Por suerte, tenemos una manera de saberlo de forma fácil.

Gracias al comando fuser, podemos darnos cuenta muy fácilmente de cual es el número de proceso que nos da problemas. Supongamos que necesito saber qué proceso está ocupando ese puerto UDP número 53 que yo quiero usar para mi servidor de juegos de canasta por Internet, debería ejecutar como root:

# fuser 53/udp
53/udp:               2946

Claramente vemos que el proceso cuyo número es 2946 es el que está estorbandonos.

Para no quedarnos fuera de la temática mágica de esta serie de artículos, combinemos este comando con un poco de otros ingredientes:

# ps ax | grep `fuser 53/udp`
53/udp:
 2946 ?        Ssl    0:02 /usr/sbin/named -u bind

Bien, es el proceso del BIND. Como un servidor de DNS es algo no tan importante como un buen juego de canasta, si o si necesitamos eliminar ese proceso que nos molesta, la pócima final que nos salva de este problema es:

# kill `ps ax | grep $(fuser 53/udp) | awk '{print $1}'`

He aqui una manera de divertirse matando procesos, existe otra mucho más interesante, pero como no es orientada a la línea de comandos, no la vamos a ver por el momento.

Como recomendación: dejemos los servidores de juego de canasta y otros servicios similares para los puertos mayores a 1024

El caso concreto de hoy es el contínuo llenado de nuestro disco con archivos que desconocemos o que no recordamos: un buen día llega y vemos que nuestra partición de datos, que tiene más de 100 GB de capacidad, está al tope. ¿Cómo hacemos para liberar espacio?

Una de las formas posibles es la búsqueda de archivos “viejos”, que no usemos más y que realmente deberían ser parte de algún DVD juntando tierra en nuestra estantería en vez de ocupar nuestros preciosos bytes. Por suerte existe el comando find!

$ find $HOME -type f -atime +365 | wc -l

El número resultante es la cantidad de archivos que tenemos en nuestro directorio personal que no hemos accedido en el último año. ¿Y que puedo hacer para saber cuanto espacio me ocupan esos archivos?

$ find $HOME -type f -atime +365 -exec ls -l {} \; | awk '{suma += $5} END {print suma}'

Lo que nos devuelve este comando es la cantidad de bytes ocupados por los archivos que hace más de un año que no utilizamos. ¿Bueno, y que tal si quiero ver el “top 10″ de archivos viejos más grandes?

$ find $HOME -type f -atime +365 -exec ls -l {} \; | cut -d" " -f5,8- | sort -nr | head -n 10

Finalmente con este comando que sigue, eliminamos cualquier archivo que no haya sido usado en los últimos 3 años:

$ find $HOME -type f -atime +1095 -exec rm {} \;

Esto es todo, ¡a limpiar esos discos!