Apache: Índice Directorio prohibido por la directiva Opciones

Question

Estamos funcionando con 4 instalaciones de la red de Wordpress en un servidor Windows 2008 R2 VPS, con Apache 2.2.17 y PHP 5.3.10 y por alguna razón estamos regularmente conseguir esto (muestra) de error:

registro de errores

[Thu Feb 16 15:01:59 2012] [error] [client x.x.x.x] Directory index forbidden by Options directive: C:/_webserver/_www/wp/www/ 

registro de acceso

host x.x.x.x - - [17/Feb/2012:12:59:23 +0200] "GET/HTTP/1.1" 403 306 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.2; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; MATM)" 

El error "índice Directorio prohibido" por lo general significa que un directorio está tratando de ser visitada, pero no hay ningún archivo (según la directiva opciones) que se mostrará y el listado de directorio está prohibido. Sin embargo, este no es el caso aquí. El error se refiere a la carpeta C:/_webserver/_www/wp/www/, que es la raíz web para el proyecto, y siempre ha tenido un index.php. Además, httpd.conf está configurado con: DirectoryIndex index.html index.php

Al ver cómo se produce el error en Apache, creo que es muy poco probable que esto pueda ser causado por PHP o Wordpress.

Lo difícil es que no sabemos cómo reproducir el error, por lo que es difícil para poner a prueba esta.

¿Qué podemos hacer para descubrir cuál podría ser el problema? Puede tener algo que ver con la configuración de Apache (parece una pregunta redundante). ¿Puede tener algo que ver con el archivo que ya está siendo leído por Apache? ¿Hay alguna manera de que podamos obtener más información sobre este problema?

daría la bienvenida a cualquier ayuda para ayudar a resolver este caso desagradable.

ACTUALIZACIÓN

Estos son los módulos que tengo actualmente en uso

LoadModule deflate_module modules/mod_deflate.so 
LoadModule expires_module modules/mod_expires.so 
LoadModule headers_module modules/mod_headers.so 
LoadModule cache_module modules/mod_cache.so 

LoadModule rewrite_module modules/mod_rewrite.so 
LoadModule setenvif_module modules/mod_setenvif.so 
LoadModule vhost_alias_module modules/mod_vhost_alias.so 
LoadModule alias_module modules/mod_alias.so 
LoadModule authz_host_module modules/mod_authz_host.so 
LoadModule dir_module modules/mod_dir.so 
LoadModule log_config_module modules/mod_log_config.so 
LoadModule mime_module modules/mod_mime.so 
LoadModule php5_module "c:/_webserver/_server/php-5.3.10-Win32-VC9-x86/php5apache2_2.dll" 

opciones de directivas:

<Directory /> 
    Options FollowSymLinks ExecCGI 
    AllowOverride None 
    Order deny,allow 
    Allow from all 
</Directory> 

<Directory "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/cgi-bin"> 
    AllowOverride None 
    Options None 
    Order allow,deny 
    Allow from all 
</Directory> 

httpd-vhosts.conf se ve así:

NameVirtualHost *:80 

<VirtualHost *:80> 

    <Directory "C:/_webserver/_www/sites/www"> 

     Options FollowSymLinks 
     AllowOverride All 
     Order allow,deny 
     Allow from all 

    </Directory> 
    Include "C:/_webserver/_www/sites/htaccess.conf" 

    DocumentRoot "C:/_webserver/_www/sites/www" 
    ServerName xxx 
    ServerAlias xxx 
    CustomLog logs/sites.access.log mycombined 
    ErrorLog logs/sites.error.log 

</VirtualHost> 

Tengo 5 hosts virtuales configurados de esta manera, con cada uno su propio registro de acceso y error. Los proyectos no usan un .htaccess, pero esto está configurado estáticamente a través de la configuración para el rendimiento.

El servidor se ejecuta en Windows, por lo que el MPM puesta a punto es un poco limitado

# WinNT MPM 
# ThreadsPerChild: constant number of worker threads in the server process 
# MaxRequestsPerChild: maximum number of requests a server process serves 
<IfModule mpm_winnt_module> 
    ThreadsPerChild  1750 
    MaxRequestsPerChild 0 
