[Jderobot-admin] Caída de zabbix_server este fin de semana

Mie Dic 5 10:37:32 CET 2012

El 04/12/2012 19:26, Borja Mon Serrano escribió:
> 4) Lo de squid es algo que habría que hacer, sí, independientemente de
> cómo sea la máquina, ya que parece que va a mejorar notablemente el
> rendimiento de la misma. En este apartado de "aplicaciones" que has ido
> comentando a lo largo de todo este tiempo también tengo pendiente
> instalar fail2ban como mecanismo de defensa.
> De todas formas, todo esto lo tendré que probar primero en un servidor a
> parte antes de pasarlo a jderobot.

Te adjunto un documento que creé hace un tiempo para instalar el 
acelerador web que usábamos en la intranet. Aquí estamos heredando una 
serie de problemas debido a que antes de entrar yo montaron todo en 
Windows y funcionaba a pedales.

Gracias al cielo conseguí ganar la batalla de quitar el servidor MySQL 
del servidor Windows y ahora estoy en medio de una batalla para 
conseguir poner el squid como frontal de dos servidores activo-activo. 
Actualmente usan el servicio de cluster de microsoft en activo-pasivo y 
éste no detecta las caídas de apache, por lo que requiere de los 
operadores para restaurar el servicio.

En los servidores de operación llevamos años con una configuración 
balanceada por squid, usando para compartir las sesiones memcache, pero 
aún se muestran reticentes a abandonar Windows como plataforma de servidor.

> 5) Con lo de "mantener el disco" me refería a que lo que se ha hecho ha
> sido coger el disco de la anterior máquina y meterlo en la nueva, tal
> cual. Por tanto, así de primeras yo no pensaba que se pudiera arreglar
> el problema de tu página de Working Progress... Creo que el problema
> está en la base de datos, supongo que eliminando solamente esa entrada
> bastaría, pero bueno, puedo probar a hacer lo que dices. Guardar todas
> las bases de datos lo tengo ya bastante claro pero, ¿cómo las cargo?
> Antes de usar esta nueva máquina había intentado hacer justo eso y no lo
> logré. No estoy muy ducho en este tipo de operaciones, pero por lo que
> leí se supone que bastaría con un "source basededatos.sql", aunque eso
> lo leí para cargar una sola base de datos, no todas.

No tengo acceso al servidor MySQL por lo que no puedo depurar qué está 
pasando. Lo ideal sería activar el logueo de consultas largas 
(log_slow_queries        = /var/log/mysql/mysql-slow.log) y consultar el 
PROCESSLIST para ver qué consulta está quedándose congelada.

Como te dije no hay que descartar que el problema venga del código PHP 
de la wiki o de otra fuente.

> 6) En los logs de apache2 no veo nada relativo a PHP. Lo que sí veo es
> este tipo de mensajes cada cierto tiempo:
> También veo otro tipo de mensajes:
> [Tue Dec 04 14:36:05 2012] [notice] child pid 12543 exit signal
> Segmentation fault (11)
> [Tue Dec 04 14:36:05 2012] [notice] child pid 12546 exit signal
> Segmentation fault (11)
> [Tue Dec 04 14:36:05 2012] [notice] child pid 12547 exit signal
> Segmentation fault (11)
> [Tue Dec 04 14:36:05 2012] [notice] child pid 12549 exit signal
> Segmentation fault (11)
> [Tue Dec 04 14:36:05 2012] [notice] child pid 12551 exit signal
> Segmentation fault (11)
> [Tue Dec 04 14:36:05 2012] [notice] child pid 12552 exit signal
> Segmentation fault (11)
> [Tue Dec 04 14:36:08 2012] [notice] child pid 12586 exit signal
> Segmentation fault (11)

Estos mensajes parecen provenir, según las horas, de las pruebas que 
hice con "ab", por lo que ya sabemos que la carga de la página maldita 
provoca un segmentation fault en los procesos apache que tratan de 
ejecutar la página PHP.

Estoy casi por proponerte que hagas un reinstall de todos los paquetes 
relacionados con apache y php.

Yo lo haría por partes.

Actualizamos repositorios: apt-get update

Primero, todo lo relacionado con PHP:

