José Carlos Areán, Capellán del R.C. Celta – Vigo

Dos leonas no hacen pareja. Dos gatos, tampoco. No pueden aparearse. Para ello tendrían que ser de distinto sexo y de la misma especie. Son cosas de la zoología. No es producto de la cultura hitita, fenicia, maya, cristiana o musulmana. Por supuesto no es un invento de la Iglesia Católica. Muchos siglos antes de que Jesús naciera en Belén, el Derecho Romano reconocía el matrimonio como la unión de un hombre y una mujer. Después ellos se divertían con efebos, que para eso estaban, para el disfrute. La esposa era para tener hijos.

La palabra matrimonio procede de dos palabras romanas: “matris” y “munio”. La primera significa “madre”, la segunda “defensa”. El matrimonio es la defensa, el amparo, la protección de la mujer que es madre, el mayor y más sublime oficio humano.

Cada palabra tiene su significado propio. Una compraventa gratuita no es una compraventa, sino una donación. Y una enfiteusis por cinco años no es una enfiteusis, sino un arriendo vulgar.

Llamar matrimonio a la unión de dos personas del mismo sexo me parece como poco serio. Jurídicamente, un disparate. De carcajada. Que le llamen “homomonio”, “chulimonio”, “seximonio”, lo que quieran, todo menos matrimonio, que ya está inventado hace tiempo. Nadie llama tarta de manzana a la que está hecha de peras.

Lo curioso es que cuando dices cosas como estas, algunos te miran como extrañados de que no reconozcas la libertad de las personas. Y por más que les dices que sí, que respeto la libertad de todos, que cada uno puede vivir con quien quiera, incluso con su perro, pero que eso no es un matrimonio, van y me llaman intolerante.

No sé lo que harán los parlamentarios españoles a la hora de votar. Son políticos, no juristas. Votarán por razones políticas, no según Derecho. Las consecuencias son graves. Si un varón tiene derecho a casarse con otro varón y una mujer a hacerlo con otra mujer, ¿le vas a negar el derecho a un hermano a casarse con su propia hermana? ¿O a un padre a hacerlo con su hija? ¿No tienen el mismo derecho? La sociedad se quiebra. Huele a podrido. Como en Dinamarca.

Estoy aprovechando unos momentos libres (al final del post les contaré el por qué) para escribir unas líneas acerca del viaje que vamos haciendo.

Empezamos por Madrid, llegamos el 2 de Octubre al aeropuerto de Barajas, donde nos esperaba mi amigazo German que ya hace unos cuantos años que vive en España. Tuvimos aproximadamente unos 40 minutos de viaje hasta el centro, donde se localiza el Hotel en el que teníamos reserva, el cual abandonamos al segundo día porque cuando reservamos 2 habitaciones dobles, se confundieron y nos guardaron 1 (chan!), así que por la noche había dos pero al día siguiente no… German nos averiguó por otro lado y listo, nos mudamos. De paso, quedamos a 150 metros de la Gran Vía!

La ciudad de Madrid me gustó mucho, aunque seguro nos ha quedado muchísimo por conocer ya que estuvimos 3 días solamente, creo haberme dado una idea de lo que es.

Me gustó la onda de la Plaza Mayor, y los parques y paseos que tiene son espectaculares, pienso que no me cansaría de caminar por ellos!

Una contra que tuvimos es que muchas cosas interesantes estaban “tapadas” por haber obras en marcha, muchas!

Las noches de tapas tampoco estuvieron nada mal! Siempre en la calle te invitan con algún trago si entrás a los bares, así que en parte hemos tomado de arriba

Para los que no han visto las fotos, he dejado un álbum en Facebook.

El día 5 nos tomamos un vuelo hacia Londres, llegando al aeropuerto de Gatwick que queda al sur de la ciudad. La bienvenida del personal de inmigración de Londres fue un poco mas dura que la que nos dió Madrid, pero nada grave, solo unas cuantas preguntas (y hasta me tocó mostrar el cash y las tarjetas de crédito). Ahí averiguamos cómo había que hacer para llegar a Crystal Palace, la zona donde nuestro hotel residía, resultado: tren! Enganchamos el tren casi sin salir del aeropuerto, como que la terminal de tren y el aeropuerto están pegados.

