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
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?
Please try the updated httpd packages from here: http://people.redhat.com/jorton/Tikanga-httpd/
Did you confirm that the updated httpd packages fixed all the problems you were seeing?
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).
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.