Un lugar en el mundo...

Bacalao con salsa de pimientos

Publicado en 11 de octubre de 2013 por Josemaría / 1 comentario

Bacalao con salsa de pimientos De vuelta a los fogones. Anotad, que esta es sencillita:

4 lomos de bacalao ya desalado.
2 pimientos rojos y uno verde.
2 cebollas.
8 dientes de ajo.
una rebanada de pan frito
Perejil
250 grs. de tomate frito
Un par de hojas de laurel.
Medio vaso de vino blanco
Pimienta negra molida y aceite de oliva.

Espolvoreamos ligeramente el bacalao con pimienta negra y lo reservamos. Picamos la cebolla, los ajos y los pimientos y lo sofreímos todo. Cuando está bien pochado (pero cuidando que no se queme en absoluto) lo trituramos con una picadora junto con la rebanada de pan frito, lo mezclamos bien con el tomate y añadimos medio vaso de vino blanco y otro medio de agua. Lo devolvemos a la cacerola, añadimos las hojas de laurel y, esperamos a que empiece a hervir. Colocamos los lomitos de bacalao, espolvoreamos generosamente con perejil fresco bien picado y lo dejamos cocer, cubierto y a fuego lento, durante unos 15 minutos por cada lado.

Mi intención original era hacer bacalao a la vizcaína pero parece ser otra de esas recetas con miles de variantes y una lucha encarnizada por defender la verdad única. Y no, ya no me meto en más de esas que estoy mayor… 😉

correo electrónico/herramientas/howto´s/spam

Greylisting en Postfix y Debian 7

Publicado en 27 de septiembre de 2013 por Josemaría / 3 comentarios

Nadie se acuerda de Santa Bárbara hasta que truena, que dice el refrán. Yo tenía pendiente configurar un sistema de Greylisting (listas grises) en mi servidor de correo pero no lo he visto como urgente e inmediato hasta el aumento inusitado de actividad de los bots de spam de los últimos días.

El Greylisting es, hoy por hoy, uno de los métodos más efectivos a la hora de controlar el spam y su funcionamiento es sencillo y fácil de entender. Cuando un servidor de correo recibe un mensaje anota en una lista tres datos que lo identifican (la IP desde donde viene, el correo del remitente y el del receptor) y a continuación lo rechaza indicando al emisor que lo intente de nuevo más tarde. Esto se hace con un código 45x:

-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
<- 451 4.7.1 Please try again later

Si el mensaje ha sido enviado por un servidor SMTP legítimo reconocerá el mensaje de rechazo y en un tiempo predefinido (típicamente de 300 segundos) reenviará de nuevo el correo que, en este caso, será aceptado por el servidor del destinatario. Un bot preparado para enviar spam no realizará el segundo envío. De esta forma, si el correo no es spam llegará al destinatario con 5 minutos de retraso. Salvo este detalle el emisor no se enterará de nada (todo el trabajo se hace entre los servidores de correo sin que los clientes intervengan). Si el receptor abre la cabecera del mensaje recibido verá una línea parecida a esta:

X-Greylist: delayed 300 seconds by postgrey-1.34 at invernalia; Thu, 19 Sep 2013 16:30:33 CEST

El sistema de control del spam mediante Greylisting fue originalmente ideado por Evan Harris en este whitepaper de 2003. El señor Harris mantiene, además, una lista de implementaciones de su método para diversos servidores de correo. Si quieres más información conceptual sobre esta técnica, esta página y la entrada correspondiente de la wikipedia también tienen información interesante.

Si ya tienes una Debian con un servidor de correo postfix funcionando la implementación en perl del Greylisting es muy, muy fácil de poner en marcha. Basta con instalar el paquete postgrey y añadir check_policy_service inet:127.0.0.1:10023 en la lista de restricciones del fichero main.cf de configuración de postfix en el directorio /etc/postfix:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023

Por supuesto, una vez hechas ambas cosas debemos de reiniciar el servicio postfix. La instalación nos ha creado un nuevo servicio llamado postgrey que arranca como daemon y escucha en el puerto 10023 y que responde a los argumentos habituales: start, stop, restart, reload, force-reload y status. En el directorio /etc/postgrey tenemos dos ficheros denominados whitelist_clients y whitelist_recipients donde, respectivamente, se pueden especificar las direcciones de ciertos servidores smtp o direcciones de correo que no se someteran al procedimiento de rechazo temporal de los mensajes y que se aceptaran al primer intento. Tenemos, además, un fichero donde se encuentra la configuración principal del servicio llamado /etc/default/postgrey que veremos más adelante.

Si observamos ahora el log de nuestro postfix (/var/log/mail.log) podemos estudiar el funcionamiento y si este es correcto. Cuando recibimos cualquier correo (salvo uno ya identificado como válido en las whitelist) será inmediatamente registrado y rechazado:

Al cabo de cinco minutos si el correo es legítimo el servidor remitente volverá a intentarlo y ahora el correo si será aceptado:

Puede que el servidor emisor se impaciente y antes de que transcurran esos cinco minutos vuelva a intentarlo. En ese caso el correo volverá a ser rechazado:

Como puedes observar en los mensajes del log, aparte de la razón del rechazo el servidor enviará una dirección web personalizada donde se informa detalladamente de lo que está ocurriendo:

