[Jderobot-admin] Caída del servidor del finde pasado

[Borja Mon Serrano]

>
> No creo que se cargara el servidor web, posiblemente matara un proceso
> hijo que sería regenerado por el proceso apache padre. Estoy casi seguro
> que fue un hijo pq oom-killer deja los procesos cuyo id es "root" para
> los últimos, a parte de que trata de matar los procesos que llevan menos
> tiempo ejecutándose y los procesos apache hijos tienen una vida mucho
> más corta que el proceso apache padre. Eso asegura que servidores como
> apache o sshd seguirán en pie y sólo sus hijos (procesos workers) serán
> los sacrificados.
>

Puede ser que solo fuese un hijo, aunque con estas dos líneas:

Oct 27 22:54:42 jderobot kernel: Out of Memory: Kill process 6758 (apache2)
score 41572 and children.
Oct 27 22:54:42 jderobot kernel: Out of memory: Killed process 6758
(apache2).

Yo entiendo que lo que se cargó es apache y a todos sus procesos hijos.
Tampoco es algo que pueda afirmar rotundamente, ya que hasta el jueves
pasado no me había parado a analizar un syslog.


> El problema es que hay que dimensionar el servidor (o los procesos
> servidor) para la RAM que se tiene. Por ejemplo, limitar el número de
> procesos hijos que puede levantar apache (con zabbix sería bueno
> monitorizar el número) o usar un acelerador web como squid para
> aligerarle el trabajo.
>

He estado echándole un ojo a squid y parece un buen servicio. ¿Se
asemejaría al mod_pagespeed de Google [1] o es un servicio complementario?


> También se puede limitar el número de sesiones activas de un usuario
> en /etc/security/limits.conf (maxlogins) para evitar acumulaciones de
> intentos de entrada svn, rsync, ssh, etc.
>

Ahora mismo el control de acceso de usuarios al svn y a la wiki se hacen a
través de ldap. ¿Valdría también en este caso?


> Por otro lado hay que ver qué más procesos se levantan y si hay tareas
> programadas o bots que hagan algo de manera automática que se puedan ir
> acumulando si no terminan el trabajo en el tiempo que se suponía que
> debían hacerlo.
>

Hay varias tareas en cron que se ejecutan diaria o semanalmente. También,
cada hora, se hace un log del blog y de la wiki con webalizer. También hay
un proceso que se ejecuta cada media hora, aunque no sé quién lo está
lanzando (porque cron no es), que fue el último en ejecutar antes de la
catástrofe.

Oct 27 22:44:51 jderobot /USR/SBIN/CRON[29129]: (root) CMD (  [ -d
/var/lib/php4 ] && find /var/lib/php4/ -type f -cmin
+$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm)
Oct 27 22:44:51 jderobot /USR/SBIN/CRON[29055]: (CRON) error (grandchild
#29129 failed with exit status 1)

He estado viendo que ese proceso siempre da error.

¿Has restado a esa cantidad la caché de disco usada?
>
> redstar en greystar:~$ cat /proc/meminfo
> MemTotal:        2431608 kB
> MemFree:          512600 kB
> Buffers:          189232 kB
> Cached:           470668 kB
>
> redstar en tauri:~$ cat /proc/meminfo
> MemTotal:        4020452 kB
> MemFree:          549760 kB
> Buffers:          709448 kB
> Cached:           536100 kB
>
> Aunque pone en ambos casos que la memoria libre es cerca a 512 MB es
> falso, a eso hay que añadirle la totalidad de la caché de disco (Cached)
> que es descartada cuando se requiere memoria RAM y parte de los buffers
> (sockets, archivos, etc) que también pueden ser liberados.
>
> ¿Tuviste en cuenta esos datos para tomar la medida de uso de memoria? ¿O
> usaste el valor que te ponía algún comando como top o free?
>

No, no lo tuve en cuenta, cogí los datos que te ofrece free directamente
sin tener en cuenta la caché. Por ejemplo, ahora mismo:

jderobot:~# free -m
             total       used       free     shared    buffers     cached
Mem:          2020       1856        163          0        466        780
-/+ buffers/cache:        609       1410
Swap:         1608          0       1607

Querría decir que tenemos 163MB (aproximadamente) libres, pero que si
hiciese falta un poco más se liberaría parte (o toda, según se requiriese)
de la cacheada, que son ~780MB, ¿no?


> El problema es que el syslog pudo ser matado y dejó de loguear eventos,
> por eso es bueno tener un watchdog configurado. En la configuración
> viene para descomentar la monitorización del archivo de log "syslog"
> para que se reinicie la máquina en caso de que éste caiga.
>

Para poder instalar watchdog o cualquier otro programilla ahora mismo hay
que enmendar el problema de las librerías. He tratado de reinstalar perl a
mano pero parece que sigue dando el mismo fallo, seguiré con ello.


> Recuerdo que dijiste que todo el software adicional se instalaba en /opt
> o /usr/local... pero tiene toda la pinta de que alguien instaló perl5
> (creo recordar) en el directorio root.
>
> ¿Podéis comprobarlo? Cuando se instalan programas en paralelo que son
> usados por los gestores de paquetes para ejecutar scripts de instalación
> o configuración... ¡puf! es cuando te la juegas.
>

/usr/local es el directorio por defecto, sí, pero, por ejemplo, perl está
instalado en /root/perl5. Después de haber reinstalado perl he visto que
este es el directorio que él mismo escoge por defecto. Al menos, con la
instalación manual.


> Por cierto, ¿no habéis pensado en redundar la instalación?
>

Es decir, ¿tener varios servidores?


> Por otro lado, podríais meter ciertos servicios dentro de un contenedor
> virtual dentro de la misma máquina para limitar los recursos usados. Yo
> soy un usuario compulsivo de openvz.
>

¿Qué ventajas proporcionaría esto? ¿Sería realmente necesario?


> Creo que cuanto antes se tenga montado el servidor zabbix y se
> monitorice el comportamiento del servidor antes sabremos cuál es el
> origen del problema (cuando se repita) para arreglarlo.
>
> PD: Hablando de ataques, también recomendaría usar fail2ban para tener
> una mínima defensa contra ataques de fuerza bruta en el servidor ssh (y
> otros que se configuren) y tener watchlog enviando informes diarios de
> actividad del servidor.
>

Vuelvo a lo de antes, primero hay que eliminar el error de las dependencias
de libc, aunque es cierto que es algo que habría que hacer.


> Un saludo.
>

Un saludo,

Borja.

[1] - https://developers.google.com/speed/pagespeed/mod
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jderobot-admin/attachments/20121105/9bfb2a93/attachment.htm