Archivo de la categoría: informática

Cambiar el estado devuelto por un monitor de Nagios

Posted on por
Responder

En algunas ocasiones se puede necesitar que un monitor de Nagios nunca devuelva el estado CRITICAL, considere el estado UNKOWN como WARNING, invierta el estado OK por CRITICAL, etc. A priori se podría pensar en modificar el plugin o jugar con Bash, pero para invertir o cambiar el resultado de un plugin está negate.

Por ejemplo, en el caso de querer utilizar el plugin check_ping para saber si una máquina está en la red o no, pero que en caso de que no lo esté (como que se agote el timeout) el estado devuelto sea WARNING y no CRITICAL. Se llamaría a negate tal que:

  • Se le indique un timeout superior al de check_ping, que en caso de superarse devolvería CRITICAL, porque supondría que el plugin objeto de la comprobación no está funcionando bien.
  • Que sustituya la cadea que representa el estado, que aunque Nagios hace caso del código de salida así el texto devuelto será acorde al número.
  • Se le indique que reemplace el estado CRITICAL por WARNING.
  • Se añada al final el plugin y argumentos cuya salida se quiere invertir según convenga.

Hablando en línea de comandos sería algo así:

# /usr/lib/nagios/plugins/negate -t '20' -s -c WARNING /usr/lib/nagios/plugins/check_ping -H '192.168.1.3' -w '5000.0,80%' -c '10000.0,100%' -p '1' -t '10'
PING WARNING - Packet loss = 100%|rta=10000.000000ms;5000.000000;10000.000000;0.000000 pl=100%;80;100;0
# echo $?
1

En cambio si no se usase negate el plugin devolvería el estado CRITICAL:

# /usr/lib/nagios/plugins/check_ping -H '192.168.1.3' -w '5000.0,80%' -c '10000.0,100%' -p '1' -t '10'
PING CRITICAL - Packet loss = 100%|rta=10000.000000ms;5000.000000;10000.000000;0.000000 pl=100%;80;100;0
# echo $?
2

Fuente → Nagios only create warning for a http service [Server Fault]

Alta disponibilidad de Internet con Linux (i)

Posted on por
Responder

En unos firewalls con Linux hay infinitas maneras de intentar conseguir alta disponibilidad de salida a Internet, aunque todas tienen sus inconvenientes. Voy a contar un ejemplo combinando Conntrack, Iptables, Corosync, Pacemaker y un script inspirado en la solución de amperis.

Una de las soluciones que primero se vienen a la cabeza es utilizar un algoritmo de pesos con ip route según la relación de velocidad de los proveedores contratados o nuestras preferencias, configurando una ruta por defecto multicamino. Pero esto pronto empezará a dar problemas en según qué conexiones o aplicaciones al encontrarse que según qué paquetes les llegan por distintas IP públicas, como las páginas de los bancos. Y aunque la lógica de dividir el tráfico entre proveedores también puede hacerse con iptables y el módulo statistic, no se evita el problema del multicamino.

Justo acabo de mencionar a iptables […] (continuar leyendo)

Recargando un servidor de Node.js con WebSocket

Posted on por
Responder

Un sencillo servidor corriendo sobre Node.js puede permitir la recarga sin interrupciones, de manera amistosa, algo parecido al reload de Apache u otros demonios en Linux. Para ello sólo es necesario que haya un proceso padre que lance hijos y les envíe señales según sea necesario. Sin embargo el cierre de las conexiones esperando a que estas terminen puede dar algunas complicaciones cuando hay un WebSocket.

La gestión de padre e hijos se puede hacer con el módulo cluster. En este ejemplo el script a lanzar manualmente es master.js. Él a su vez lanzará al script server.js y le pasará las señales SIGHUP para recargar el servidor (terminar amistosamente) o SIGTERM para terminar sin piedad.

master.js:

'use strict';

var cluster = require('cluster');
const path = require('path');

cluster.setupMaster({
  exec: path.join(__dirname, 'server.js')
});

//fork the first process
cluster.fork();

process.on('SIGHUP', function () {
  var new_worker = cluster.fork();
  new_worker.once('listening', function () {
    //stop all other workersS
    for (var id in cluster.workers) {
      if (id === new_worker.id.toString()) continue;
      cluster.workers[id].process.kill('SIGHUP');
    }
  });
}).on('SIGTERM', function () {
  for (var id in cluster.workers) {
    cluster.workers[id].process.kill('SIGTERM');
  }
});

[…] (continuar leyendo)

Anotaciones para un CPD

Posted on por
Responder

Montar un centro de procesamiento de datos o una sala de máquinas es de esas cosas sobre las que todo el mundo sabe pero que pocos quieren echarse al hombro. Es fácil acabar aglutinando a un montón de empresas de distinto oficio y beneficio, cada una encargándose de una cosa, pero sin una supervisión común ni fina. Lo cual suena a tiquismiquis, pero asegurarse de que todo quede como debe ahorrará muchos quebraderos de cabeza y misterios a futuro.

