El modo CGI de Apache permite a los webmasters reducir el uso de memoria. Es la forma preferida de ejecutar muchos sitios web de bajo tráfico.
Pero el modo CGI es bastante sensible a cosas como los permisos y la codificación de archivos, lo que conduce a un error interno de servidor de 500.
En nuestro papel de Ingenieros de soporte para hosts web, hemos visto una amplia gama de causas de este error.
Algunas causas comunes y sus soluciones son:
- Permisos de archivo o carpeta incorrectos: Los archivos de script y los directorios deben tener EXACTAMENTE 755 permisos. En algunos servidores, los directorios pueden necesitar 750 permisos.
- Propiedad incorrecta (usuario & problemas de grupo) – La propiedad del archivo debe establecerse en «USUARIO : ApacheUser» o «USUARIO : USUARIO» dependiendo de la configuración de Apache.
- Codificación incorrecta: Los archivos cargados en modo binario fallarán en la ejecución y deberían volver a cargarse como ASCII.
Casi el 80% de los problemas de error 500 se resolverían con estas correcciones.
Este artículo trata sobre el resto del 20% de las causas que son difíciles de encontrar y corregir.
Causas poco comunes para el error interno del servidor CGI de Apache
500 El error interno del servidor es la forma en que un servidor web dice: «Algo ha salido mal cuando intenté mostrar la página. No estoy seguro de qué.»
Si no se trata de problemas de permisos o propiedad, podría ser cualquier cosa, desde errores de aplicación & Configuraciones erróneas de Apache hasta bloques de firewall & errores del sistema de archivos.
Estos son los 10 principales problemas poco comunes que hemos visto en nuestro curso de trabajo.
Módulos faltantes
Las aplicaciones web dependen de una gran cantidad de «módulos» PHP o Perl para funciones específicas.
Algunos de estos módulos son parte de una configuración de servidor estándar, pero muchos no lo son.
Hemos visto que después de una migración o durante la configuración de un nuevo sitio web, los scripts a menudo fallan porque no están presentes todos los módulos necesarios.
El registro de errores dirá que no existen funciones» indefinidas «o» métodos».
Para solucionar esto, revisamos las especificaciones de requisitos de la aplicación e instalamos todos los módulos que faltan.
Tiempos de espera de red (de llamadas a la API, scripts remotos, etc.)
Algunas aplicaciones web obtienen datos de servidores remotos(p. ej. datos meteorológicos).
Si por alguna razón se interrumpe esta conexión con el servidor remoto, la aplicación web esperará un tiempo y luego mostrará un error de tiempo de espera.
Apache informa de este estado como un error 500.
Este problema puede ser difícil de solucionar, ya que es posible que no deje una entrada de registro.
Detectamos problemas de tiempo de espera inspeccionando las conexiones salientes pendientes durante mucho tiempo y lo solucionamos deshabilitando la función de la aplicación que requiere las conexiones salientes.
Rutas de programa antiguas (compilador)
La primera línea de cada aplicación CGI (llamada Shebang) contiene la ruta al programa que se supone que debe ejecutarla.
Por ejemplo. Los scripts de Perl tienen esta ruta:
#!/usr/bin/perl
Pero esta ruta puede diferir en función de los proveedores de sistemas operativos y la configuración de compilación personalizada.
Por lo tanto, el script buscará el archivo de programa en una ubicación en particular, y si no se encuentra allí, el script mostrará un error 500.
Dos métodos eficaces son:
- Utilice las rutas definidas en el entorno del servidor: las rutas de todos los programas se almacenan en la variable «entorno» del servidor. Por lo tanto, cambiamos la primera línea llamando al medio ambiente, así:
#!/usr/bin/env perl- Esto asegurará que no importa dónde esté configurado Perl, la ruta de acceso estará disponible para el script.
- Defina las rutas de acceso del programa en la configuración de Apache-Utilice las directivas «AddHandler» y «Action» de Apache para ejecutar todos los archivos con el programa correcto. Por ejemplo. he aquí cómo configurar PHP como CGI:
AddHandler application/x-httpd-php5 phpAction application/x-httpd-php5 /local-bin/php-cgi
Errores en el código de aplicación
Los propietarios de sitios web pueden cometer pequeños errores, como eliminar un»; » o insertar un carácter extraviado al editar archivos de configuración o de aplicación.
Esto resultará en que la aplicación no se ejecute, pero Apache solo escupirá el críptico mensaje de «Error Interno del servidor».
Detectamos estos problemas analizando los archivos de registro y los resolvemos corrigiendo el error de código o deshabilitando el complemento / complemento / tema que está causando el error.
Los archivos de configuración antiguos con rutas de módulo incorrectas
Los sitios web a menudo se personalizan para el entorno del servidor y las rutas de programa.
Cuando se migran sitios, sus archivos de configuración contendrán estas rutas antiguas que podrían no ser compatibles con el nuevo servidor.
Hemos visto casos en los que las aplicaciones web utilizan archivos de configuración personalizados (por ejemplo, php.ini) para cargar funciones de biblioteca. Esto fallará cuando la ruta de acceso cambie en un servidor nuevo.
En tales casos, eliminamos las rutas de programa codificadas y, en su lugar, usamos variables de entorno para adquirir automáticamente las ubicaciones del programa.
Restricciones de seguridad (firewall de aplicaciones web, SELinux, etc.)
La mayoría de los servidores en estos días tienen Firewalls de aplicaciones Web como mod_security o ComodoWAF.
Estos cortafuegos pueden causar un error 500 si interpreta una solicitud de página como un ataque.
Por ejemplo. hemos visto que las aplicaciones web fallan porque mod_security interpretó las llamadas a archivos externos como un ataque de Inclusión de archivos remotos.
En tales casos, creamos reglas de exclusión de firewall personalizadas para que la aplicación ya no se bloquee, mientras que la seguridad del servidor no se vea afectada.
Cambiar la configuración de SELinux de «Hacer cumplir» a «Permisivo» también nos ha ayudado a corregir este error.
Sin restricción de ejecución en la partición
Las aplicaciones CGI se ejecutan como programas.
Para eso necesita algo llamado privilegio «Ejecutar».
Este privilegio » Ejecutar «está desactivado para particiones de acceso público como» /tmp «y particiones de almacenamiento de datos como» /backup » para evitar la ejecución de malware.
Hemos visto casos en los que este bit de «Ejecución» está desactivado para hogares de sitios web, lo que provoca un error en la ejecución del script.
Restauramos exec por:
# mount -o remount,exec /home
Apache & .error de configuración de htaccess (sin ExecCGI, sin AllowOverride, etc.)
Apache necesita saber qué directorios contienen scripts CGI.
Que se denota usando la directiva «ExecCGI».
Por ejemplo. para denotar /cgi-bin/ como un directorio CGI, Apache debe configurarse con:
<Directory /path/to/cgi-bin>
Options +ExecCGI
</Directory>
En algunos servidores hemos visto» ExecCGI » desactivado en cgi-bin debido a una configuración incorrecta en el archivo de configuración de Apache o en an .htaccess en el directorio padre.
Del mismo modo, hemos visto directivas relacionadas con CGI en .htaccess se vuelve ineficaz porque .htaccess no estaba habilitado a través de una directiva «AllowOverride» en la configuración de Apache.
Todo esto puede resultar en una ejecución fallida del script y, en consecuencia, en un error 500.
Permisos incorrectos en el directorio home
Los directorios CGI generalmente se colocan dentro del directorio home. Por ejemplo. la ruta a un cgi-bin en servidores cPanel es:
/home/username/public_html/cgi-bin/
Muchos webmasters tienen cuidado de cambiar el permiso del directorio cgi-bin y de los directorios de aplicaciones web a 755, pero se olvidan de comprobar los permisos del directorio personal.
En algunas configuraciones de Apache (p. ej. cuando se usa SuExec), el directorio personal también debe tener permisos 755. Cualquier otra cosa que no sea eso (por ejemplo. 777), hará que la ejecución del script falle.
Por lo tanto, una de las primeras cosas que verificamos junto con los permisos de archivo de script es verificar los permisos de todos los directorios en la ruta del archivo.
Configuramos todo correctamente para asegurarnos de que el script se ejecute sin errores.
Errores relacionados con Chroot que rompen la ruta de acceso del archivo
En algunos servidores compartidos, la seguridad se refuerza confinando a cada usuario a un entorno encarcelado.
Esto evita que un usuario acceda a los archivos de cualquier otro usuario.
Pero tales entornos pueden romper enlaces de software a archivos de programa.
Por ejemplo. si los programas están almacenados en » / opt/php/ bin /» y está enlazado desde «/usr/bin/ php/», esas referencias pueden romperse.
Estos son casos bastante raros, y lo arreglamos reconfigurando el servidor (o sitio) para que use la ruta correcta en lugar de enlaces suaves.