Londres realmente redefinió el concepto de tren en mi mente, al primer viaje pasó a ser mi modo favorito de viajar. La pulcritud tanto de las estaciones como de los vagones, la puntualidad y la variedad de líneas que usar para llegar a casi cualquier lado me asombraron!

Llegamos a Crystal Palace ya siendo las 6 de la tarde aproximadamente y ya casi anochecía, de todos modos no hacía el frío que me imaginaba, de hecho hacía calor! La zona (o ciudad?, pueblo?) de Crystal Palace si bien está bastante retirada del centro de Londres (10 km si mal no recuerdo), tiene una uniformidad edilicia con el centro que llama la atención. Luego de acomodarnos en el hotel y darnos una buena ducha, salimos a recorrer la zona y no tardamos nada en encontrar un restaurant y bar para alimentar nuestros muy viajados cuerpos

Resulta que luego de las 22 hs, la gente ya no cena, con excepción de los Indios! por suerte encontramos un restaurante indio al lado de lo que terminó siendo nuestro pub favorito en Crystal Palace, el cual también cierra temprano.

He publicado también fotos de Londres en Facebook, conocimos la zona del Parlamento, el Museo Británico (enoooooooorme! seguro un 10%), numerosos puentes, el Acuario, el Ojo de Londres (aunque de abajo), Picadilly Circus, el Barrio Chino, entre otras cosas.

Me llamó la atención la correctitud de la gente, desde los mayores a los jóvenes… no se si es sólo una correctitud en el modo de hablar o si además se extiende a la forma de tratarse entre ellos en el día a día, pero el 99% de la gente a la que le preguntamos cosas, nos trataron muy bien y siempre intentaron ayudar. Imprescindible el English, of course!

Otra cosa muy llamativa, la limpieza! En todos lados, hasta en las plazas había dispensers de bolsitas para que los dueños de mascotas puedan levantar los restos que los animalejos suelen dejar, impresionante!

Una cosa que no estuvo tan bien: la disponibilidad de Wi-Fi. Habiendo ido a Mendoza hace mas de dos años y viendo que había Internet inalámbrico GRATIS en muchos lugares, es increíble que hasta en la mayoría de los lugares donde uno consume, el acceso a Internet sea pagado (y no barato! desde 2 libras la hora).

El viernes 9 emprendimos la retirada, con la idea de llegar a París de un modo alternativo al avión o al trén que va por debajo del Canal. Buscando en Internet encontramos información que nos decía que teníamos que ir hasta Dover, que queda en la costa sureste de la isla, y de ahí tomarnos un ferry hasta Calais, en Francia. A partir de ahí podríamos llegar a París en tren.

Así fue! sólo que desde Calais tuvimos que hacer escala en Lille Flandres, y cambiarnos a un tren expreso (TGV se llama?). Llegamos antenoche a las 22 hs aprox. a la Garde du Nord, una estación al norte del centro de París.

Antes de salir de Londres habíamos reservado en un hotelito llamado Hotel de France, localizado a pocas cuadras de una estación de subtes importante al este del centro: Nation. Está bueno porque muchas líneas de subte te dejan cerca desde cualquier punto de la ciudad.

Volviendo al viaje intra-ciudad hasta nuestro hotel, primero le preguntamos a un tachero cuanto nos cobraba para llegar al hotel (unos 6 kms de distancia según el GPS de mi teléfono) y el loquito nos quería sacudir con 40 €, eso nos dió coraje para probar buscar un subte, cosa que logramos hacer y en vez de 40, terminamos pagando 6 euros por casi el mismo viaje.

Ayer recorrimos bastante, fuimos al Museo del Louvre (im pre sio nante!), conocimos el Siena y varios de sus puentes, pasamos por el Arco del Triunfo y la Torre Eiffel (hasta sacamos varias fotos nocturnas), ya publicaré las fotos! Cosa diferente en París al menos: los baños!!! Hay que pagar para ir al baño aún en varios bares donde uno consume, con razón son tan mugrientos los franceses, porque es verdad… el tufo que se siente cada tanto, es considerable

