sábado, enero 23, 2010

21 días no es nada

Para todos que se asombren ante la osadía de Samanta Villar y su nueva entrega del programa 21 días, tengo que decirles que un servidor estuvo 16 meses en la industria del porno (u ocio para adultos) y se de amigos que han estado más tiempo. No es por quitarle mérito a lo que haga, pero hay queda eso.

Diferente sería si estuviera '21 días donando órganos', eso sí que podría considerarse un gran reto.

lunes, enero 18, 2010

Así se extinguió el Lince (dos veces)

El deseo por parte de las autoridades gobernantes de tener controlada la escasa población de Linces ibéricos y saber en todo momento que tal se encontraban, les llevó a comprar unos carísimos radiocollares, que colocarían en los peludos cuellos de los animales, después de una campaña de captura y marcaje de los especímenes que quedaban por nuestros bosques.

Meses después, las autoridades estaban muy contentas con el resultado de la compra, incluso pusieron un página web -2.0- en la que podía verse ¡online! la cantidad de ejemplares.

Pero algo trágico ocurrió a finales del año, cuando el general invierno envió intensas nevadas que cubrieron las montañas donde el Lince vivía. En el plazo de una semana, las señales de los animales desaparecieron del radar elevándose una señal de alarma de los expertos. Cuando las autoridades reaccionaron era tarde. No había rastro de ellos y los dieron por muertos.

Pasados unos meses y siendo transitable la sierra, algunos cazadores informaron de avistamientos de Linces: ¡Viven! La culpa fue de las baterías de los radiocollares, que se agotaron y el Lince no tenía el cargador a mano.

Ante tal error, las autoridades adquirieron unos nuevos collares cuya duración de batería estaba garantizada por miles de años. Otra vez se organizó una campaña de captura y sustitución de radiocollar. La página web -2.0- volvío a funcionar a todo trapo, siendo el orgullo del ministro de medio ambiente de turno.

Pero la alegría no duró mucho, apenas un año. Al cabo de ese periodo de tiempo, se fueron encontrando Linces ibéricos moribundos, que aparecían enfermos, desnutridos y sin pelo, producto de un envenenamiento radiactivo por una fuga de la batería del radiocollar. Poco pudieron hacer por ellos. Y esta vez, la cagaron de verdad.

PD: Concurso público del suministro de Radiocollares para el Lince Ibérico

7-0

Se puede decir que he tenido una guardia tranquila. Ninguna llamada durante la semana. El resultado del partido da muestras de ello.

sábado, enero 16, 2010

Regalos abrigados

Uno de los regalos de reyes que me hicieron fue darme dinero para que me comprase un abrigo que me gustase. Lo tenía muy claro, los abrigos que me gustan son largos estilo películas de gansters de los años 20 -como el que lleva Tom Hanks en Camino a la Perdición-.

He aprovechado para comprarme uno algo más largo que él que tengo, con el bolsillo interior a la izquierda en lugar de la derecha y que no se vean los botones cuando se abrocha. Ahora ya puedo ir dándole boleto al mio viejo, que se me había quedado pequeño y estaba algo repasadito. Ayer lo recogí.

En Sevilla ndebería hacer más frio y durante más tiempo al año.

viernes, enero 15, 2010

La bombilla se iluminó

Pensaba que me iba a costar mucho trabajo monitorizar el programa de copias de seguridad EMC NetWorker, pero esta mañana me dió por mirar el sistema de notificación, que por defecto asocia la ejecucíon de programa del sistema a un determinado evento, para darme cuenta que el ejecutable que ejecutase podría ser cualquiera que yo quisiera. Más aún, aunque el soporte de networker del protocolo SNMP es muy pobre, incluye una herramienta llamada nsrtrap que encapsula todos sus mensajes dentro de un único OID, con un formato especial.

El truco esta en crear una notificación, asociada a todos los eventos, para que mande un trap al servidor snmptrapd. Luego simplemente hay que instalar un manager para el OID de networker que parsee la notificación del trap. Simple y efectivo.

1 Tan pobre que ni siquiera dan la especificación de mibs y para su integración con algun NMS tienes que pagar una licencia adicional.

martes, enero 12, 2010

Otra nevada

Para uno que no tiene mucha experiencia en esto de que nieve no esta mal la que cayo el otro dia cerquita de Sevilla. Intente llegar al pueblo de mis padres, pero la carreta, a la altura de la media fanega (venta del alto, entre el Ronquillo y las Pajanosas) no hacia aconsejable seguir.

En poco mas de un mes he vivido dos nevadas :-)

viernes, enero 08, 2010

Apple contra Linux

No comprendo porque Apple se empecina en no hacer el iTunes compatible con Linux.

Cualquiera que quiera meter cosas en los iPod Touch (extensible a iPhone) de Apple tiene que usar por cojones el software de iTunes que solo funciona bajo MacOS o Windows. En principio no hay otras opciones -obvio usar la AppStore y el iTunes web que son para comprar cosas y que necesitan por guebos de una tarjeta de credito para activar tu cuenta-.

