You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "@lbutlr" <kr...@kreme.com> on 2020/04/30 22:08:43 UTC
[users@httpd] Debugging apache configs
I'm trying to troubleshoot a Domain that is loading the wrong content (Well, I am sure it is loading the RIGHT content, but not the INTENED content) and was wondering if there is a flag for apachectl that will show me what apache thinks the document root is for each vhost? And possibly a way of piping in a URL and having apache spit back where that URL points to locally and the steps taken to get there (redirect, proxy, lookup, whatever).
A trace, essentially.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Debugging apache configs
Posted by "@lbutlr" <kr...@kreme.com>.
On 01 May 2020, at 16:19, Rich Bowen <rb...@rcbowen.com> wrote:
(Tried to fix the quote levels, apologies if I missed something)
>> The login in apache is… well, terrible? Appalling? Almost entirely a waste of disk space?
>
> You can configure it to whatever level suits you. That's your choice.
Changing the level doesn’t actually improve the logging though, just changes how much or little is logged.
>> I mean, 86%% of my error log (yes, I checked and did the calculation) is ever so helpful lines like this:
>>
>> [Fri May 01 15:53:14.704934 2020] [ssl:info] [pid 17522] [client 65.121.55.45:46411] AH01964: Connection to child 1 established (server www.covisp.net:443)
>>
>> Really? That’s an ERROR? In what universe is that an error? And how they hell is it even HELPFUL since it is entirely a stand-alone line devoid of any context whatsoever?
> No. It's an info. Says right there in the message.
It is logged to httpd-error.log
>> [Fri May 01 15:26:31.491833 2020] [ssl:info] [pid 17508] AH01914: Configuring server www.covisp.net:443 for SSL protocol
>>
>> Yep, that is an error I need to be aware of. Sure.
> Also an info
Also logged to httpd-error.log
> I'm completely unclear what the purpose of this comment is. If you're asking what the error message means I can probably help you with that, but it kind of sounds like you're picking a fight here. Did you have an actual question?
Not picking a fight, just frustrated by the very bad user-hostile logging. I suppose it’s great for log analysis tools, but not so great for humans.
--
I WILL NOT PLEDGE ALLEGIANCE TO BART Bart chalkboard Ep. 7F09
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Debugging apache configs
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, May 1, 2020, 18:11 @lbutlr <kr...@kreme.com> wrote:
> On 01 May 2020, at 15:38, Rich Bowen <rb...@rcbowen.com> wrote:
> > On the other hand, adding a bunch of additional debug level prints in
> the URL mapping modules would serve the same purpose. But, again, that
> doesn't exist at this time, as far as I'm aware.
>
> The login in apache is… well, terrible? Appalling? Almost entirely a waste
> of disk space?
You can configure it to whatever level suits you. That's your choice.
>
> I mean, 86%% of my error log (yes, I checked and did the calculation) is
> ever so helpful lines like this:
>
> [Fri May 01 15:53:14.704934 2020] [ssl:info] [pid 17522] [client
> 65.121.55.45:46411] AH01964: Connection to child 1 established (server
> www.covisp.net:443)
>
> Really? That’s an ERROR? In what universe is that an error? And how they
> hell is it even HELPFUL since it is entirely a stand-alone line devoid of
> any context whatsoever?
>
No. It's an info. Says right there in the message.
> [Fri May 01 15:26:31.491833 2020] [ssl:info] [pid 17508] AH01914:
> Configuring server www.covisp.net:443 for SSL protocol
>
> Yep, that is an error I need to be aware of. Sure.
>
Also an info
> And the access logs are no better.
>
> [Fri May 01 05:43:27.032221 2020] [cgid:error] [pid 95842] [client
> 150.136.214.147:54436] AH01264: script not found or unable to stat:
> /usr/local/www/apache24/cgi-bin/luci
>
> Is that a configuration error, or some idiot trying to hack something
> that’s not there?
I'm completely unclear what the purpose of this comment is. If you're
asking what the error message means I can probably help you with that, but
it kind of sounds like you're picking a fight here. Did you have an actual
question?
>
>
Re: [users@httpd] Debugging apache configs
Posted by "@lbutlr" <kr...@kreme.com>.
On 01 May 2020, at 15:38, Rich Bowen <rb...@rcbowen.com> wrote:
> On the other hand, adding a bunch of additional debug level prints in the URL mapping modules would serve the same purpose. But, again, that doesn't exist at this time, as far as I'm aware.
The login in apache is… well, terrible? Appalling? Almost entirely a waste of disk space?
I mean, 86%% of my error log (yes, I checked and did the calculation) is ever so helpful lines like this:
[Fri May 01 15:53:14.704934 2020] [ssl:info] [pid 17522] [client 65.121.55.45:46411] AH01964: Connection to child 1 established (server www.covisp.net:443)
Really? That’s an ERROR? In what universe is that an error? And how they hell is it even HELPFUL since it is entirely a stand-alone line devoid of any context whatsoever?
[Fri May 01 15:26:31.491833 2020] [ssl:info] [pid 17508] AH01914: Configuring server www.covisp.net:443 for SSL protocol
Yep, that is an error I need to be aware of. Sure.
And the access logs are no better.
[Fri May 01 05:43:27.032221 2020] [cgid:error] [pid 95842] [client 150.136.214.147:54436] AH01264: script not found or unable to stat: /usr/local/www/apache24/cgi-bin/luci
Is that a configuration error, or some idiot trying to hack something that’s not there?
grmbl.
Sorry for my rant, but it’s your own fault for mentioning logs, even if obliquely! 😉
--
And there were all the stars, looking remarkably like powered
diamonds spilled on black velvet, the stars that lured and
ultimately called the boldest towards them…
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Debugging apache configs
Posted by Rich Bowen <rb...@rcbowen.com>.
On Fri, May 1, 2020, 17:21 @lbutlr <kr...@kreme.com> wrote:
> On 01 May 2020, at 08:52, Rich Bowen <rb...@rcbowen.com> wrote:
> > On 4/30/20 6:08 PM, @lbutlr wrote:
> >> I'm trying to troubleshoot a Domain that is loading the wrong content
> (Well, I am sure it is loading the RIGHT content, but not the INTENED
> content) and was wondering if there is a flag for apachectl that will show
> me what apache thinks the document root is for each vhost? And possibly a
> way of piping in a URL and having apache spit back where that URL points to
> locally and the steps taken to get there (redirect, proxy, lookup,
> whatever).
> >> A trace, essentially.
> >
> >
> > Not directly, but
> >
> > httpd -t -D DUMP_VHOSTS
> >
> > is a good start. It at least tells you what names are handled by what
> bits of the configuration file(s).
>
> Yeah, but it dodoesn’t show the path that apache takes to load a page,
> which is what I am looking for.
>
> For example, the issue that I had turned out to be that since
> DirectoryIndex globally contains index.php, the fcgi was triggering even
> when there was no index.php file present instead of loading the index.html.
> Either setting DirectoryIndex locally or disabling the fcgi resulted in the
> expected page loading.
>
> That wasn’t discoverable by looking at the configuration until I thought,
> “Huh, I wonder…”
>
> Seems there would be some tool out there that would do this as it must be
> someone else has thought of for troubleshooting,
>
While that would be incredibly cool, I'm not aware of any such tool.
On the other hand, adding a bunch of additional debug level prints in the
URL mapping modules would serve the same purpose. But, again, that doesn't
exist at this time, as far as I'm aware.
>
Re: [users@httpd] Debugging apache configs
Posted by "@lbutlr" <kr...@kreme.com>.
On 01 May 2020, at 08:52, Rich Bowen <rb...@rcbowen.com> wrote:
> On 4/30/20 6:08 PM, @lbutlr wrote:
>> I'm trying to troubleshoot a Domain that is loading the wrong content (Well, I am sure it is loading the RIGHT content, but not the INTENED content) and was wondering if there is a flag for apachectl that will show me what apache thinks the document root is for each vhost? And possibly a way of piping in a URL and having apache spit back where that URL points to locally and the steps taken to get there (redirect, proxy, lookup, whatever).
>> A trace, essentially.
>
>
> Not directly, but
>
> httpd -t -D DUMP_VHOSTS
>
> is a good start. It at least tells you what names are handled by what bits of the configuration file(s).
Yeah, but it dodoesn’t show the path that apache takes to load a page, which is what I am looking for.
For example, the issue that I had turned out to be that since DirectoryIndex globally contains index.php, the fcgi was triggering even when there was no index.php file present instead of loading the index.html. Either setting DirectoryIndex locally or disabling the fcgi resulted in the expected page loading.
That wasn’t discoverable by looking at the configuration until I thought, “Huh, I wonder…”
Seems there would be some tool out there that would do this as it must be someone else has thought of for troubleshooting,
--
I gotta straighten my face This mellow-thighed chick just put my
spine out of place
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Debugging apache configs
Posted by Rich Bowen <rb...@rcbowen.com>.
On 4/30/20 6:08 PM, @lbutlr wrote:
> I'm trying to troubleshoot a Domain that is loading the wrong content (Well, I am sure it is loading the RIGHT content, but not the INTENED content) and was wondering if there is a flag for apachectl that will show me what apache thinks the document root is for each vhost? And possibly a way of piping in a URL and having apache spit back where that URL points to locally and the steps taken to get there (redirect, proxy, lookup, whatever).
>
> A trace, essentially.
Not directly, but
httpd -t -D DUMP_VHOSTS
is a good start. It at least tells you what names are handled by what
bits of the configuration file(s).
--
Rich Bowen - rbowen@rcbowen.com
http://rcbowen.com/
@rbowen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Debugging apache configs
Posted by "@lbutlr" <kr...@kreme.com>.
On 30 Apr 2020, at 16:08, @lbutlr <kr...@kreme.com> wrote:
> A trace, essentially.
What I am thinking is something along the lines of:
Apache received http://w.example.com/
Redirected https://w.example.com/
DocumentRoot /usr/local/www/example/web/
Loading DocumentIndex index.php
fcgi redirect /usr/local/www/example/otherweb/index.php
--
You are twisted and sick; I like that in a person.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org