All geek questions in one place

Apache: directory index disabled by option "Options"

We run 4 network installations of Wordpress on Windows Server 2008 R2 VPS with Apache 2.2.17 and PHP 5.3.10, and for some reason we regularly get this (approximate) error:

Error log

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

Access log

 host xxxx - - [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)"

The “Directory Blocking” error usually means that the directory is trying to access, but there is no file (according to the options directive) that will be displayed, and the list of directories is denied. However, it is not. The error refers to the C:/_webserver/_www/wp/www/ folder, which is webroot for the project, and always had index.php . In addition, httpd.conf configured using: DirectoryIndex index.html index.php

When I see how an error occurs in Apache, I find it unlikely that this could be caused by PHP or Wordpress.

The tough thing is that we don’t know how to reproduce the error, so it’s hard for us to verify this.

What can we do to find out what the problem is? Could this have anything to do with setting up Apache (this seems like an extra question). Could this have anything to do with the file already being read by Apache? Is there a way to get more information about this issue?

I would welcome any help to help me resolve this unpleasant case.

UPDATE

These are the modules that I am currently using.

 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"

Options directives:

 <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 is as follows:

 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>

I have 5 virtual hosts configured this way, with each of their own errors and access logs. Projects do not use .htaccess , but it is statically set via conf for performance.

The server runs on windows, so MPM configuration is a bit limited.

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

Final update

Well, I decided to completely disable Apache caching, and since then there have been no more errors. Unfortunately, this week I did not have too much time to conduct proper testing, but at least I know where the problem is. And with a server not so busy, there is no caching yet. I could come back after a while :-)

+6
source share
2 answers

This, of course, is difficult to debug, random errors are the worst :-)

My first thoughts were related to “internal haze problems,” but that wouldn't show you the IE8 beta signature in access.log.

So, I found three links that you can explore:

From this, I think that this problem is a bit like interacting with drugs. So the first thing to do:

  • Check the modules loaded into your apache configuration and delete (comment on the boot lines) those that you don't need at all (and you will have faster Apache if you haven’t done this before!).
  • Create a test environment for the modules you are still using in production (where removing them will crash your application). You will need to reproduce the error using wget or ab or any other massive HTTP request tool.
  • try inactive modules, one by one, until the problem goes away.

Modules that usually cause strange behavior:

  • mod_negotiation (with corresponding Option Multiviews ). Apache then tries to serve alternate files after discussing with browser headers. This can break RewriteRules or interact poorly with other modules. This usually leads to some unsatisfied responses to garbled requests, I always delete this module.
  • mod_include : the server side includes (with related option Includes ), also known as SSI. Who really needs this?
  • mod_cache and mod_disk_cache are really very old school things, you better try using Varnish or any other reverse proxy caches.
  • mod_rewrite : a swiss knife, but are you sure you didn't write a very strange rule somewhere?
  • mod_dir : make sure you don’t have DirectorySlash Off that might interact poorly with any other module that does strange things.
  • mod_isapi : reading a document may lead to some hints. For me, I have the feeling that this is experimental support, with a heavy load, I am quite sure that strange things can happen.
  • mod_proxy : delete it if you do not need it.

UPDATE: (after configuration details) While reading your configuration, I saw a few small errors (not related):

  • <Directory /> I do not think this will work on Windows, since your root is c: not /. But maybe I'm wrong. At the very least, you do not need allow from all , which is completely unsafe.
  • If you do not use .htaccess files, set AllowOverride None everywhere, especially in <Directory "C:"> , to avoid searching for abstract files from the root directory.

Now for your problem. I don’t see any option related to mod_cache in your configuration (but maybe you have some included files in apache configuration subdirectories that use mod_cache directives. If you don’t use any of mod_cache , you can pause this module without any risk.

+4
source

If it is intermittent, it is fair to assume that someone periodically removes and replaces index.php.

Re comments - this does not require "sabotage." If you simply relocate some application style with a working web server or restore a backup, a window of time will appear when Apache can see this directory, but not the file.

0
source

Source: https://habr.com/ru/post/895138/

More articles:


All Articles