Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <439D4B42.6010904@netspinner.co.uk>
Date: Mon, 12 Dec 2005 10:04:50 +0000
From: Stephen Collyer <scollyer@netspinner.co.uk>
Reply-To: scollyer@netspinner.co.uk
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: users@httpd.apache.org
References: <439AE92C.3030906@netspinner.co.uk>
	 <e498c1660512101017sa52e744re1db00575c9f16b0@mail.gmail.com>
	 <439B2214.7020409@netspinner.co.uk>
 <e498c1660512101200g6c2a5564u94ccc6f322758f27@mail.gmail.com>
In-Reply-To: <e498c1660512101200g6c2a5564u94ccc6f322758f27@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [users@httpd] Apache 1.3: Aliases no longer working

Joshua Slive wrote:
> On 12/10/05, Stephen Collyer <scollyer@netspinner.co.uk> wrote:
> 
> 
>>And the perms are fine - chmod'ed everything wide open earlier
>>on to be sure.
>>
>>There's a ScriptAlias set up pointing to a cgi-bin dir thats
>>working just fine, too. This strikes me as odd.
> 
> 
> You checked ALL PARENT DIRECTORIES?  Are you using selinux?  Are you
> using symlinks?  Have you tried to su to the User/Group specified in
> httpd.conf and see if you can access the files?

Yes, I've checked ALL PARENT DIRECTORIES.
No, I'm not using selinux.
No, I'm not using symlinks.
Yes, I can su to the appropriate user, and I can, indeed, access the
files that way.

> 
>>I'm much keener to get Apache to tell why it's returning a
>>403 rather than guessing - do you know if this is possible ?
> 
> 
> Sure; first you need to find the code in apache that is denying
> access, and then add an appropriate error log message to that code
> path.  Easy, huh?

I'm not familiar with the Apache code base, but I guess this
implies that there's no trace code in there ? Seems to be
something of an omission for a project as large as Apache, if so.

> An alternative is to run the request under a debugger and step through
> it until you see what is causing the problem.  See:
> http://httpd.apache.org/dev/debugging.html

Well, I'd already strace'd it, with no better results; all
I could see is that the appropriate file is stat'ed, and then
a little later on, the 403 being returned.

However: *** I have found the problem ***

The problem, of course, was caused by my being a dick.
I'd put in some temporary access control that I'd forgotten
about in an Include'd conf file.

Now, given that we're all dicks at some point or other,
this has taught me that Apache is too hard to debug.

It would be much more useful if it were possible to ask
Apache to provide a trace of a request, based on its current 
configuration, this trace containing all of the major decisions
that are made thoughout its life: access control, URL->dir
translations, usage of Aliases, and so on.

Now, I'd guess that such trace would be spread across many
components, written by many different people, so I won't be
holding my breath, but this would be far more useful than the
current suggestions in the debugging page of, say, strace or
gdb, both of which are really at the wrong level semantically.
(strace is telling you about syscalls, not config logic, and
gdb'ing Apache ain't for those who aren't already familiar
with the code, though it would give you the right answer with
enough effort, of course).

-- 
Regards

Stephen Collyer
Netspinner Ltd

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org