root en zabbix-cal:~# dpkg -l | grep "^ii  php" | cut -d " " -f 3
php5
php5-cli
php5-common
php5-gd
php5-mcrypt
php5-mysql
phpmyadmin (bueno, este último no sería necesario)
root en zabbix-cal:~# apt-get --reinstall install `dpkg -l | grep "^ii 
php" | cut -d " " -f 3`
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Los paquetes indicados a continuación se instalaron de forma automática 
y ya no son necesarios.
   libhtml-template-perl libdbd-mysql-perl libpq5
Utilice «apt-get autoremove» para eliminarlos.
0 actualizados, 0 se instalarán, 7 reinstalados, 0 para eliminar y 0 no 
actualizados.
Se necesita descargar 0 B/7982 kB de archivos.
Se utilizarán 0 B de espacio de disco adicional después de esta operación.
Preconfigurando paquetes ...
(Leyendo la base de datos ... 45819 ficheros o directorios instalados 
actualmente.)
Preparando para reemplazar php5 5.3.3-7+squeeze14 (usando 
.../php5_5.3.3-7+squeeze14_all.deb) ...
Desempaquetando el reemplazo de php5 ...
Preparando para reemplazar php5-cli 5.3.3-7+squeeze14 (usando 
.../php5-cli_5.3.3-7+squeeze14_amd64.deb) ...
Desempaquetando el reemplazo de php5-cli ...
Preparando para reemplazar php5-common 5.3.3-7+squeeze14 (usando 
.../php5-common_5.3.3-7+squeeze14_amd64.deb) ...
Desempaquetando el reemplazo de php5-common ...
Preparando para reemplazar php5-gd 5.3.3-7+squeeze14 (usando 
.../php5-gd_5.3.3-7+squeeze14_amd64.deb) ...
Desempaquetando el reemplazo de php5-gd ...
Preparando para reemplazar php5-mcrypt 5.3.3-7+squeeze14 (usando 
.../php5-mcrypt_5.3.3-7+squeeze14_amd64.deb) ...
Desempaquetando el reemplazo de php5-mcrypt ...
Preparando para reemplazar php5-mysql 5.3.3-7+squeeze14 (usando 
.../php5-mysql_5.3.3-7+squeeze14_amd64.deb) ...
Desempaquetando el reemplazo de php5-mysql ...
Preparando para reemplazar phpmyadmin 4:3.3.7-7 (usando 
.../phpmyadmin_4%3a3.3.7-7_all.deb) ...
Desempaquetando el reemplazo de phpmyadmin ...
Procesando disparadores para man-db ...
Procesando disparadores para libapache2-mod-php5 ...
Reloading web server config: apache2.
Configurando php5-common (5.3.3-7+squeeze14) ...
Configurando php5-gd (5.3.3-7+squeeze14) ...
Configurando php5-mcrypt (5.3.3-7+squeeze14) ...
Configurando php5-mysql (5.3.3-7+squeeze14) ...
Configurando phpmyadmin (4:3.3.7-7) ...
dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf
Replacing config file /etc/phpmyadmin/config-db.php with new version
dbconfig-common: flushing administrative password
Reloading web server config: apache2.
Configurando php5 (5.3.3-7+squeeze14) ...
Configurando php5-cli (5.3.3-7+squeeze14) ...

Luego las librerías de apache:
root en zabbix-cal:~# dpkg -l | grep -e "^ii  [^ ]*apache" | cut -d " " -f 3
apache2-mpm-prefork
apache2-utils
apache2.2-bin
apache2.2-common
libapache2-mod-php5
root en zabbix-cal:~# apt-get --reinstall install `dpkg -l | grep "^ii  [^ 
]*apache" | cut -d " " -f 3`
...

De esa manera nos quitamos de encima problemas de algún paquete que se 
haya quedado corrupto. Como hubo problemas de repositorios, 
dependencias, etc posiblemente se quedara algo "tonto". No viene mal 
volver a instalar para asegurarse (no se modificará ningún archivo de 
configuración, o no debería).

> De estos hay muchos más, pero no sé de dónde pueden provenir. Luego hay
> otros mensajes que creo que saltan al iniciar la máquina. Y digo que lo
> creo porque más o menos coincide con las ocasiones en las que se ha
> reiniciado (o iniciado de nuevo):
> Lo de python_init supongo que vendrá en algún sitio de la configuración
> de apache y se podrá cambiar. Lo de mod_python no sé ni tan siquiera
> ahora mismo para qué está instalado, porque por todo lo que he visto
> hasta este momento no hay nada del servidor desarrollado en python. Que
> me corrija José María si me equivoco.