mensaje de información de postgrey en castellano

Postgrey crea, además, una base de datos en el directorio /var/lib/postgrey donde guarda información acerca de los mensajes recibidos. Después de aceptar cinco mensajes de un servidor, este será automáticamente incluido en una whitelist de tal forma que, a partir de este momento, ya no se le volverá a exigir el trámite de los reintentos. Podemos consultar en cualquier momento los servidores de esta lista ejecutando el siguiente script:

perl /usr/share/doc/postgrey/postgrey_clients_dump

Y una ejecución de ejemplo:

Servidores incluidos en la whitelist de greylist

Tenemos aún pendiente ver el fichero de configuración principal: /etc/default/postgrey. En el podemos modificar, por ejemplo, el texto que aparecerá en el mensaje de rechazo:

POSTGREY_TEXT="Si tu sevidor funciona como debiera debería de intentar enviarme de nuevo el mensaje en 5 minutillos de nada"

También podemos enviar al demonio cualquiera de los argumentos que tenemos disponibles para modificar su funcionamiento (ver man postgrey) mediante el parámetro POSTGREY_OPTS. Por ejemplo, en la siguiente línea se dice al demonio que escuche en el puerto 60000, subimos el retraso para aceptar el mensaje a 600 segundos y le indicamos que incluya las direcciones de los clientes en la whitelist después de aceptarles 3 envíos:

POSTGREY_OPTS="--inet=60000 --delay=600 --auto-whitelist-clients=3"

Para terminar, si quieres comprobar la configuración de tu servidor de correo electrónico para ver si es vulnerable de alguna forma y puede ser usado como un Open Relay, si el correo saliente que envía puede verse bloqueado de alguna forma, etc. existen muchas herramientas en línea pero las más cómodas y completas, a mi juicio, son las de mxtoolbox y el test de allaboutspam.

ACTUALIZACIÓN: Los servidores de Microsoft (outlook, hotmail…) dan problemas con este sistema desde hace un tiempo. Aquí tienes como resolverlos.

howto´s/monitorización

Analizando el arranque de tu Linux con bootchart

Publicado en 17 de septiembre de 2013 por Josemaría / 3 comentarios

¿Qué es lo que hace tu Linux durante el arranque?¿Hay alguna forma de ver exactamente que se ejecuta, cuales son los procesos dependientes que genera y cuanto tiempo se invierte en cada uno de ellos de forma que podamos, si es necesario, saber donde tenemos que tocar para conseguir un arranque más rápido?

Bootchart es una herramienta que obtiene y procesa fácilmente esta información y genera como resultado un gráfico fácilmente interpretable. Como muestra, aquí tenéis la gráfica resultado en un servidor VPS con Debian 7 (ya sabes, pulsa sobre la gráfica para verla con mejor resolución):

La instalación básica en una Debian estable requiere dos paquetes (y sus dependencias): bootchart y pybootchartgui. El primero es el que recopila los datos y el segundo el que genera el gráfico a partir de ellos. bootchard se instalará por defecto en el directorio /sbin y su archivo de configuración se llama bootchard.conf y se encuentra en el directorio /etc. pybootchartgui se encuentra en el directorio /usr/bin/. Aunque tenemos muchas opciones interesantes para explorar, vamos a limitarnos a ver el funcionamiento tal y como queda recién instalado y sin tocar nada.

Una vez instalados ambos, tenemos que hacer que el kernel de nuestro Linux ejecute el proceso que realiza la recogida de datos lo antes posible y esto lo hacemos introduciendo dicha llamada directamente en GRUB. Si estamos en un equipo desde el que tenemos acceso directo a teclado y monitor lo más fácil es introducir a mano la opción necesaria en el momento del arranque. Para ello, una vez que nos aparece el menú de GRUB pulsamos la letra «e» (de editar) e introducimos la opción init=/sbin/bootchartd. De esta forma el proceso sólo se llamará en este arranque puesto que la opción no queda salvada:

Editando la entrada de Grub para invocar a bootchar

Si no tenemos acceso al teclado de la máquina en el momento del arranque (en un Hosting VPS, por ejemplo) el método pasa por introducir esta opción en los archivos de configuración de GRUB. El método es diferente según que usemos GRUB o GRUB2. En GRUB basta con editar el archivo /boot/grub/menu.lst, buscar el bloque correspondiente al kernel con el que qeremos realizar el arranque e introducir la misma opción que hemos visto antes. Por ejemplo, así:

title           Debian GNU/Linux, kernel 3.2.0-4-amd64
root            (hd0,0)
kernel          /boot/vmlinuz-3.2.0-4-amd64 root=/dev/vda1 ro quiet no-kvmclock init=/sbin/bootchartd
initrd          /boot/initrd.img-3.2.0-4-amd64

En GRUB2 tenemos que editar el fichero /etc/default/grub, buscar la línea etiquetada como GRUB_CMDLINE_LINUX_DEFAULT e incluir al final de lo que allí aparezca la opción de carga de bootchartd. Así, por ejemplo:

GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/35a07870-ac1a-489f-a19b-629
6dca46903 init=/sbin/bootchartd"

En este segundo caso, una vez editado el fichero tendremos que ejecutar el programa update-grub para que los cambios tomen efecto.