El que escribe esto es como todos, con muchas ideas, pero que tampoco sabe diseñar la construcción de un Centro de Procesamiento de Datos de principio a fin. Sin embargo puedo aportar algunos detalles.

Ubicación. Partimos de la base de que vamos a tener una sala llena de máquinas con un considerable valor económico, pero que a su vez van a albergar una información y prestar un servicio con mucho más valor, que es el que realmente va a dar dinero. De manera que es necesario elegir un lugar con:

  • Acceso restringido. Que no sea el c**o de la Bernarda.
  • Unas variables físicas estables. No como el desierto con sus cambios de temperatura.
  • Una temperatura del aire que absorben las máquinas comprendida entre 24 ºC y 26 ºC o incluso mayor. Es una moda de los últimos años a favor de un menor derroche energético, que depende también de las máquinas y sus especificaciones. En CPD de lugares públicos, esos cuya factura de la luz pagamos entre todos, siguen con configuraciones de 19 ºC y tan pichis.
  • Una humedad relativa en torno a un 50 %. Este valor también depende de las especificaciones de las máquinas, pero si es baja pueden soltarnos chispotazos porque se carguen de electricidad estática, y si es alta los componentes empezarán a enrobinarse y tendrán una vida útil menor, cuando no empiecen antes a dar problemas misteriosos que nos hagan perder muchas horas intentado resolverlos.
  • Un entorno con bajo riesgo de catástrofes. Poco importa ponerle la puerta de un búnker, si luego está en un sótano, vienen lluvias torrenciales, el alcantarillado se inunda, los sumideros empiezan a expulsar agua en lugar de succionarla, las bombas de achique no dan abasto o se quedan sin suministro de electricidad,.. Como levantino sé bien que eso puede pasar.

[…] (continuar leyendo)

Listar sólo ficheros ordenados por fecha de modificación

Posted on por
Responder

Lo intuitivo sería pensar en usar ls -lt, pero si se quieren evitar directorios, ficheros con un determinado nombre, seguir enlaces simbólicos, que los caracteres de nueva línea nos la puedan jugar,.. find es más fiable que andar filtrando con grep los resultados. Aunque hay que pensar un poco para combinarlo con sort para ordenar los resultados por el primer campo (en tiempo POSIX con parte decimal) y sed para eliminar después el tiempo, que ya no nos sirve.

Algo así:

find -P . -maxdepth 1 -type f -printf '%C@ %p\0' | sort -znrk1 | sed -e 's/^[^ ]* //' -e 's/\x0[^ ]* /\x0/g' | while IFS= read -r -d '' i

OjO a ISF= y -d », que permiten dividir las ocurrencias y no zamparse los espacios en blanco que pudiera tener el nombre de un fichero al final.

Actualizar DNS de cPanel desde Bash

Posted on por
1

Hoy Dyn ha dejado de prestar de manera gratuita su servicio de DNS dinámico. Avisaron con un mes de antelación y yo que ya llevaba tiempo dándole vueltas a cómo poder utilizar un dominio y un hosting propio para eso, me puse a investigar y tuve suerte.

En los foros de cPanel encontré un mensaje con un script en Bash para actualizar desde consola nuestros registros DNS —que por motivos de licencias no puedo reproducir aquí—. Utiliza la api de cPanel para gestionar los dominios y es ideal por ejemplo para crearnos un subdominio y llamar al script periódicamente desde el cron de una máquina con Linux. Incluso una Raspberry Pi con una distribución a medida, al no necesitar de librerías extrañas. Está bien pensado, comprobando en cada ejecución si la IP actual es la misma que la anterior para ahorrar actualizaciones innecesarias y hasta puede mandar un correo electrónico en caso de errores.

La configuración para un ejemplo podría ser:

CONTACT_EMAIL="[email protected]"
DOMAIN="delospalotes.com"
SUBDOMAIN="micasa"
CPANEL_SERVER="cpanel.delospalotes.com"
CPANEL_USER="usuario de cpanel"
CPANEL_PASS="contraseña de cpanel"

Y fuera dependencias de servicios de terceros.

Fedora 20, Eclipse y Google Talk

Posted on por
Responder

Eclipse y el plugin de Google Talk no se llevan bien los toques en Fedora 20. Cada vez que Eclipse necesita renderizar contenido como si de un navegador web se tratase, intenta utilizar WebKit y se cierra inesperadamente. Por ejemplo al abrir su Marketplace.

La solución oficial no sé muy bien si corresponde a Eclipse o a Google Talk, pero de momento las dos formas más famosas de arreglarlo son:

  • Eliminar Google Talk:
# yum erase google-talkplugin
  • O bien editar el fichero de configuración de Eclipse (eclipse.ini) y esta opción para que utilice Mozilla:
-Dorg.eclipse.swt.browser.DefaultType=mozilla

Fuente → Google Talk plugin presence breaks Eclipse in Fedora 20 @ Chris Daniel.