Es un módulo de apache, se puede deshabilitar con a2dismod y probar si 
algo deja de funcionar. Algunas listas de distribución están hechas en 
python, no sé si podría ser eso...

> 7) Cierto es que con los kernels -pae se pueden manejar tamaños más
> grandes de memoria, no había caído en ello, no estoy habituado.

Yo tampoco, estuve varios meses trabajando con mi portátil nuevo con 
ubuntu 10.04 con sólo 2 GB de RAM por no haber instalado el núcleo pae 
xD se convierte en mala costumbre eso de trabajar siempre en 64bits.

> Así que en este punto hay dos alternativas posibles que he
> hablado con Roca, dos alternativas que se manejan mmás que nada porque
> lo que se quiere es cambiar el disco duro también y poner el que traía
> la nueva máquina (320GB SATA a 7200 rpm en lugar de 40GB (SO) + 40GB
> (chroot) + 80GB (svn), todo ello en IDE):
>
> 7a) Hacer con PartImage [1] imágenes de disco de los tres que hay y
> luego cargar la imagen en el nuevo disco, en particiones separadas. Con
> actualizar el kernel a un -pae valdría. El tiempo invertido en esto
> sería pequeño y se solucionaría el hecho de querer ampliar
> posteriormente la memoria RAM.

Clonar está bien, pero siempre deja basura (paquetes viejos olvidados 
que no sirven para nada, configuraciones enrevesadas y con parámetros 
obsoletos, etc).

> 7b) Particionar el disco e instalar Debian de 64 bits, replicando todo
> lo que hay en el servidor. Es decir, que habría que instalar de cero
> absolutamente todo.

No es completamente "empezar de cero".

Puedes recuperar los paquetes instalados siguiendo:
http://kvz.io/blog/2007/08/03/restore-packages-using-dselectupgrade/

Luego, los archivos de configuración siguen en /etc. Bastaría con 
copiar/pegar los que fueran necesarios restaurar.

> Está claro que lo rápido y (espero) fácil es lo primero, pero quizá
> convendría más lo segundo. ¿Merece la pena el esfuerzo a invertir en
> instalar de cero todo o sería "una pérdida de tiempo" teniendo en cuenta
> lo que se puede ganar?

Nosotros siempre hacemos pasos a producción (de nuevas versiones de 
sistema operativo) en máquinas nuevas o "limpias". Procuramos ser lo 
menos intrusivos posible configurando o recompilando cosas.

Una cosa que sí que deberíais plantearos es pasar todo a volúmenes lógicos.

Creando un grupo de volúmenes con todo el espacio y no usando todo el 
espacio en los volúmenes lógicos creados te permitirá más adelante hacer 
crecer aquél volumen que necesite espacio.

En nuestras plantillas de virtualización las máquinas debian 6 tienen 
tres gigas de espacio en el grupo de volúmenes sin usar para que luego 
con un simple lvextend se aumente el espacio de aquél sistema de 
archivos que se haya quedado corto para ese servicio en particular. 
Cuando se necesita más espacio simplemente se agrega un nuevo disco 
virtual al grupo de volúmenes, pero siempre se trabaja con ellos por la 
flexibilidad que te ofrece incluso para hacer backups en caliente 
(snapshots).

También se podría hacer un híbrido entre ambos, para mantener todo 
exactamente tal cual está pero pasando de usar particiones reales a 
volúmenes lógicos, todo ello en caliente y sin parada de servicio 
(exceptuando el último rsync antes de poner en producción la nueva máquina).