Un cuarto método, disponible si estamos usando un equipo de escritorio con un gestor de ventanas instalado, es usar uno de los muchos programas existentes para configurar grub de forma gráfica. Por ejemplo, grub-customizer:

Configurando el arranque de bootchartd con grub-customizer

Sea cual sea el método que hayamos usado, en el próximo arranque se ejecutará bootchartd, pero no olvides que, salvo en el primer caso, cuando ya no quieras usarlo tendrás que deshacer los cambios efectuados.

Bien. Tras reiniciar la máquina se invocará al proceso llamado bootchartd que recogerá la información necesaria y la guardará en un archivo llamado bootchart.tgz en el directorio /var/log. Para crear el gráfico basta con invocar a pybootchartgui:

Generando el gráfico de bootchart con pybootchartgui

Nota que se toma por defecto la ubicación y nombre del archivo original y que, por tratarse este de un nombre genérico, cada vez que reiniciemos y/o generemos un nuevo gráfico machararemos los datos del anterior a menos que los renombremos manualmente o le echemos un vistazo a la forma de modificarlos mediante los parámetros en línea y/o opciones de configuración adecuadas. Y listo. A continuación tenéis otro ejemplo correspondiente a un servidor más modesto que el anterior montado sobre VirtualBox:

En la paquetería de Manjaro Linux (e, imagino, que ocurre igual con Arch) se usa otro programa similar también llamado bootchart pero que, en realidad, integra en un sólo servicio la recolección de datos y la generación del gráfico final. El gráfico resultante presenta, además, algunos aspectos diferenciadores. Podéis ver una muestra en la siguiente imagen que corresponde con el arranque de un PC de escritorio:

Para usarlo basta instalar el paquete llamado bootchart. El programa que tendremos que invocar se llamará igualmente bootchartd pero en este caso reside en el directorio /usr/bin. Podemos usar cualquiera de los métodos anteriormente vistos para invocarlo pero el parámetro a incluir en las opciones de carga del kernel será init=/usr/bin/bootchard. El archivo de configuración también es sensiblemente diferente y está en el directorio /etc/systemd. Cuando reiniciamos la máquina, el archivo que bootchart genera es ya directamente un gráfico en formato svg. El directorio destino del mismo es, igualmente, /var/log pero en este caso el nombre incluye una marca de tiempo (por ejemplo bootchart-20130916-0800.svg) de forma que si realizamos sucesivos reinicios tendremos disponible una colección de gráficos para su posterior estudio sin necesidad de ninguna intervención manual.

Existe aún, al menos, otro tercer sistema similar a estos denominado bootchart2 y que, por el momento, no he tenido ocasión de probar. Ahí queda el enlace por si alguien se anima…

NOTA: Desde hace ya unos meses estoy usando Manjaro Linux (con Openbox como window manager) como distribución de escritorio, tanto en mi ordenador de sobremesa como en mi portatil. Manjaro es una distribución rolling release, muy, muy ligera basada en Arch Linux que me está gustanado bastante, así que previsiblemente hablaremos bastante de ellas en lo sucesivo.

herramientas/howto´s/monitorización

Plugins de memcached y bind9 para munin

Publicado en 5 de septiembre de 2013 por Josemaría / 1 comentario

El otro día dejamos munin instalado y funcionando con los plugins más comunes que vienen de serie y se configuran de forma automática sin (casi) necesidad de manipulación extra alguna. El principal problema que vamos a encontrar con esta herramienta de monitorización es que cuando tratemos de instalar alguno de los centenares de plugins adicionales de que dispone nos encontraremos, según el caso, una información bastante irregular en cuanto a la forma en que tenemos que hacerlo: dependencias, configuración, etc. Hoy vamos a instalar un par de estos plugins adicionales de forma manual y así conoceremos un poco mejor sus tripas y veréis claramente a lo que me refiero.

La primera herramienta que debemos de conocer a la hora de añadir plugins adicionales es munin-node-configure, un script que nos ayuda a identificar que plugins nos pueden resultar útiles y ayudarnos a instalarlos. Como ya vimos, la instalación base de munin identifica muchos de los elementos que pueden resultarnos útiles y los configura e instala, pero si existe algún requisito o dependencia adicional para que funcionen no es capaz de resolverlo aunque si deja un mensaje informándonos de ello si usamos el parámetro --suggest. No suelen ser muy descriptivos y suele hacer falta hacer uso de Google para encontrar la solución (por ejemplo, si te falta la librería libcache-cache-perl para que funcione el plugin de MySQL el mensaje que aparece es «Missing dependency Cache::Cache»), pero bueno, algo es algo.

Para configurar el plugin de bind9 no necesitamos instalar nada adicional, pero si hacer algunos cambios en la configuración de nuestro servidor DNS. En el archivo named.conf.options (típicamente en el directorio /etc/bind) tenemos que introducir la siguiente línea dentro del bloque de options:

statistics-file "/var/cache/bind/named.stats";

Y añadir al final del fichero el siguiente bloque:

logging {
        channel b_query {
                file "/var/log/bind9/query.log" versions 2 size 1m;
                print-time yes;
                severity info;
        };
        category queries { b_query; };
};

