A veces, el sitio web de Magento utiliza conexiones a recursos externos, que se inician desde el lado del servidor. Esto puede deberse al uso de fopen, curl, sockets, xmlrpc, etc. Esta extensión SMTP de Magento es un claro ejemplo del uso de estas conexiones externas. En cualquier caso, la falta de disponibilidad o la disponibilidad parcial de recursos externos podría provocar un comportamiento inesperado del sitio web.
Por ejemplo, si el servidor de licencias está sobrecargado o no está disponible, la extensión de verificación de licencias puede terminar con un error. En el mejor de los casos, esto conduciría a un retraso en la ejecución, en el peor de los casos (si el código de extensión no maneja correctamente los errores de red), esto podría conducir a un comportamiento impredecible o varios errores que son difíciles de conectar con la razón genuina.
Si su sitio web dejó de funcionar repentinamente, probablemente deba verificar el caso relacionado con la falta de disponibilidad de recursos externos.
como introducción
Para nuestro ejemplo, usamos la extensión Magento que intenta conectar los servidores de Gmail en lugar de usar la función «mail()» para enviar correos electrónicos. Dado que las conexiones al puerto 25/tcp están prohibidas para el servidor web, dicho comportamiento genera demoras o errores en el procesamiento de solicitudes.
Aunque el ejemplo está tomado sólo de la cabeza, sirve para ilustrar las técnicas recomendadas. Las técnicas descritas utilizan opciones de sistema privilegiadas y, en consecuencia, requieren permisos de superusuario. En caso de que no tenga permisos de superusuario, es muy poco probable que pueda utilizar los ejemplos descritos.
Tome el control total sobre la configuración SMTP de Magento , aplique configuraciones predefinidas para proveedores de servicios de correo electrónico y pruebe sus correos electrónicos usando el modo de depuración.
Conexiones iniciando sesión en cortafuegos
Una de las formas de entender que su servidor intenta conectar recursos externos es registrar dichas acciones en el firewall. Para activar el registro de todas las conexiones externas, es necesario agregar la siguiente regla al final de la cadena de SALIDA:
# iptables -A SALIDA -m estado –estado NUEVO -j REGISTRO
Si hay una nueva conexión, el registro tendría los siguientes registros en syslog (generalmente /var/log/messages o /var/log/syslog ):
1 de agosto 15:54:46 p53m kernel: [1125878.818034] IN= OUT=venet0 SRC=192.168.100.10 DST=192.168.100.1 LEN=60 TOS =0x00 PREC=0x00 TTL=64 ID=48656 DF PROTO=UDP SPT=37348 DPT=53 LEN=40
1 de agosto 15:54:46 kernel p53m: [1125878.818502] IN= OUT=venet0 SRC=192.168.100.10 DST=74.125.136.109 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=30704 DF PROTO=TCP SPT=36355 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
El primer registro en el registro muestra la solicitud al servidor DNS (dirección 192.168.100.1, puerto 53/udp), el segundo registro muestra la solicitud al servidor SMTP (dirección 74.125.136.109, puerto 25/tcp).
Si su servidor tiene muchos servicios que establecen conexiones salientes, puede limitar la lista. Esto se puede hacer, si se conoce el UID del usuario, bajo el cual se inicia el intérprete de PHP. Como de costumbre, sería Apache (UID: 99), www-data (UID: 33) o propietario de archivos (el UID se puede aprender con el comando id -u nombre de usuario). En caso de que su servidor tenga Debian o Ubuntu, la regla requerida será la siguiente:
# iptables -A OUTPUT -m propietario –uid-propietario 33 -m estado –estado NUEVO -j LOG
Seguimiento del proceso del intérprete
Se puede recibir más información sobre los cambios que ocurren durante el rendimiento de la solicitud rastreando el proceso del intérprete de PHP. Para rastrear la utilidad se utiliza strace. En caso de que no esté instalado en su servidor, puede instalarlo a través del administrador de paquetes o compilarlo usted mismo.
$ wget ‘http://sourceforge.net/projects/strace/files/strace/4.8/strace-4.8.tar.xz/download’ -O strace-4.8.tar.xz
$ tar -xf strace-4.8.tar.xz
$ cd strace-4.8/
$ ./configurar
$ hacer
$ ./strace -V
Ahora, para realizar el seguimiento, agregue la instrucción sleep (60) al comienzo del archivo raíz index.php;
<?php
dormir (60);
Esto haría que el intérprete retrasara la ejecución en 60 segundos, lo cual es suficiente para que usted encuentre el proceso requerido y le adjunte seguimiento. Para adjuntar al intérprete, es necesario conocer el PID (ID del proceso). Uno puede aprenderlo consultando mod_status http://your-site-name/server-status) o estudiando la lista de procesos. Si conoce el PID (que sea 12345 por ejemplo), puede adjuntarlo al proceso.
$ strace -o /tmp/strace.log -fF -e red -s 8192 -p 12345
Una vez finalizada la solicitud, detenga la ejecución de strace presionando CTRL+C y verifique el archivo de registro /tmp/strace.log. En este registro, verá la lista de las llamadas al sistema realizadas por el intérprete durante la ejecución de la solicitud. El parámetro «–e» representa la elección de la clase de llamada (en el ejemplo, solo se registran las llamadas relacionadas con las operaciones de la red). Si desea ver todas las llamadas, excluya el siguiente parámetro.
12345 enchufe (PF_INET, SOCK_STREAM, IPPROTO_TCP) = 36
12345 enchufe (PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 38
12345 connect(38, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(“192.168.100.1”)}, 16) = 0
12345 enviar a (38, «5362114smtp5gmail3com11», 32, MSG_NOSIGNAL , NULO, 0) = 32
12345 recvfrom(38, “53622012001344smtp5gmail3com11300f 0513253216gmail-smtp-msa1l6google30027300,11 3254J}210l300,113254J}210m300=211R /63ns1300=300=211R/63ns3300=300=211R /63ns2300=300=211R/63ns4300=”, 1024, 0, {sa_family=AF_INET, sin_port=htons( 53), sin_addr=inet_addr(“192.168.100.1”)}, [16]) = 174
12345 connect(36, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr(“74.125.136.108”)}, 16) = -1 ECONNREFUSED (Conexión rechazada)
12345 shutdown(34, 1 /* enviar */)
En este ejemplo se ve la solicitud de DNS al servidor y luego el intento de conexión al host 74.125.136.108 con el puerto 25/tcp, que terminó con un error (ECONNREFUSED).
Independientemente del método que utilice en la depuración, no olvide comprobar los registros de errores. Por lo general, los registros del servidor web son: /var/log/httpd/error_log en RHEL/CentOS y /var/log/apache2/error_log en Debian/Ubuntu .