Pero es un proceso que hay que hacerlo poco a poco:
1.- Instalar la máquina debian 6 con los volúmenes como se desean.
2.- Arrancar un live en la máquina nueva para volcar los datos de la 
máquina en producción a la nueva sin preocuparse con que algún proceso 
modifique algo en el proceso.
3.- Montar por segunda vez los sistemas de archivos en modo sólo lectura 
en /mnt en la máquina en producción para hacer los rsync de cada 
directorio (/etc, /home, /usr, etc) sin miedo a equivocarte en el 
sentido del rsync y cargarte algo del servidor de producción, a parte de 
quitarte problemas de copiar directorios que realmente no existen o son 
virtuales (como /dev, /sys, /proc, etc).
4.- Hacer un rsync inicial de producción a la máquina nueva (puede 
tardar horas o días dependiendo de la cantidad de archivos y/o datos). 
Se pueden excluir ciertas rutas en esta primera sincronización ya que 
sólo es para probar su buen funcionamiento.
5.- Arrancar la nueva máquina en aislamiento (con el cable de red 
desconectado) para que no haya conflicto de IPs con la máquina de 
producción y probar que todos los servicios funcionan correctamente. 
Anotar cualquier modificación que se haya tenido que hacer para ponerla 
en marcha (borrar registros de udev, problemático cuando se usa 
networkmanager, por ejemplo). Se puede probar incluso a cambiar la IP.
6.- Volver a arrancar un live en la nueva máquina y sabiendo que todo 
funciona correctamente hacer un nuevo rsync para actualizar los archivos 
modificados.
7.- Parar servicios en la máquina de producción, arrancar una live y 
montar de nuevo en sólo lectura todo en /tmp como cuando estaba en 
producción y hacer el rsync definitivo a la nueva máquina usando 
--delete para borrar aquellos archivos que hayan sido eliminados 
(durante el segundo rsync sólo se agregaron archivos, no se borraron, 
ahora que están en frío se más seguro borrarlos, ahora es cuando se 
necesita haber montado en sólo lectura para asegurarse que no borras 
nada del servidor que estaba en producción).
8.- Intercambiar discos.
9.- Aplicar los cambios que se anotaron que fueron necesarios.
10.- Probar que todo funciona y, en caso de no hacerlo aplicar el plan 
de marcha atrás. En este caso es tan sencillo como volver a colocar el 
disco IDE.

> Un saludo y perdón por el tocho,

El mío también ha sido un buen tocho :)

------------ próxima parte ------------
1.- Instalación squid en c:\squid e instalación del servicio con squid -i
2.- Renombrar squid.conf y mime.conf
3.- Configurar squid (hacer backup del archivo de configuración):
http_port 172.25.2.69:80 accel act-as-origin
* Activa la configuración de squid para actuar como un acelerador web y toma el control de la IP externa de servicio.

cache_peer 127.0.0.1 parent 80 0 name=apache no-query login=PASSTHRU
* Configura el servidor web real (apache) como backend o destino fijo del proxy. Con esto impedimos, además, que se use el acelerador web como proxy (open proxy).

cache_mem 32 MB
* Permite almacenar en RAM hasta 32 megas de archivos (JPGs, PDFs, etc) para impedir que sea el servidor web el que realice el trabajo "duro" cuando se accede repetidas veces a un mismo archivo.

maximum_object_size_in_memory 1 MB
* Permite almacenar en RAM archivos de hasta 1 MB de tamaño (PDFs pequeños, prácticamente la totalidad de hojas de estilo, imágenes, etc están por debajo de este tamaño).

cache_dir aufs c:/squid/var/cache 50 16 256
* Configura una caché de 50 megas en disco

shutdown_lifetime 5 seconds
* Impide que el proxy tarde más de 5 segundos en apagarse (pq está sirviendo archivos grandes).

* No hay que modificar nada en los ACLs ya que por defecto están permitidos los rangos de redes LAN privadas (http_access allow localnet).

4.- Creación de directorios caché: squid -z
5.- Instalar los módulos mod_log_rotate y mod_rpaf en modules.
6.- Configurar apache (hacer backup del archivo de configuración):
Listen 127.0.0.1:80
* Evitamos que apache responda a las conexiones al puerto 80 de la IP de servicio, sólo lo haremos desde el propio equipo (desde squid).

LoadModule log_rotate_module modules/mod_log_rotate.so
RotateLogs On
CustomLog "N:/Apache/logs/access.%Y%m%d-%H%M%S.log" common
ErrorLog "N:/Apache/logs/error.%Y%m%d-%H%M%S.log"
* Activamos la rotación de logs de acceso y errores diaria y la ponemos por fecha y hora.

LoadModule rpaf_module modules/mod_rpaf.so
RPAFenable On
RPAFproxy_ips 127.0.0.1
RPAFheader X-Forwarded-For
* Activamos el módulo que intercambia la IP de 127.0.0.1 del acelerador web (squid) por la que entregue éste en la cabecera "X-Forwarded-For". Esto permite que tanto en los logs como en PHP aparezcan las IPs de los clientes y no la del acelerador web que es quien establece la conexión última.

7.- Parar servicio apache2.2 (para que libere la IP de servicio). Esperar a la parada completa y que en netstat no aparezca ninguna conexión al puerto 80.
8.- Arrancar servicio squid.
9.- Arrancar servicio apache2.2.
10.- Comprobar que funciona desde el exterior el acceso web.