A continuación creamos el directorio /var/log/bind9, le damos permisos de escritura al usuario bind, reiniciamos el demonio de nuestro servidor DNS y ejecutamos el comando rndc stats. Con esto el servicio dejará los logs detallados de estadísticas de consultas en ese directorio. A continuación tenemos que configurar el plugin de munin para que las lea y nos las muestre de forma gráfica. Para ello editamos el fichero /etc/munin/plugin-conf.d/munin-node y añadimos los siguientes bloques:

[bind9]
user root
env.logfile   /var/log/bind9/query.log

[bind9_rndc]
user root
env.querystats /var/cache/bind/named.stats

Por último, creamos un enlace a los plugins en el directorio de configuración como explicábamos el otro día:

ln -s /usr/share/munin/plugins/bind9 /etc/munin/plugins/bind9
ln -s /usr/share/munin/plugins/bind9_rndc /etc/munin/plugins/bind9_rndc

Y ya sólo nos queda reiniciar el demonio munin-node. Casi inmediatamente tendremos una nueva categoría de gráficos dedicada a la monitorización de nuestro servicio de nombres:

Plugin de bind9 para munin

La configuración del plugin para memcached es bastante más sencilla. Lo primero que debemos de hacer es instalar el paquete libcache-memcached-perl (en una debian o derivada). A continuación añadimos el siguiente bloque en el archivo /etc/munin/plugin-conf.d/munin-node:

[memcached_*]  
env.host 127.0.0.1  
env.port 11211  
env.timescale 3

Creamos los enlaces:

ln -s /usr/share/munin/plugins/memcached_bytes /etc/munin/plugins/memcached_bytes
ln -s /usr/share/munin/plugins/memcached_counters /etc/munin/plugins/memcached_counters
ln -s /usr/share/munin/plugins/memcached_rates /etc/munin/plugins/memcached_rates

Reinciamos munin-node y ya:

Plugin de memcached para munin

NOTA: Tienes información bastante detallada acerca del fichero de configuración munin-node, las opciones que admite y su significado en este enlace.

enlaces rápidos

7 enlaces 7 (y LIII)

Publicado en 7 de julio de 2013 por Josemaría / 2 comentarios

Vega, una nueva herramienta a tener en cuenta para auditar la seguridad de tus webs. Es multiplataforma y la he conocido, como tantos otros buenos productos, a través de security by default.
Doudou Linux, una distribución con muy buen aspecto basada en Debian para los más pequeños de la casa.
ntopng 1.0, la primera versión de la nueva generación de una de las más populares herramientas de monitorización de redes.
sngrep, un analizador de paquetes SIP basado en ncurses que ha llegado a mi gracias a sinologic donde tienes un pequeño manual de introducción a la herramienta.
How strong is your password? Una herramienta web de intel para que compruebes lo segura que es tu contraseña ante un ataque de fuerza bruta.
O’Really Atlas, el nuevo servicio de biblioteca gratuita de la mejor editorial de libros técnicos de informática que incluye incluso versiones previas de títulos que aún no se han publicado.
11 aplicaciones poco conocidas de Google. Un servicio para identificar canciones mediante un fragmento de las mismas, un juego que te permite construir ciudades mediante un Lego virtual y algún otro servicio que puede que no conozcas del gigante de Internet.

culturales/televisión

Series, series y más series…

Publicado en 4 de julio de 2013 por Josemaría / 6 comentarios

Nunca me han gustado las series. Salvo Friends, claro. A mi juicio no son más que telenovelas para públicos «diferentes» donde el desarrollo de la trama se hace forzadamente lento capítulo a capítulo sin que apenas pase nada en ninguno de ellos. Y, que diablos, que no hay tantas historias que necesiten 10 horas (¡o más!) para narrarse y que puedan ser realmente interesantes. Se salvan, claro, aquellas que presentan una estructura de capítulos autoconcluyentes atados por el hilo conductor de sus protagonistas que van mostrando algún tipo de evolución más o menos conseguida. Pero vamos, eso ya estaba ahí con Los hombres de Harrelson, El superheroe americano, Luz de luna… ¿Os acordáis?

El chip me cambió hace dos años. Desde que nació Juanito empecé a verle la utilidad a estas pequeñas piezas de pseudo-cine que duran entre 40 y 50 minutos: el tiempo ideal durante el que eres capaz de mantener el interés (¡y los ojos abiertos!) una vez que has acostado a la bestezuela. Máxime en estos tiempos en los que los directores se han vuelto locos y es casi imposible encontrar una peli con un metraje inferior a los 120 minutos ¿Tanto ha bajado el precio del celuloide? Ah, espera, que ya no se usa celuloide… 😛

Pero bueno, a lo que vamos. Durante el último año he descubierto varias nuevas series y alguna de ellas ha sido gracias a recomendaciones de gente de la que me fío. Para «devolver el favor» (y buscar posibles reemplazos) voy a hacer aquí una lista de lo que estoy viendo o he visto últimamente y si las considero aprovechables o no. Ojo: sólo series que aún están en la primera temporada. Para las consolidadas no hacen falta recomendaciones y hay fuentes mejores que este blog. Ahí van:

