Cómo saber que está fallando con mi servidor usando Strace y Puppet para automatizar la solución
Leer en chino sin ayuda puede ser más fácil
El servidor te da un error 500
Eso es de lo más genérico que puede haber, la causa puede ir desde un cambio en la versión de algún módulo hasta un typo en un archivo, de manera que resolverlo requiere herramientas más sofísticadas. Ahí entra en juego Strace.
Strace
Lo puedes obtener aquí:
Lo que hace strace es dar más información acerca de los procesos del sistema.
Entonces debemos saber cuales procesos están corriendo en el sistema (parece ovbio) pero muchas veces uno no sabe ni por donde empezar.
Para instalarlo usa:
$ sudo apt-get install -y strace
Antes de usarlo debemos saber que queremos inspeccionar, para esto, vamos a la terminal del servidor y usamos este comando para conocer los procesos que están corriendo:
$ ps -aux
Con esto obtenemos los PID (Process ID)
También es bueno revisar los permisos de las carpetas y otras fallas comunes, pero eso lo dejaré para otro día. Verificaré el árbol de procesos porque ajá.
$ pstree
Verificamos el funcionamiento del Mysql
$ strace -c mysql
Hacemos lo mismo con el apache (cuyo archivo está en la carpeta apache2)
$ strace -c apache2
Aparecen variables sin configurar…
Ahora revisemos en detalle los procesos, el proceso principal de apache
$ strace -p 2161
Ahora los procesos derivados
$ strace -p 2165
Desde otro terminal hacemos una petición al localhosts AKA (127.0.0.1)
$ curl -sI http://127.0.0.1
En este texto empiezan a aparecer cosas extrañas, por ejemplo unas salidas ENOENT (No such file or directory)
¿Pero como lee uno este tipo de salidas?
Vemos que hay un patrón
Acción = lstat
Parametros (entre paréntesis)
Resultado = -1 ENOENT (en este caso)
En el parámetro vemos que hay una referencia a un archivo, que además tiene un typo en el nombre, la extensión .phpp no es común.
Si verificamos en el sistema de archivos la versión class-wp-locale.php existe y la versión con .phpp no, de manera que ahí podríamos tener una causa.
Si revisamos los tipos MIME probablemente no encontremos nada
Como dato curioso por allá en 2012 se trato de implementar un tipo de archivo con ese nombre, lo pueden consultar aquí: https://wiki.php.net/rfc/phpp
En el caso de hoy podemos concluir que se trata de un error.
¿Pero y dónde está el error?
¿Cómo encuentro esa llamada mál hecha al archivo?
Probaremos lo más sencillo usar grep sobre el sistema de archivos, en particular la carpeta html que es donde están los archivos que “sirve” el servidor web.
$ grep -r class-wp-locale.phpp html
Efectivamente aparece una línea en el archivo wp-settings.php (Eureka!)
Probemos que al arreglar la línea el servidor funcione correctamente.
Perfecto, tenemos el 200 OK en la respuesta a la petición CURL.
Pero aún falta automatizar!
Ahora vamos a Puppet
Ejecutemos un reemplazo simple de la línea comprometida con sed.
sed -i \’s/class-wp-locale.phpp/class-wp-locale.php/g\’ /var/www/html/wp-settings.php
Aquí un tutorial de uso de sed:
https://www.cyberciti.biz/faq/how-to-use-sed-to-find-and-replace-text-in-files-in-linux-unix-shell/
El reemplazo funciona, ahora metamoslo en un archivo Puppet.
Usamos el comando sed y en el parámetro command y definimos la carpeta bin para el lugar de ejecución.
$ exec{ ‘puppeter’:
command => ‘sed -i \’s/class-wp-locale.phpp/class-wp-locale.php/g\’ /var/www/html/wp-settings.php’,
path => ‘/usr/local/bin/:/bin/’,
}
Tadaaaaa! así se convierte un 500 en un 200.
Funciona. Veremos que dice el “checker”.
