Error Interno del Servidor al instalar en Joomla! componentes, modulos, templates o plugins

Modificado por última vez en Miércoles, 08 Julio 2015 13:01
(0 votos)

Internal Server Error

Internal Server Error | ModSecurity: Input filter: Failed to delete temporary file

Hacía tiempo que no necesitaba instalar por FTP ningún nuevo componente en mis sistios Joomla! (las actualizaciones se descargan directamente desde los sitios de los desarrolladores), pero hoy que estoy realizando una nueva página web para un cliente y necesitaba instalar una nueva plantilla me ha saltado el Internal Server Error al tratar de subirla por FTP desde el instalador de Joomla!

Por cierto, y al margen de esta solución, a ver si los gurús del equipo de desarrollo de Joomla! eliminan del archivo .htaccess prederminado las líneas:

## Can be commented out if causes errors, see notes above.
Options +FollowSymlinks
Options -Indexes

Que al renombrar el htaccess.txt a .htaccess y poner en la configuración de Joomla! las URLs amigables también salta el Internal Server Error (al menos con la configuración del mio) y hay que comentarlas:

# Options +FollowSymlinks
# Options -Indexes

Volviendo al tema del artículo, al mirar los logs del servidor me encuentro con líneas de error como esta:

[Tue Jul 07 22:52:10 2015] [error] [client 79.145.180.136] ModSecurity: Input filter: Failed to delete temporary file: /var/lib/mod_security/20150707-225210-VZw7@i5pe3gAAATOaIkAAAAR-request_body-28wPmA [hostname "wave-ola.es"] [uri "/losgallos/administrator/index.php"] [unique_id "VZw7@i5pe3gAAATOaIkAAAAR";]

El error viene claramente producido por el ModSecurity de Apache y buscando en Google parece que la solución está en comprobar los ajustes ModSecurity, en particular la instrucción SecUploadDir.

Normativa de soporte de carga de archivos en ModSecurity

ModSecurity es capaz de interceptar los archivos cargados a través de peticiones POST y codificación multipart/form-data o (a partir de la versión 1.9) a través de peticiones PUT.

Dado que sólo hay un lugar en el que se puede establecer ese valor en PHP, y que ha sido verificado en tiempo de ejecución, además de que sabemos que ModSecurity va desde la salida del registro, parece que este problema es debido a ello.

Observa las directrices OP: Si no se establece el parámetro SecUploadDir, ModSecurity no lo ignora.

Así que hice las siguientes modificaciones añadiendo al archivo de configuracion de ModSecurity [ /etc/httpd/conf.d/mod_security.conf ] las siguiente líneas inmediatamente antes de </IfModule>:

SecUploadDir /tmp
SecTmpDir /tmp

Quedando el final como sigue:

SecTmpDir /var/lib/mod_security
SecDataDir /var/lib/mod_security
SecUploadDir /tmp
SecTmpDir /tmp
</IfModule>

y ahora funciona perfectamente (lo he comprobado en otro sitio web).

Otra cosa que me encontré que se puede tratar en una situación como ésta sería desactivar ModSecurity por completo para ver si eso elimina el problema. A continuación, se puede reducir el problema de ModSecurity rápidamente:

http://serverfault.com/questions/57210/disable-modsecurity-for-a-specific-directory Desactivando ModSecurity para un dirrectorio específico.

Otra solución que he visto en Intertet es añadir o descomentar la siguiente línea en el archivo php.ini:

upload_tmp_dir = /tmp

o, en algunos casos:

upload_tmp_dir = ./tmp/

Y, por supuesto, después de cualquiera de las modicicaciones reiniciar Apache:

service httpd restart

 


Comentarios (0)

No hay comentarios escritos aquí

Deja tus comentarios

  1. Publicar comentario como invitado. Regístrate o ingresaa tu cuenta
Archivos adjuntos (0 / 3)
Compartir su ubicación
close

Recibe gratis nuestros nuevos artículos!

Serás el primero en conocer las novedades y noticias que pasan en Internet, nuestros tutoriales, trucos y más.

Escribe tu email:

Se abrirá una nueva ventana deFeedBurner a la izquierda de la página y habrás de validar un Captcha.

Lee nuestras Política de privacidad & Política de cookies
Puedes darte de baja de la lista de correo electrónico en cualquier momento