House of Cards. Posiblemente lo mejor que he visto en lo que va de año. La conocí a través de Antonio de Error 500, un malagueño al que jamás haré caso de una recomendación músical (¡tiene un gusto pésimo!) o para comprarme un portátil (demasiado pijo) pero que me ha descubierto de vez en cuando buenos libros. Y ahora una serie. La empecé con miedo porque El ala oeste de la Casa Blanca me parece, a pesar de sus miles de fans, un truño falso y blandengue y me temía algo similar. Para nada. Se trata de una serie que refleja de la forma más real y descarnada las miserias, corruptelas y servidumbres entre políticos, periodistas y grandes empresas. Si, si, como ver el telediario todos los días. La temporada 2 se emitirá en 2014 pero aún no tiene fecha de estreno.

Bates Motel. Los Bates, madre e hijo, acaban de comprar el Motel que hicieron famoso en la película Psicosis y se trasladan allí con objeto de empezar una nueva vida. Eso si: en la época actual de iphones y demás. La perturbadora relación entre madre e hijo se presenta bastante creíble pero hay algo que falla y que no me deja disfrutarla. Es predecible, los personajes son muy planos… no he sido capaz de aguantar más de los tres primeros episodios que le concedo a una prueba. Descartada.

Hannibal. Y otra de psicópatas. Esta recrea los años en los que el Doctor Hannibal Lecter (para los más jóvenes, psiquiatra obsesionado por el canibalismo y popularizado en la literatura gracias a las novelas de Thomas Harris y en el cine con El silencio de los corderos) dirige una consulta íntimamente ligada con la unidad del FBI de ciencias del comportamiento, la división encargada de capturar a los asesinos en serie más sanguinarios y transtornados. Los personajes son interesantes y están bien construidos (en particular Will Graham, el alter-ego del doctor Lecter que lucha por controlar sus inclinaciones) y no se ahorran detalles en la recreación de los escenarios del crimen. Los diálogos y situaciones encaminados a reflejar el complicado mundo de las enfermedades mentales, su tratamiento y su padecimiento también están muy logrados. La segunda temporada también está ya garantizada para el año que viene y yo la espero con apetito. Por cierto: el doctor Lecter se presenta como un exquisito gourmet conocedor de los más delicados y sofisticados manjares, pero después de verlo hablar sobre el jamón serrano, cortarlo usando un cuchillo de cocina y comerlo con tenedor el personaje pierde bastante… 😉

Arrow. Está centrada en Flecha Verde, un superheroe de segunda fila de la DC que, por si no lo conoces, no se trata más que de un clónico de Batman: un millonario playboy que ha perdido a su padre en extrañas circunstancias y que con la ayuda de un extraordinario entrenamiento físico y mental y un montón de juguetitos de alta tecnología se convierte en un justiciero enmascarado. Lo único destacable de la serie es el impresionante físico del protagonista. Salvando esto, está enfocada a un público demasiado adolescente para engancharme (copiando el estilo de Smallville). Alejaos de ella a no ser que tengáis menos de 17 años o disfrutéis viendo bellos y esculturales cuerpos masculinos.

Vikings Vikings – Descubierta gracias a mi amigo Kade (quién, por cierto, se ha embarcado últimamente en El contragolpe, un proyecto que os encantará si os gusta el deporte). Su punto fuerte es la posibilidad de conocer los ritos y costumbres de una cultura tan diferente a la nuestra y la confianza de que, estando avalada por el Canal History, debería de estar bien documentada. La historia que relata no da para mucho (al menos hasta ahora) pero, inexplicablemente, me he tragado la primera temporada sin pestañear y aplaudo que hayan renovado por una segunda.

Defiance. Esta tampoco me ha funcionado. Personajes poco convincentes, ambientación y maquillaje muy falsos… Su atractivo debería de ser la historia de convivencia y enfrentamiento entre distintas razas intergalácticas muy diferentes que se ven obligadas a convivir en una tierra post-apocalíptica pero, a mi al menos, sólo me transmite sopor y aburrimiento. A la hoguera.

Zero Hour. Recomendación de mi amigo Guillermo (que tiene su hogar digital por aquí). En EE.UU. no ha funcionado bien y, después del tercer episodio, la relegaron a un horario de segunda categoría. A mi, sin embargo, me enganchó desde el primer momento a pesar de que no tenía ninguna papeleta. Mezcla una trama que combina de forma incoherente las conspiraciones pseudo-histórico-religiosas de los libros de Dan Brown con las aventuras de Indiana Jones. Pero mola. Que queréis que os diga: asumo mis contradicciones…

Elementary – Sherlock Holmes está de moda, es evidente. Tenemos la adaptación al cine de Downey Jr., la fabulosa serie británica que lleva ya dos temporadas (y regresa en octubre con la tercera) y ahora esto que, posiblemente, es el peor producto de los tres pero que, aún así, aguanta el tipo y se hace entretenida. En este caso el nuevo Sherlock vive en el New York de nuestros días y Watson (Luci Liu) es un asistente contratado por su padre para ayudarle a superar sus problemas de adicción a las drogas. Las historias son irregulares y a veces abusan del síndrome del mayordomo (el culpable es ese personaje que sale cinco minutos al principio del episodio y no le volvemos a ver el pelo hasta el final) pero la mayoría de las veces te dejan participar de la deducción que conduce a la resolución del caso. Lo dicho: no es Sherlock pero ayuda a hacer agradable la espera hasta octubre.