Decía que en principio no hay más opciones pero no es así, hay dos opciones más.

La primera, conocida por muchos se basa en liberar el iPod (Touch/iPhone), que es un proceso bastante cómodo y que te da paso a otro mundo independiente del universo Apple, con el inconveniente de que empiezas a utilizar aplicaciones clónicas para la parte básica del aparato.

La segunda, que he probado recientemente se basa en utilizar una maquina virtual dentro de Linux. Esa maquina virtual, que tiene instalado el sistema operativo windows, corre sobre VirtualBox. De esta forma consigues utilizar el iTunes instalado en el windows de la maquina virtual. El engorro es que cuando quieres pasar algo al aparato mediante iTunes, debes pasarlo previamente a la maquina virtual y luego lo pasas al ipod mediante el iTunes, obligando a hacer un paso intermedio.

Como veran hay opciones, pero Apple sigue sin sacar la versión para linux, discriminando a sus clientes linuxeros. Aunque me gusta mucho el aparato, me toca la moral esto.

jueves, enero 07, 2010

Cáculo de la teoría de ir rápido cuando llueve

Hace tiempo emitieron un programa de los cazadores de mitos en los que intentaban averiguar si es útil correr cuando esta lloviendo. En las pruebas, bastante limitadas, no llegaron a una conclusión.

Más tiempo aún hace que hable de ese tema con un amigo en la que eramos de opiniones diferentes, él decía que era una tontería correr porque te mojabas más y yo decía que no tenía por qué.

Me parece que ese problema es posible resolverlo, matemáticamente hablando, de una forma parecida a los problemas de cálculos de máximos y mínimos en segundo de BUP. Aquel problema del socorrista que tenía que calcular el punto exacto en donde se tenía que tirar al agua para salvar al nadador con el tiron muscular y salvarlo antes de que se ahogara es el ejemplo, que resolvía aplicando derivadas primeras y segundas a las función de distancia recorrida en función de la velocidades del socorrista cuando iba corriendo por el borde de la piscina y nadando en dirección al nadador.

En este caso, hay que hacer una función que calcule la cantidad de agua por unidad de volumen y otra función que calcule la cantidad de unidades de volumen que traspasa nuestra superficie dependiente de la velocidad.

Esta claro que teniendo una cantidad de lluvia constante, al ir más rápido iremos pillando más agua por unidad de tiempo y superficie, pero al ir más rápido estaremos menos tiempo sometidos a la lluvia. Lo importante es averiguar cual es la velocidad justa a la que debemos ir.

Y todo esto lo pensé esta mañana mientras conducía, esperando en un semáforo y viendo como caía el agua sobre el cristal de coche. Es lo que tiene que llueva tanto por Sevilla, que no estamos acostumbrados, el cerebro se nos vuelve agua y nos ponemos a pensar en matemáticas.

Reyes tolkinianos

Los reyes trajeron la Enciclopedia Tolkien Ilustrada. Un compedío de la tierra media que había pedido muchas veces antes -estaba siempre en mis listas de regalos- pero que se resistía. Tan contento estaba que por la noche puse la versión extendida de la Comunidad del Anillo.

lunes, enero 04, 2010

Las sartenes y el Aloe Vera

Tenemos una sartén muy graciosa en casa que no tiene mango. En su momento tenía mango, pero se le cayo, quedando solo un pequeño apéndice de metal. No caí en la cuenta de que cuando se pone al fuego, ese apéndice también se calienta. El resultado es que me queme el dedo indice y el gordo de la mano. Fizzzzzzzzz.

El remedio para las graves quemaduras1 ha llegado de manos de una maceta de Aloe Vera, arrancándole un poco y refregándolo por la superficie afectada (mis dedos y no la sartén!). Pobre maceta planta, que sufrida es2.

1 To cuento, pero me aprovecho.
2 Hay que crear un grupo del Feisbuk pro Aloe Vera.

domingo, enero 03, 2010

La nimiedad que obvié

Para hacer funcionar el Ipod Touch con la máquina virtual de VirtualBox sólo me faltaba el detalle de ejecutarla maquina como Root. Una nimiedad que pase por alto y que hizo que el Windows dentro de la máquina virtual nunca pudiese interactuar con los dispositivos USB engachados al linux.

Ahora ya puedo ejecutar el itunes correctamente. De todas formas, sigue sin gustarme itunes.

sábado, enero 02, 2010

Ocasión perdida

Fui a ver Solomon Kane al cine esta tarde y no es nada del otro mundo. Típica película para pasar el rato, con cierto aire Van Helsing. Sabía a lo que iba.

Creo que ha sido una ocasión perdida para ver la de Avatar, que tengo curiosidad por aquello del 3D, pero no consigo coincidir con ningún colega para ir a verla.

viernes, enero 01, 2010

Una pequeña aplicación

Desde hace algo más de cuatro meses estoy enfrascado en una tarea interesante que tengo que hacer en el trabajo. Se trata de hacer que las alarmas de todo tipo de aparatos hardware (cabinas de discos, chasis blade de virtualización, librerías de cintas, SAIs, electrónica de red, balanceadores) estén integradas en el Nagios.

