Apache: indice di directory vietato dalla direttiva Opzioni

Question

Stiamo eseguendo 4 installazioni di rete Wordpress su un VPS di Windows Server 2008 R2, con Apache 2.2.17 e PHP 5.3.10 e per qualche motivo siamo regolarmente ottenendo questo (esempio) errore:

Protocollo errori

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

Access log

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)" 

L'errore "Indice directory vietato" di solito significa che una directory sta tentando di accedere, ma non c'è alcun file (in base alla direttiva opzioni) da visualizzare e l'elenco delle directory è vietato. Questo però non è il caso qui. L'errore si riferisce alla cartella C:/_webserver/_www/wp/www/, che è il webroot per il progetto e ha sempre avuto un index.php. Inoltre, httpd.conf è impostato con: DirectoryIndex index.html index.php

Visto come l'errore si verifica in Apache, penso sia altamente improbabile che ciò possa essere causato da PHP o da Wordpress.

La cosa difficile è che non sappiamo come riprodurre l'errore, quindi è difficile per noi verificarlo.

Cosa possiamo fare per scoprire quale potrebbe essere il problema? Può avere qualcosa a che fare con l'installazione di Apache (sembra una domanda ridondante). Può avere qualcosa a che fare con il file già letto da Apache? C'è un modo per ottenere maggiori informazioni su questo problema?

Sarei felice di ricevere aiuto per risolvere questo pessimo caso.

UPDATE

Questi sono i moduli che ho attualmente in 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" 

Opzioni direttive:

<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 assomiglia a questo:

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> 

Ho 5 configurazioni di host virtuali come questa, con ogni loro errore e registro di accesso. I progetti non utilizzano uno .htaccess, ma questo è impostato staticamente tramite il conf per le prestazioni.

Il server gira su Windows, in modo che il set-up MPM è un po 'limitato

# 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> 

aggiornamento finale

Bene, ho deciso di spegnere Apache caching completamente, e da allora, non ha avuto più errori. Purtroppo non ho avuto troppo tempo questa settimana per fare test adeguati, ma almeno so dove si trova il problema. E con un server non molto occupato, nessun caching è ok per ora. Potrei essere di ritorno :-)

Answer 1

Questo è certamente qualcosa di difficile da mettere a punto, i bug occasionali sono quelli peggiori :-)

miei primi pensieri erano "connessioni dumy interne" le questioni relative, ma che non avrebbero mostrato una firma IE8 beta nell'accesso log.

così ho trovato tre link che si può indagare:

• A serverFault intermittent 403 problem, related to mod_negotiation and SSI
• Another serverFault intermittent 403, related to MaxClients reached, controllare che non si raggiunge MaxClients quando appare tale errore.
• A deep analysis of intermittent 403 related to mod_cache

Da quel Penso che questo tipo di problema è un po 'come interazioni farmacologiche. Quindi la prima cosa da fare è:

1. Controllare i moduli caricati nella configurazione di apache e rimuovere (linee di commento Load) quelli che non ti servono a tutti (e si avrà un Apache più veloce se non hai mai fatto prima!).
2. Creare un ambiente di test, per i moduli che si stanno ancora utilizzando in produzione (dove rimuoverlo renderebbe l'applicazione in crash). Dovrai essere in grado di riprodurre il bug con wget o ab o qualsiasi altro strumento di richieste HTTP.
3. provare a moduli inattivi, uno per uno, finché il problema non scompare.

moduli che di solito fanno i comportamenti strani sono:

• mod_negotiation (con il relativo Option Multiviews). Apache sta quindi cercando di servire file alternativi, dopo una negoziazione con le intestazioni dei browser. Questo potrebbe infrangere il tuo RewriteRules o interagire male con altri moduli. Questo di solito porta a risposte non programmate a query non corrette, rimuovo sempre quel modulo.
• mod_include: lato server include (con relativo option Includes), noto anche come SSI. Chi ne ha davvero bisogno?
• mod_cache & mod_disk_cache, in realtà, questo è un vecchio cose di scuola, è meglio provare a utilizzare vernice o qualsiasi altre cache proxy inverso
• mod_rewrite: il coltellino svizzero, ma sei sicuro che didn ha scritto una Regola molto strana da qualche parte?
• mod_dir: controllare non si dispone di DirectorySlash Off, che possono interagire male con qualche altro modulo fare cose strane
• mod_isapi: lettura the doc può condurvi ad alcuni suggerimenti. Per me ho la sensazione che questo sia un supporto sperimentale, su carichi pesanti sono abbastanza sicuro che potrebbero accadere cose strane.
• mod_proxy: rimuoverlo se non ne hai bisogno

UPDATE: (dopo dettagli di configurazione) Leggendo la configurazione ho visto diversi piccoli errori (non correlati):

• <Directory /> Non penso che funzionerà su Windows, dato che la tua radice è c: not /. Ma forse ho torto. Almeno non hai bisogno di un allow from all qui, abbastanza non sicuro.
• Se non si utilizzano i file .htaccess, impostare AllowOverride None ovunque, in particolare in un <Directory "C:">, per evitare la ricerca di questi file dalla directory principale.

Ora per il vostro problema. Non vedo alcuna opzione correlata a mod_cache nella tua configurazione (ma forse hai alcuni file inclusi nelle sottodirectory di configurazione di apache che usano le direttive mod_cache .Se non usi nessuno dei mod_cache directives puoi sospendere quel modulo senza alcun rischio

Answer 2

Se è intermittente, è giusto indovinare che qualcuno sta eliminando e sostituendo in modo intermittente index.php.

Re commenti - questo non richiede "sabotaggio". Se si ridistribuisce semplicemente uno stile di applicazioni con un server Web in esecuzione o si ripristina un backup, esiste una finestra temporale in cui Apache potrebbe visualizzare una directory ma nessun file.