ACTUALIZACI�?N: Utopía es otra serie inglesa a la que he llegado gracias a la recomendación de Anuxi y que, después de tan solo el primer capítulo, presenta un aspecto inquietante. La trama gira alrededor de un misterioso cómic dibujado por un genetista internado en un psiquiátrico que murió en circunstancias bastante extrañas y que alguien tiene bastante interés en que no salga a la luz. The hour y The fall son dos series inglesas recomendadas por mi excompañero Lorenzo que me he devorado en apenas una semana. La primera es una historia sobre periodismo y espionaje en la BBC durante los años de la guerra fría. La segunda trata sobre un asesino en serie en el complicado mundo de las dos Irlandas.

herramientas/howto´s/monitorización

Instalación y primeros pasos con Munin en Debian 7

Publicado en 17 de junio de 2013 por Josemaría / 5 comentarios

Munin es un sistema de monitorización muy similar a cacti (que ya hemos tratado hace poco por aquí) pero que en lugar de usar snmp usa su propio programa recolector de información (llamado munin-node). La instalación básica sobre un único servidor (que es la que vamos a ver) es muy sencilla y proporciona más de 60 gráficas y cerca de 100 indicadores del estado y rendimiento de nuestro servidor sin que apenas tengamos que despeinarnos. Está escrito en perl, viene con una amplia colección de plugins (a la que se le añaden las múltiples contribuciones de los usuarios) y también admite monitorización de servidores windows.

La versión actual en los repositorios estables de Debian wheezy es 2.0.6-4 (de aproximadamente un año de antiguedad) que será la que instalaremos aquí. Si usas los repositorios de la versión inestable (sid) tienes disponible la versión 2.0.14. La máquina donde queremos instalarlo es un servidor LAMP típico con Apache2 y MySQL. Los paquetes necesarios son estos. Y sus dependencias, claro:

apt-get install munin munin-node munin-plugins-extra

NOTA: La versión de munin en una debian estable es la 2.06 mientras que en backports tienes disponible la 2.0.19. Si quieres instalar esta última basta con que sigas las instrucciones que se te indican aquí.

La instalación por defecto en Debian configura Munin para que sólo pueda accederse a la instancia web de monitorización desde la misma máquina en la que hemos realizada la instalación. Para solucionar esto y poder acceder en remoto a través de un navegador tenemos que editar el fichero /etc/apache2/conf.d/munin en el que se encuentra la configuración de la instancia web. Buscamos la directiva <Directory /var/cache/munin/www> y en su interior comentamos las líneas siguientes:

# Order allow,deny
# Allow from localhost 127.0.0.0/8 ::1

Y añadimos esta otra:

Order deny,allow

Luego repetimos la misma operación en las directivas <Location /munin-cgi/munin-cgi-graph> y <Location /munin-cgi/munin-cgi-html>. Con esto el acceso será libre para cualquiera que conozca la URL de acceso. Si queremos proteger la entrada mediante usuario y contraseña podemos, por ejemplo, usar htdigest como contábamos por aquí en su día.

Y listo. Ahora recargamos la configuración de apache:

service apache2 reload

Y ya podemos acceder a través de la URL http://ip-del-servidor/munin/. La pantalla inicial, una vez introducida la identificación, es así de ~~sosa~~ minimalista:

Primera ejecución de munin. Pantalla inicial.

ACTUALIZACIÓN: Si realizas la instalación en Debian 8 (esta entrada se escribió aún con la versión 7) o actualizas a ella existen ciertas diferencias introducidas por la nueva versión de Apache, la 2.4. En el directorio de configuración de munin (/etc/munin/) te encontras un fichero llamado apache24.conf. Asegurate que es a este al que apunta el enlace que se encuentra en el directorio /etc/apache2/conf.d con el nombre de munin. Luego edítalo y modifica las dos veces en las que aparece la línea Require local sustituyéndola por Require all granted. Recarga la configuración de apache y listo.

Vamos a pararnos un poco a ver donde ubica sus diferentes elementos. Como ya hemos comentado, munin usa una estructura cliente servidor con nodos recolectores en cada uno de los equipos que queremos monitorizar y un elemento que centraliza la información de todos ellos. El daemon del primer elemento se llama munin-node y el del segundo munin. Ambos son servicios que residen, como es habitual, en el directorio /etc/init.d y responden a los argumentos habituales (start y stop). munin-node responde, además, a restart (necesario cuando añadimos un nuevo plugin o modificamos la configuración de uno ya existente) y alguno mas.

Los archivos de configuración se encuentran en /etc/munin/. Existen, entre otros, un archivo por cada uno de los servicios (munin.conf y munin-node.conf) y un directorio donde se encuentran los plugins en uso de este nodo. El procedimiento para activar los plugins es crear un enlace en este directorio al archivo que contiene el código del plugin. Los que vienen por defecto con la instalación se encuentran en /usr/share/munin/plugins/.

Por último, los datos de la instancia web de monitorización se encuentran en /var/cache/munin/www/, la base de datos en bruto en /var/lib/munin/ (no, no usa mysql como hace cacti), y los logs en /var/log/munin.

