Tilman Kastner wrote:
> after some configuration work, i finally managed to get mod_backhand up
> and running.
>
> Unfortunately, two problems still remain, and I have no idea how to
> investigate any further:
>
> The first one are occasionaly dying processes at the machine working as
> proxy. Currently, this
> machine handles approx. a few requests a second or less, so load should
> not be a problem. But in
> the apache error log looks like this:
>
> <snip>
> [Sat Feb 3 10:13:01 2001] [notice] child pid 15606 exit signal
> Segmentation fault (11)
> <snip>
> [Sat Feb 3 13:59:15 2001] [notice] child pid 18893 exit signal
> Segmentation fault (11)
> <snip>
>
> This segfaulting did not occur before i installed mod_backhand. It only
> happens at the server
> answering the requests from remote, those working as proxies on other
> machines are perfectly
> fine.
>
> I'm not an expert in debugging running applications, so any hint how to
> receive more information
> about the dying processes would be appreciated.
After some trouble shooting, this was resolved. It appeared to be something
awry in the configuration file. It wasn't found to be directly mod_backhand
related. A configuration change was made to the mod_log_spread set up and the
problem disappeared. I will forward the problem over the m_l_s maintainer.
> Second: It seems that mod_backhand gets sometimes confused about the
> clients' IP adresses.
>
> If I reload repeatedly the /backhand/ status handler, it sometimes
> (approx 10%) reports
> the wrong REMOTE_ADDR. Same happens to php-scripts echoing or processing
> the REMOTE_ADDR.
> These wrong addresses usually belong to clients who are at the same
> time making requests to the system. As we do things like content
> customisation on an clients IP address
> base, this is no good (Even the logging at the proxy-servers shows the
> wrong adresses, while the external
> server logs the right one)
BUG! Fixed :-) mod_backhand changes the remote address on the connection as
it comes in so that IP based authentication will still work right. Of course
it would "fudge" this data if the Backhanded request doesn't come from a
trusted server. So, it checks to make sure that the connection is from a
trusted server and then *changes* that data to reflect the actual client.
When keep alives are enabled, there can be more than one request on the same
connection. DOH! So, the second and all subsequent requests will reject the
attempt to set the remote address because it was set to the client (untrusted)
during the first request.
I have added a routine that triggers in the logging phase to set the
connection's remote IP back to what it was (the fellow server). If you care
about logging "correct" remote IP addresses on "backend" servers, then make
sure that your logging facilities (mod_log_config, mod_log_spread, etc.) come
before it in he AddModule directives. If they follow mod_backhand, the IP
address will be change back to the "fellow server" *before* the request is
logged -- probably not what you want. The default install should be correct.
This fix and a removeSelf candidacy function (which should need no
explanation) are in CVS and have been rolled into a 1.1.1pre3 prerelease. It
is available on the web site.
My laziness is slowly evaporating and 1.1.1 is slowly becoming a reality.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
> after some configuration work, i finally managed to get mod_backhand up
> and running.
>
> Unfortunately, two problems still remain, and I have no idea how to
> investigate any further:
>
> The first one are occasionaly dying processes at the machine working as
> proxy. Currently, this
> machine handles approx. a few requests a second or less, so load should
> not be a problem. But in
> the apache error log looks like this:
>
> <snip>
> [Sat Feb 3 10:13:01 2001] [notice] child pid 15606 exit signal
> Segmentation fault (11)
> <snip>
> [Sat Feb 3 13:59:15 2001] [notice] child pid 18893 exit signal
> Segmentation fault (11)
> <snip>
>
> This segfaulting did not occur before i installed mod_backhand. It only
> happens at the server
> answering the requests from remote, those working as proxies on other
> machines are perfectly
> fine.
>
> I'm not an expert in debugging running applications, so any hint how to
> receive more information
> about the dying processes would be appreciated.
After some trouble shooting, this was resolved. It appeared to be something
awry in the configuration file. It wasn't found to be directly mod_backhand
related. A configuration change was made to the mod_log_spread set up and the
problem disappeared. I will forward the problem over the m_l_s maintainer.
> Second: It seems that mod_backhand gets sometimes confused about the
> clients' IP adresses.
>
> If I reload repeatedly the /backhand/ status handler, it sometimes
> (approx 10%) reports
> the wrong REMOTE_ADDR. Same happens to php-scripts echoing or processing
> the REMOTE_ADDR.
> These wrong addresses usually belong to clients who are at the same
> time making requests to the system. As we do things like content
> customisation on an clients IP address
> base, this is no good (Even the logging at the proxy-servers shows the
> wrong adresses, while the external
> server logs the right one)
BUG! Fixed :-) mod_backhand changes the remote address on the connection as
it comes in so that IP based authentication will still work right. Of course
it would "fudge" this data if the Backhanded request doesn't come from a
trusted server. So, it checks to make sure that the connection is from a
trusted server and then *changes* that data to reflect the actual client.
When keep alives are enabled, there can be more than one request on the same
connection. DOH! So, the second and all subsequent requests will reject the
attempt to set the remote address because it was set to the client (untrusted)
during the first request.
I have added a routine that triggers in the logging phase to set the
connection's remote IP back to what it was (the fellow server). If you care
about logging "correct" remote IP addresses on "backend" servers, then make
sure that your logging facilities (mod_log_config, mod_log_spread, etc.) come
before it in he AddModule directives. If they follow mod_backhand, the IP
address will be change back to the "fellow server" *before* the request is
logged -- probably not what you want. The default install should be correct.
This fix and a removeSelf candidacy function (which should need no
explanation) are in CVS and have been rolled into a 1.1.1pre3 prerelease. It
is available on the web site.
My laziness is slowly evaporating and 1.1.1 is slowly becoming a reality.
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7