Nagios es la aplicación que utilizamos para monitorizar las aplicaciones y que nos martiriza avisa cuando hay algún problema.

A bote pronto la cantidad y variedad de chismes que tenemos es grande, con lo que la tarea puede ser abrumadora:
  • Cabinas de disco NetApp y SGI.
  • Balanceadores Alteon y BipIP.
  • Electrónica de red Cisco, HP y MRW.
  • Switches de fibra Brocade.
  • Chasis Blade de Egenera y HP.
  • Virtualización PrimeQuest de Futjisu.
  • Librerias de cintas virtuales CentricStor de Fujitsu.
  • SAIs Merling-Gerin, Riello y APC.
Todos estos aparatos tienen en su interior un agente, que implementa el protocolo SNMP, encargado de notificar mediante traps (mensajes especiales SNMP) determinados sucesos. En el caso de un switch cisco un suceso puede ser la desconexión de un cable de red y para una cabina de disco puede ser el fallo de uno de sus discos. Esto incrementa la complejidad, ya que no solo hay que tratar con muchos aparatos, sino que estos pueden notificar cualquier cosa que les venga en gana.

La forma de implementar una sistema que recoja los traps y que los transforme en alarmas para el nagios se basa en aprovechar varios demonios -no hay que reinventar la rueda- llamados snmptrapd y nsca.

El primero, snmptrapd, es una aplicación que recoge las notificaciones que les envian los agentes y que segun sea esa notificación puede ejecutar un script -manager-. Se puede hacer que el script manager sea genérico, es decir que sea invocado ante cualquier trap, o que sea determinado según sea el trap recibido.

La lógica de los managers es bastante sencilla. Primero recoge el OID del trap, que es un identificador de la notificación. Cada trap diferente tendrá un OID distinto. Luego tratará los parámetros del trap. Como existen parámetros comunes a todos los traps y otros especificos, el manager se encarga de saber que parametros recoger y qué hacer con ellos.

Por último, la lógica del trap determinara como notificar al Nagios del problema. Para ello se sirve del otro demonio llamado nsca, que no es más que un sistema para enviar mensajes al Nagios con el nombre del servicio, una gravedad del problema y listo.

Hasta el momento, mi implementación consistía en realizar un manager en bash por cada tipo de sistema hardware a monitorizar. De esa forma tengo un manager para cabinas de disco Netapp, otro para los chasis blade de Egenera, etc. Y un manager general para guardar en un log todas las notificaciones.

Una de las parte más complicadas es averiguar cuales son los traps que suponen que existe un problema y cuales son aquellos que pueden indicar que el sistema ha vuelto a la normalidad. Para ello es indispensable disponer de la especificación de los MIBs del dispositivo. El mib contiene la relación de OIDs de los traps y variables del dispositivo.

Casi todos los dispositivos que disponen de un agente snmp, el fabricante ofrece el MIB del mismo, siendo posible entender sus problemas. De esa forma, la lógica del script se reduce al manejo de unas notificaciones y poco más.

Llegados a cierto punto, uno se da cuenta de que no puede estar creando script para cada tipo de dispositivo, sino que debe haber algo más general.

Lo primero es entender que el funcionamiento de un sistema de alerta para un dispositivo cualquier se basa en una maquina de estado con cuatro estados 'de notificación' distintos.
  • OK. El dispositivo esta funcionando correctamente. No hay problemas.
  • Warning. El dispositivo esta funcionando pero hay ciertas partes que tienen problemas y que es posible que hagan que el aparato deje de funcionar.
  • Critical. El aparato no esta funcionando bien. Existe algun problema que no le deja hacer su función.
  • Unknow. Algo le pasa pero no se sabe concretamente en que consiste o se desconoce el estado del funcionando del aparato.

Los traps que envia el agente snmp del aparato no hacen otra cosa que cambiar el estado de notificación. Si llega un trap 'de warning', el estado del dispositivo se pone Warning. Si es de Ok, entonces pasamos a Ok. Estos cambios de estados son independientes del estado anterior que pudiese tener el aparato.

Así que estoy empezando a hacer un programita que reuna el trabajo de configurar un manager y traducir sus estados de notificación a algo visual e incluso pueda notificar los cambios a terceros programas (nagios por ejemplo).

El programa tiene los siguientes componentes:
  • Manager general, instalado como manager 'default' del demonio snmptrapd, que guardará las notificaciones en una base de datos.
  • Manager despachador, que es el encargado de determinar que manager específico se tiene que ejecutar en función de la notificacion que ha llegado y del dispositivo que lo envia.
  • Cliente de estados que consulta la base de datos y muestra el estado de un dispositivo.
  • Cliente configurador de manager específicos que sirve para configurar la máquina de estados de notificación de un dispositivo.
La idea inicial era realizarlo en PHP (actualmente lo tengo realizado en Bash la parte de los managers), pero la parte de los clientes puede resultarme complicada, por ello esa parte la voy a realizar en Java. No he realizado nada serio en este lenguaje y tengo el gusanillo.