Volvemos al pantallazo anterior. En la parte central tenemos acceso a las diferentes máquinas monitorizadas ordenadas por grupos (en nuestro caso sólo una) Mientras que en la barra de la izquierda, abajo, tenemos un menú organizado por categorías con acceso directo a las gráficas diarias, semanales, mensuales o anuales de cada una de ellas. De cualquiera de las formas accedemos a una colección de gráficas pero con una pequeña diferencia. Si accedemos a través del menú superior llegamos a una página donde se encuentran todas las gráficas almacenadas en dos versiones, diaria y semanal (semanas, en realidad, de ocho días 🙂 , muy bien pensado para detectar mejor las secuencias):

Munin - Gráficas del sistema diarias y semanal

Mientras que si pulsamos en el lateral sólo se nos muestra la lista de las gráficas de la categoría elegida y exclusivamente en la modalidad de vista elegida según la letra que pulsemos: diaria (d), semanal (w), mensual (m, 33 días aproximadamente) o anual (y, 13 meses):

Munin - Gráficas de postfix diarias

Pulsando sobre cualquier gráfica accedemos a la vista en mosaico de las cuatro vistas disponibles antes mencionadas y si de nuevo pulsamos sobre cualquiera de ellas llegamos a una vista ampliada de la misma con un panel de control desde el que podemos, analítica o gráficamente, hacer la ampliación o reducción de cualquier zona de la misma:

Munin - Gráfica de Load Average

NOTA: Lógicamente, los gráficos de una instalación recién concluida no presentan este aspecto. Tendrás que esperar al menos 24 horas para ello 😉

Lo normal tras la instalación inicial es que, como nos ha pasado, no te instale los plugins correspondientes a apache y mysql debido a que falta algún prerequisito para ello. munin viene con un asistente llamado munin-node-configure que identifica cuales de los plugins que tienes en tu sistema están activos, cuales te podrían ser útiles… Incluso te asiste dándote el comando que necesitas para crear los enlaces necesarios al archivo y directorio adecuados. Échale un vistazo al enlace anterior de este párrafo para más detalles.

Para MySQL, en concreto, basta con que instaléis el siguiente paquete:

apt-get install libcache-cache-perl

Para apache2 necesitamos también instalar una librería extra de perl:

apt-get install libwww-perl

Además, debemos añadir la siguiente línea (o asegurarnos de que ya está) en el fichero /etc/apache2/mods-available/status.conf:

ExtendedStatus On

Y habilitar los módulos status e info de Apache:

a2enmod status info

Por último, reiniciamos el servidor web:

apache2ctl graceful

Creamos los enlaces a los plugins (fíjate en la forma diferente de hacerlo para mysql que se trata de un wildcard plugin) y reiniciamos el recolector de munin de esta máquina:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/apache_accesses
ln -s /usr/share/munin/plugins/apache_processes
ln -s /usr/share/munin/plugins/apache_volume
ln -s /usr/share/munin/plugins/mysql_ mysql_bin_relay_log
ln -s /usr/share/munin/plugins/mysql_ mysql_commands
ln -s /usr/share/munin/plugins/mysql_ mysql_connections
ln -s /usr/share/munin/plugins/mysql_ mysql_files_tables
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_bpool
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_bpool_act
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_insert_buf
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_io
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_io_pend
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_log
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_rows
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_semaphores
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_tnx
ln -s /usr/share/munin/plugins/mysql_ mysql_myisam_indexes
ln -s /usr/share/munin/plugins/mysql_ mysql_network_traffic
ln -s /usr/share/munin/plugins/mysql_ mysql_qcache
service munin-node restart

Y con esto (tal vez tengas que esperar unos minutos para ver los resultados) ya tenemos dos categorías nuevas (apache y mysql2) con las gráficas correspondientes. Un par de ejemplos de cada una de ellas:

Munin - Gráfica de threads de Apache

Munin - Gráfica de operaciones de MySQL

Existen muchos otros plugins de monitorización que os pueden ser útiles (asterisk, bind9, memcached, varnish…). En algunos casos puede ser necesario instalar algún otro requisito o realizar algún cambio en la configuración como nos ha ocurrido con Apache y MySQL. Como siempre, lo mejor en el caso de que simplemente creando el enlace al plugin este no funcione es buscar información (que es lo que yo he hecho con estos dos, no creáis que hay muchas otras formas de resolver estas cosas 😉 ). También es sencillo eliminar cualquier gráfico que no nos interese en absoluto simplemente borrando el enlace del plugin correspondiente y reiniciando munin-node. Si tenemos duda acerca del plugin que genera la gráfica, el nombre del archivo aparece en la pantalla de los datos que nos permite realizar zooms de los datos. Añadir otros nodos para centralizar la monitorización de los mismos en esta máquina es bien fácil, pero ya lo dejamos para otro día 😉

En definitiva, se trata de una herramienta mucho más potente que cacti que nos proporciona toda la información que podemos desear de una máquina y más sin apenas consumir recursos. Hecho en falta, tal vez, la facilidad de cacti para crear vistas personalizadas con ciertos gráficos que te interesa consultar de forma habitual. Y, por supuesto, no es tan cómoda como Cacti para monitorizar electrónica de red usando snmp. Pero bueno, no se puede tener todo ¿no?

