Bug 474230

Summary:	mod_proxy breaks existing applications with RHEL-5.3beta update.
Product:	Red Hat Enterprise Linux 5	Reporter:	Stephen John Smoogen <smooge>
Component:	httpd	Assignee:	Joe Orton <jorton>
Status:	CLOSED NEXTRELEASE	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	high	Docs Contact:
Priority:	low
Version:	5.3	CC:	apenney, mdehaan, me
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-01-13 17:07:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Stephen John Smoogen 2008-12-02 21:19:08 UTC

Description of problem:

updated httpd's mod_proxy breaks cobbler utility. 

from the email list it turns out that the updated httpd breaks expected functionality that was worked in RHEL-5 before (and probably works the same in newer versions of upstream Fedora.) I have included Micheal from RH to help explain better what he is seeing.

--------
What we've found out is that if Apache connects to itself within
mod_python via a mod_proxy URL, bad things happen.

So if you change

127.0.0.1/cobbler_api (Apache proxied XMLRPC endpoint) to just

127.0.0.1:25151 (python directly)

everything works great.

Rather than hard code the port, I'm going to make it read the settings
file to get the port number, but basically that's the workaround.

I suspect this /is/ a bug in mod_python and/or mod_proxy though I'm not
sure the extent of it's seriousness and am ultimately ok with the
workaround.

--Michael

Comment 1 Michael DeHaan 2008-12-02 21:22:03 UTC

I was going to ask first if this should be expected to work, but since the bug is filed, here's the rest of my details sent to Joe Orton (who Koji says is the package owner)

(BEGIN EMAIL)


A cobbler user found a /potential/ problem in mod_python RHEL 5.3 that I wanted to ask about.
Scenario...

A xmlrpclib-using mod_python handler (services.py) tries to connect back through Apache on a mod_proxied url like:

xmlrpclib.Server("http://127.0.0.1:80/cobbler_api, allow_none=True)

which is configured as

ProxyRequests off
ProxyPass /cobbler_api http://localhost:25151/
ProxyPassReverse /cobbler_api http://localhost:25151/

This seems to work fine on 5.2, but on 5.3 produces:

  1. Core was generated by `/usr/sbin/httpd'.
  2. Program terminated with signal 11, Segmentation fault.
  3. [New process 10332]
  4. #0  0x00d2b717 in ap_update_child_status (sbh=0x0, status=3,
     r=0x0) at /usr/src/debug/httpd-2.2.3/server/scoreboard.c:448
  5. 448        return
     ap_update_child_status_from_indexes(sbh->child_num, sbh->thread_num,
  6. (gdb) where
  7. #0  0x00d2b717 in ap_update_child_status (sbh=0x0, status=3,
     r=0x0) at /usr/src/debug/httpd-2.2.3/server/scoreboard.c:448
  8. #1  0x00d331ef in core_create_conn (ptrans=0x90c3030,
     server=0x8fe23f0, csd=0x90c3068, id=0, sbh=0x0, alloc=0x90c9048)
     at /usr/src/debug/httpd-2.2.3/server/core.c:3907
  9. #2  0x00d427a3 in ap_run_create_connection (p=0x90c3030,
     server=0x8fe23f0, csd=0x90c3068, conn_id=0, sbh=0x0,
     alloc=0x90c9048) at /usr/src/debug/httpd-2.2.3/server/connection.c:40
 10. #3  0x00603a9f in ap_proxy_connection_create
     (proxy_function=0xfac628 "HTTP", conn=0x90c1060, c=0x9148c60,
     s=0x8fe23f0) at
     /usr/src/debug/httpd-2.2.3/modules/proxy/proxy_util.c:2415
 11. #4  0x00faabef in proxy_http_handler (r=0x9154af8,
     worker=0x90385b8, conf=0x9038190, url=0x91492a8 "/",
     proxyname=0x0, proxyport=0) at
     /usr/src/debug/httpd-2.2.3/modules/proxy/mod_proxy_http.c:1982
 12. #5  0x005fe660 in proxy_run_scheme_handler (r=0x9154af8,
     worker=0x90385b8, conf=0x9038190, url=0x9155d8e
     "http://localhost:25151/", proxyhost=0x0, proxyport=0)
 13.     at /usr/src/debug/httpd-2.2.3/modules/proxy/mod_proxy.c:2345
 14. #6  0x006028d3 in proxy_handler (r=0x9154af8) at
     /usr/src/debug/httpd-2.2.3/modules/proxy/mod_proxy.c:969
 15. #7  0x00d3a97d in ap_run_handler (r=0x9154af8) at
     /usr/src/debug/httpd-2.2.3/server/config.c:157
 16. #8  0x00d3e328 in ap_invoke_handler (r=0x9154af8) at
     /usr/src/debug/httpd-2.2.3/server/config.c:371
 17. #9  0x00d4a43e in ap_process_request (r=0x9154af8) at
     /usr/src/debug/httpd-2.2.3/modules/http/http_request.c:258
 18. #10 0x00d471df in ap_process_http_connection (c=0x9148c60) at
     /usr/src/debug/httpd-2.2.3/modules/http/http_core.c:184
 19. #11 0x00d4284d in ap_run_process_connection (c=0x9148c60) at
     /usr/src/debug/httpd-2.2.3/server/connection.c:43
 20. #12 0x00d4294c in ap_process_connection (c=0x9148c60,
     csd=0x9148ac8) at /usr/src/debug/httpd-2.2.3/server/connection.c:178
 21. #13 0x00d4edb2 in child_main (child_num_arg=<value optimized out>)
     at /usr/src/debug/httpd-2.2.3/server/mpm/prefork/prefork.c:640
 22. #14 0x00d4f0c1 in make_child (s=0x8fe23f0, slot=1) at
     /usr/src/debug/httpd-2.2.3/server/mpm/prefork/prefork.c:736
 23. #15 0x00d4f19a in startup_children (number_to_start=7) at
     /usr/src/debug/httpd-2.2.3/server/mpm/prefork/prefork.c:754
 24. #16 0x00d4fcfb in ap_mpm_run (_pconf=0x8fe0550, plog=0x900e608,
     s=0x8fe23f0) at
     /usr/src/debug/httpd-2.2.3/server/mpm/prefork/prefork.c:975
 25. #17 0x00d26147 in main (argc=150857160, argv=0x0) at
     /usr/src/debug/httpd-2.2.3/server/main.c:717


I'll admit there is no reason for Apache to proxy through itself though it used to work.

Thoughts?

Comment 2 Joe Orton 2008-12-03 08:33:51 UTC

Please try the updated httpd packages from here:

http://people.redhat.com/jorton/Tikanga-httpd/

Comment 3 Joe Orton 2009-01-13 16:25:27 UTC

Did you confirm that the updated httpd packages fixed all the problems you were seeing?

Comment 4 Michael DeHaan 2009-01-13 16:30:51 UTC

Sorry, I did not.

I fixed this by not having the mod_python stuff proxy through Apache.

So rather than having the mod_python component connect through 127.0.0.1:/cobbler_api_rw I just have it do 127.0.0.1:25151 (or whatever port number).

Comment 5 Joe Orton 2009-01-13 17:07:19 UTC

OK, no worries.  Since the backport looks identical to the known-and-fixed bug in the 5.3 beta packages, I'm going to close this out as presumed fixed.