</IfModule> 

actualización final

Bueno, decidí desactivar la caché de Apache por completo, y desde entonces, no tuvo más errores Desafortunadamente no he tenido demasiado tiempo esta semana para hacer las pruebas adecuadas, pero al menos sé dónde está el problema. Y con un servidor no muy ocupado, el almacenamiento en caché no está bien por ahora. Yo podría estar de vuelta en un tiempo :-)

Answer 1

Esto es ciertamente algo difíciles de depurar, errores ocasionales son los peores :-)

Mis primeros pensamientos fueron "conexiones internas Dumy" temas relacionados, pero que no le mostrarían una firma IE8-beta en el acceso .Iniciar sesión.

así que encontré tres enlaces que usted puede investigar:

• A serverFault intermittent 403 problem, related to mod_negotiation and SSI
• Another serverFault intermittent 403, related to MaxClients reached, y comprueba que no se llega a MaxClients cuando aparece ese error.
• A deep analysis of intermittent 403 related to mod_cache

Desde que creo que este tipo de problema es un poco como las interacciones entre medicamentos. Así que lo primero que hay que hacer es:

1. Verificar los módulos cargados en la configuración de Apache y quitar (comentario Líneas de carga) los que no es necesario en absoluto (y que tendrán un Apache más rápido si nunca lo hizo ¡antes de!).
2. Cree un entorno de prueba para los módulos que todavía está utilizando en producción (donde eliminarlo haría que la aplicación se bloquee). Tendrá que ser capaz de reproducir el error con wget o ab o cualquier otra herramienta masiva de solicitudes HTTP.
3. intente con los módulos inactivos, uno por uno, hasta que desaparezca el problema.

Los módulos que por lo general hacen comportamientos extraños son:

• mod_negotiation (con la relacionada Option Multiviews). Apache está tratando de servir archivos alternativos, después de una negociación con los encabezados de los navegadores. Eso puede romper tus RewriteRules o interactuar mal con otros módulos. Eso generalmente conduce a algunas respuestas desatentas a consultas mal formadas, siempre elimino ese módulo.
• mod_include: El lado del servidor incluye (con el relacionado option Includes), también conocido como SSI. ¿Quién realmente necesita eso?
• mod_cache & mod_disk_cache, en realidad, eso es una muy antigua cosas de la escuela, es mejor que tratar de usar barniz o cualquier otro cachés de proxy inverso
• mod_rewrite: la navaja suiza, pero ¿estás seguro no lo hiciste ¿Escribiste una Regla muy extraña en alguna parte?
• mod_dir: comprobar que no tiene DirectorySlash Off, que pueden interactuar mal con algún otro módulo haciendo cosas extrañas
• mod_isapi: leer the doc que puede dar lugar a algunas pistas. Para mí tengo la sensación de que este es un soporte experimental, con mucha carga, estoy bastante seguro de que podrían suceder cosas extrañas.
• mod_proxy: quitarlo si no es necesario que

ACTUALIZACIÓN: (después de los detalles de configuración) La lectura de su configuración vi varios pequeños errores (no relacionadas):

• <Directory /> No creo que esto funcione en Windows, ya que su raíz es c: not /. Pero tal vez estoy equivocado. Al menos no necesita un allow from all aquí, bastante inseguro.
• Si no utiliza archivos .htaccess, configure AllowOverride None en todas partes, especialmente en un <Directory "C:">, para evitar buscar estos archivos desde el directorio raíz.

Ahora para su problema. No veo ninguna opción relacionada con mod_cache en su configuración (pero tal vez tenga algunos archivos incluidos en subdirectorios de configuración de Apache que usan directivas mod_cache. Si no usa ninguno de los mod_cache directives puede suspender ese módulo sin ningún riesgo.

Answer 2

Si es intermitente, que es justo suponer que alguien está intermitentemente eliminar y reemplazar index.php.

Re comentarios - esto no requiere 'sabotaje'. Si simplemente vuelve a implementar algún estilo de aplicaciones con un servidor web en ejecución, o restaura una copia de seguridad, hay una ventana de tiempo en que Apache podría ver un directorio pero no un archivo.