Tag sysadmin - Userlinux.net

Llevo desde el fin de semana con la mosca detrás de la oreja. Uno de los servidores que administro ha visto incrementada de forma inexperada su carga media de CPU sin motivo aparente. Donde el load average normal de 1 minuto variaba entre 0.40 y 0.80 de repente suponía cargas tan elevadas como 60 o 100 unidades.

En esos momentos puntuales que llegaban a dejar la máquina zombie el proceso que abarcaba un consumo de entre el 60% y el 90% de CPU era apache2. Intrigante que ni error.log ni slow-queries.log de MySQL (lo que normalmente suele ser cuello de botella) dieran ninguna pista.

Hace tiempo que quería escribir esta pequeña nota sobre algo que genera demasiada confusión, el load average.

El load average o media de carga de un sistema es un conjunto de tres números que podemos ver en diversas herramientas como uptime o top. Estos números representan el número medio de procesos del sistema que durante los últimos 1, 5 y 15 minutos han estado esperando por algún recurso del sistema (CPU, acceso a disco, red, etc.).

[root@local ~]# uptime
 19:26:28 up 4 days, 22:58,  5 users,  load average: 4.35, 4.30, 3.59
[root@local ~]# top
top - 19:26:54 up 4 days, 22:59,  5 users,  load average: 4.32, 4.20, 3.90
...

En el ejemplo la salida del comando 4.30 significa que durante los últimos 5 minutos una media de 4.30 procesos han sido bloqueados esperando por alguna asignación de recursos. Cuando alguna de estas tres cifras es muy alta no significa necesariamente que la CPU esté sobrecargada, hay otro tipo de herramientas como top, vmstat, iostat, vnstat, etc que podemos usar con la finalidad de averiguar que procesos o recursos están afectados.

Nota: Este artículo es una traducción, la fuente original del artículo en inglés, Redes Privadas Virtuales, un gran blog que se ha convertido en visita obligada para cualquier sysadmin. Me he tomado la libertad de traducirlo puesto que es un tema muy interesante y, como dice el original, genera bastante confusión.

Porque los BOFH, aunque no queramos reconocerlo, también metemos la pata de vez en cuando. Esta vez me ha costado casi 2 meses de downtime de varias páginas, entre ellas el blog de mi compañero @mameyugo.

Una vez reinstalado el servidor y reiniciados todos los servicios damos por supuesto que todo funciona bien y a otra cosa mariposa. De hecho todo estaba up & running. El problema es que fuera de la red local el servidor de nombres... no servía los nombres por un pequeño detalle:

options
{
    listen-on-v6 { ::1; };
    listen-on { 127.0.0.1; 192.168.1.12 };
}

Vaya la que he liado. Pero ha sido sin querer, de veras, os lo prometo por Theo de Raadt. Mis disculpas caballeros.

Las tareas programadas en cron por defecto reportan un correo electrónico con la salida del comando a la cuenta local del propietario de la tarea. Si por alguna razón no queremos que ese correo se envíe tenemos varias alternativas que podemos encadenar para garantizarlo.

Por un lado podemos intentar eliminar la salida de errores en las tareas que hemos programado, bien en la propia tarea o bien haciendo uso de /dev/null/. Y por otro lado está el uso de la variable MAILTO en el cron del usuario, vamos a describir un poco más cada una de estas opciones.

Todos sufrimos con más frecuencia de lo deseado intentos de ataques por fuerza bruta en los servicios que ofrecen nuestras máquinas, es inevitable. Pero con herramientas como DenyHosts podremos controlar mucho mejor estos intentos de violación. Su instalación y posterior configuración son triviales, tan solo debemos comprobar que tenemos python instalado en el sistema y poco más:

# dpkg --list | grep python2
ii  python2.5...
# python -V
Python 2.5.2
# apt-get install denyhosts

Una vez instalado pasamos a configurar el archivo /etc/denyhosts.conf, que es el que tiene toda la chicha:

Después del owned con el que hemos puesto fin al 2009 ha llegado un nuevo servidor de desarrollo y con ello su consecuente migración (y problemas varios).

Ha llegado despiezado así que nos hemos puesto manos a la obra para restaurar el servicio cuanto antes, primero el hardware y luego -wiki en mano- los servicios correspondientes. El primer problema -que en principio no ha trascendido demasiado- ha sido la migración de los repositorios Subversion a la nueva máquina. Digo problema porque nunca había migrado un SVN, pero todavía sigue quedando gente que documenta estas operaciones para hacer la vida más sencilla a los demás.

Creo que si a algún software le he sacado partido y estoy absolutamente orgulloso de usar ese es GNU screen. Ya he hablado de él en numerosas ocasiones y no hago más que alabar sus características.

Cada día que juego un poco con sus opciones me quedo boquiabierto. Esta tarde ha sido por iniciativa de David Martínez, él también habla maravillas de screen.

Apticron es una de esas herramientas que agradecemos los sysadmins que tenemos máquinas Debian.

Se trata de un pequeño script que comprueba las novedades en cuanto a actualizaciones de software instalado se refiere y envía un correo/informe con la lista de updates.

Instalarlo es tan simple como hacer un apt-get install apticron, configurar la cuenta de correo a la que van a llegar los informes también es trivial:

$ nano -w /etc/apticron/apticton.conf
EMAIL="tu@correo.com"

Un servidor en el que se había instalado una OVH Release2 Group Manager (o algo así), los clientes no eran capaces de acceder al puerto 80 de Apache, todas las redirecciones se hacían al 443 por SSL. Me encuentro con esto en la configuración por defecto de Apache2:

# Forcing https
RewriteEngine On
RewriteRule ^(.*) https://%{SERVER_NAME}$1

Configuraciones por defecto... ¡Yo os maldigo! (por si no hace efecto el hechizo, decir que tengo un amigo brujo nivel 50).

A todos los que se lo merezcan.