enlaces rápidos

7 enlaces 7 (y LII)

Publicado en 7 de junio de 2013 por Josemaría / 0 comentarios

CrunchBang, una distribución ligera basada en Debian que usa Openbox como gestor de ventanas.
Pidora. Otra distribución interesante. En este caso se trata de un remix de Fédora para procesadores ARM pensado para la Raspberry Pi.
Tioki, el Linkedin de los profesionales de la educación. No parece haber mucho movimiento fuera de los EE.UU., pero por si acaso mi perfil público es este. Que lo mismo, tal y como están las cosas, en breve me toca buscar trabajo… ¡Ay!
Lungo, un framework para crear aplicaciones para móviles con HTML5.
Better WP Security y Wordfence. Existen muchos pero estos son, posiblemente, los dos plugins más completos para securizar WordPress. Tal y como están las cosas últimamente más te vale hacerte con alguno de ellos…
Detectando webshells o backdoors en servidores web. Por si sospechas que has llegado tarde a instalar alguno de los anteriores, aquí tienes diversas formas de auditar de forma automática si tienes algún intruso en tu servidor.
allPebble.com. Appstore no oficial de aplicaciones para Pebble. Por si ya tienes el tuyo en casa y te gusta el riesgo… 😉

patrocinadas

Entradas patrocinadas

Publicado en 6 de junio de 2013 por Josemaría / 1 comentario

Entrada patrocinada

A partir de ahora tal vez habrá, por primera vez en sus ocho años de existencia, alguna entrada patrocinada en este blog. Estarán lo suficientemente diferenciadas del resto con una línea de subtitulo como la que aparece aquí arriba, un icono y un estilo diferenciado. Como esta entrada, vaya. Todo transparente y sin engaños. (Esta, en realidad, no está patrocinada ¿Alguien ve un enlace en algún sitio, eh? 😉 )

Las motivaciones son dos. La primera el dinero, claro. La publicidad en los blogs está cada vez peor. Sobre todo la no intrusiva (básicamente enlaces laterales que es lo que siempre ha habido por por aquí) y, aunque os parezca increíble, las ofertas por publicar entradas patrocinadas para un «blog de medio pelo» como este superan en importe a lo que muchos medios nacionales le pagan a un colaborador por una pieza pequeña. No necesito la publicidad del blog para vivir, la verdad, pero me he mal acostumbrado a que sufrague el coste de su mantenimiento (dominios, hosting…) y a que me permita algún que otro capricho que algunas veces comparto por aquí con vosotros (chismes, ordenadores, cámaras…) y otras veces disfruto con mi esposa y mi pequeño para compensarles por el tiempo que esta dedicación me sustrae.

Lo segundo que me ha llamado la atención en la oferta que me han hecho es que no se trataba de hablar bien (o mal) de un producto que ni siquiera conozco (es decir, de engañar a los lectores), sino de engañar a Google para posicionar determinadas búsquedas. Eso que tradicionalmente se llama SEO y que a mi siempre me ha parecido un poco de prestidigitación y algo de charlatanería. Engañar a Google, una empresa cada vez más dictatorial con sus normas e imposiciones me parece hasta sano, para que negarlo. Además, me resulta divertido. Mientras me hacían la primera propuesta me he acordado de un viejo juego que practicaban dos amigos periodistas que trabajaban en medios diferentes y que luego acabaron casándose. El juego consistía en que cada día elegían una palabra antes de saber que les tocaría escribir al día siguiente. Luego, escribieran lo que escribieran, tenían que insertar esa palabra en el texto de forma coherente. Estoy hablando de mediados de los 90 cuando Internet era casi inexistente en nuestro país y Larry y Sergey aún se preocupaban más por sus espinillas que por nuestros datos. Tal vez estos dos amigos míos, sin saberlo, inventaron el SEO.

Imagino que, como siempre, habrá a quién le parezca mal, habrá quién lo vea bien, y quién lo verá mal hasta que lo invite a una cena con los primeros pagos y a partir del momento lo empezará a ver bien de nuevo. Ya nos contamos… 😉

blogosfera/efemérides/muy personales

2922 días

Publicado en 2 de junio de 2013 por Josemaría / 4 comentarios

O, lo que es lo mismo, 8 años
en los que he cambiado 4 veces de trabajo,
he publicado 999 ~~entradas~~ ~~notas~~ ~~noticias~~ chorradas,
habéis dejado 4600 comentarios,
he paseado por seis países en tres continentes diferentes,
me he casado,
me he mudado una vez de casa
y 5 de hosting,
he trabajado de forma habitual con 10 distribuciones diferentes de Linux y con cinco gestores distintos de ventana,
he visto pasar seis versiones de Windows
(¡un par de ellas horrendas!),
he tenido un hijo,
han pasado por aquí algo más de 2 millones de visitantes
(¡muchos de ellos no humanos!)
un millón y medio distintos
y el resto ~~masocas~~ reincidentes,
que han visto en total unos 7 millones de páginas…

¿Quién dice que no he aprovechado el tiempo?

NOTA: Los datos de visitantes y páginas son una estimación en base a la evolución de visitas que ha tenido el blog y a los datos estadísticos de los últimos cuatro años que son los que conservo.

Un lugar en el mundo…