Con respecto al Wi-Fi, peor que en Londres … hola? primer mundo, donde estás? (para un geek, primer mundo equivale a wi-fi en cualquier lado, y gratis)

Y ahora viene la parte anecdótica de por que siendo casi las 10am de un domingo, sigo acá escribiendo en vez de estar durmiendo o levantandome para seguir paseando: el Hotel que reservamos da mucho que desear. Desde cosas como que no tiene WiFi en la habitación como prometía, que el dormitorio de mi hermano e Ivana tenía el baño sin limpiar del huésped anterior, pasando por el desayuno que si no lo pedís el día anterior, no te lo preparan… llegamos al detalle final: anoche llegando a las 24:00 aprox, ansiosos por darnos un bañito y cambiarnos de ropa, nos informan que perdieron la llave de mi habitación! y que para colmo no pudieron comunicarse con el jefe, que tiene la copia, chan!

En resumen: pasamos la noche en otra habitación, con la ropa del día anterior… y yo acá aún esperando que se comuniquen con el jefe, que espero que no se haya ido de viaje a algún lado por el fin de semana. ¿Cuantas patadas se aguantará la puerta?

Update: Ayer subí fotos de París en Facebook, que las disfruten!

Si todo va bien y los planetas se alinean, voy a ir publicando fotos y anécdotas durante el transcurso de la aventura

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!

Hoy, dispuesto a escribir un nuevo post (que ya verán en un futuro cercano) me doy cuenta mirando el Tablero de WordPress, que he llegado sin darme cuenta, al artículo número 100 desde aquel primer mensaje de bienvenida hace casi 5 años en este blog.

Al darme cuenta de semejante evento, he dejado de lado el post original para hacer un breve (e inútil, seguramente) análisis de la vida de este pobre blog.

• Google Analytics dice que desde mayo del 2007 (fecha que empecé a usar Analytics) hasta la fecha, aproximadamente 25000 personas han perdido en promedio 1 minuto con 5 segundos de sus vidas leyendo mi sitio.
• Bueno, en realidad tan sólo el 79% de esos 25000 visitantes han llegado a mi sitio, vomitado, y seguido con sus vidas
• El promedio de artículos por mes que tengo es de 1,75 artículos, o lo que es lo mismo decir 1 artículo cada 17 días… estoy completamente seguro que estos últimos años este promedio viene bajando de lo lindo
• Si bien la mayoría de mis artículos caen en la categoría GNU/Linux, Internet, Software Libre y Programación, la keyword campeona, la más popular por la que mucha gente llega a mi sitio es: lucas (¿¡!?) con casi el 12%, siendo además la 4ta búsqueda más popular: lucas di pentima.
• Otro dato curioso, yo que pensaba que mi blog sería interesante para gente geek o al menos pre-geek (eso existe?), pero el casi 50% de mis visitantes usan Internet Explorer, y el 80% usan Windows (o al menos visitan mi blog desde Windows)
• 59 visitantes me han visitado entre 51 y 100 veces, que es un número bastante cercano a la cantidad actual de suscriptores (71) por RSS que tengo, tendrá algo que ver? Perdón a esos 22 mil personas que han malgastado su tiempo visitandome una sola vez, no fue mi intención.
• Siguiendo con las estadísticas de Google con respecto a esta pobre gente que me visitó y no hizo mas que huir de mi sitio, en sumatoria he desperdiciado unas 28 horas de vida si tomamos en cuenta la media de cada uno de los 20130 visitantes que estuvieron en mi sitio entre 1 y 10 segundos.
• …por otro lado, tengo 75 visitantes que han estado paseando por mi blog mas de 30 minutos! ESO es tiempo libre…
• Con respecto a las fuentes de tráfico, Google me trae el 70% de las visitas, siendo la búsqueda técnica más popular (número 2 en el ranking) el término: bacula.
• Coincidentemente, el artículo más popular, aparte de la página principal, es el de Bacula, con unas 1711 visitas.

Bueno, es todo por ahora… a partir de este post me he dado cuenta que no conozco mi blog, ni mis visitantes, que lo que escribo poco importa, y que seguramente si quiero hacer plata con mi sitio, lo que debería hacer es escribir algún artículo sobre la naturaleza y orígenes del nombre Lucas, y quizás por que no una autobiografía