Hi Graham and thanks for the response again. I seem to remember when I originally built this 64-bit mod_python module I had a lot of difficulty. I was getting error messages which I solved by following the solution in this article:
http://agiletesting.blogspot.com/2007_10_01_archive.html Although I didn't fully understand what I was doing, the instructions fixed the issue I was having. I'm hoping that as a result this is a 64- bit issue which I can get around when I move to a 32-bit production server. I have never tried nor heard of mod_wsgi. Is this just a new replacement for mod_python which I can run Django and other python web apps through? Are there any changes I need to make to them if I implement this module? Many thanks Huw On Nov 8, 10:05 am, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > On Nov 7, 10:29 pm, huw_at1 <[EMAIL PROTECTED]> wrote: > > > > > Graham thanks, > > > First of all here is my httpd.conf file modules: > > > # Example: > > # LoadModule foo_module modules/mod_foo.so > > # > > > LoadModule python_module modules/mod_python.so > > #LoadModule dav_svn_module modules/mod_dav_svn.so > > #LoadModule authz_svn_module modules/mod_authz_svn.so > > > <IfModule !mpm_netware_module> > > <IfModule !mpm_winnt_module> > > # > > > So as you can see the only module I am actually using is the > > mod_python one. 'httpd -l' reveals: > > > core.c > > mod_authn_file.c > > mod_authn_default.c > > mod_authz_host.c > > mod_authz_groupfile.c > > mod_authz_user.c > > mod_authz_default.c > > mod_auth_basic.c > > mod_include.c > > mod_filter.c > > mod_log_config.c > > mod_env.c > > mod_setenvif.c > > prefork.c > > http_core.c > > mod_mime.c > > mod_status.c > > mod_autoindex.c > > mod_asis.c > > mod_cgi.c > > mod_negotiation.c > > mod_dir.c > > mod_actions.c > > mod_userdir.c > > mod_alias.c > > mod_so.c > > > Running ldd on mod_python reveals: > > > /usr/local/apache2/modules/mod_python.so: > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00002af216d13000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00002af216f2d000) > > libutil.so.1 => /lib64/libutil.so.1 (0x00002af217131000) > > libm.so.6 => /lib64/libm.so.6 (0x00002af217335000) > > libc.so.6 => /lib64/libc.so.6 (0x00002af2175b8000) > > /lib64/ld-linux-x86-64.so.2 (0x00000039a2c00000) > > The mod_python module isn't linking to shared Python library but has > linked it statically. This can cause problems, see below. > > > and on the python ldap module: > > > /usr/local/lib/python2.5/site-packages/python_ldap-2.3.5-py2.5-linux- > > x86_64.egg/_ldap.so > > libldap_r-2.3.so.0 => /usr/lib64/libldap_r-2.3.so.0 > > (0x00002aad1567e000) > > liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 > > (0x00002aad158c7000) > > libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002aad15ad5000) > > libssl.so.6 => /lib64/libssl.so.6 (0x00002aad15cef000) > > libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002aad15f38000) > > libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0 > > (0x00002aad16280000) > > The ldap module is link Python shared library. > > That mod_python.so has embedded static module and you can shared being > linked in here can cause crashes. > > Haven't seen this variation of problem before, but see: > > http://code.google.com/p/modwsgi/wiki/InstallationIssues > > This describes issues with use of static and shared library for Python > at same time when using mod_python and mod_wsgi together. > > In short, rebuild mod_python so it uses shared Python library instead. > > Maybe also consider using mod_wsgi as well. It will not solve the > problem, but arguable better solution these days. :-) > > Graham > > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aad165ef000) > > libc.so.6 => /lib64/libc.so.6 (0x00002aad16809000) > > libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aad16b5c000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00002aad16d72000) > > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aad16f76000) > > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > > (0x00002aad171ae000) > > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aad173dd000) > > libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aad17670000) > > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 > > (0x00002aad17872000) > > libz.so.1 => /usr/lib64/libz.so.1 (0x00002aad17a98000) > > libutil.so.1 => /lib64/libutil.so.1 (0x00002aad17cac000) > > libm.so.6 => /lib64/libm.so.6 (0x00002aad17eaf000) > > /lib64/ld-linux-x86-64.so.2 (0x00000039a2c00000) > > libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 > > (0x00002aad18133000) > > libkeyutils.so.1 => /lib64/libkeyutils.so.1 > > (0x00002aad1833b000) > > libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aad1853e000) > > libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aad18756000) > > > and: > > > /usr/lib64/libldap.so: > > liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 > > (0x00000039ad400000) > > libresolv.so.2 => /lib64/libresolv.so.2 (0x00000039ae800000) > > libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00000035dd200000) > > libssl.so.6 => /lib64/libssl.so.6 (0x0000003b69600000) > > libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00000039a3800000) > > libc.so.6 => /lib64/libc.so.6 (0x00000039a3e00000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00000039a4600000) > > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00000035daa00000) > > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > > (0x0000003b68a00000) > > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003b68e00000) > > libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00000039ad800000) > > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 > > (0x0000003b68600000) > > libz.so.1 => /usr/lib64/libz.so.1 (0x00000039a4e00000) > > /lib64/ld-linux-x86-64.so.2 (0x00000039a2c00000) > > libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 > > (0x0000003b69200000) > > libkeyutils.so.1 => /lib64/libkeyutils.so.1 > > (0x00000039af800000) > > libselinux.so.1 => /lib64/libselinux.so.1 (0x00000039a3400000) > > libsepol.so.1 => /lib64/libsepol.so.1 (0x00000039a3000000) > > > To me everything matches up. I have had a few other suggestions such > > as using strace. This however has so much detail in it is difficult to > > trace anything in a multi-thread/child environment. I have also had > > suggested mod_backtrace and mod_whatkilledus however these require > > recompiling my apache server which is something I am loathed to do as > > it is something I have never done before and am worried I will lose my > > setup if I do this. So I guess I am open to suggestions as I am trying > > to weigh up my options. > > > On Nov 6, 10:33 pm, Graham Dumpleton <[EMAIL PROTECTED]> > > wrote: > > > > On Nov 7, 2:38 am, huw_at1 <[EMAIL PROTECTED]> wrote: > > > > > Hi all. I am having some real problems with this. I have an LDAP > > > > authentication backend that I have hooked up to my app. Standalone it > > > > appears to run fine. However when running it through my apache server > > > > I am seeing alot of segmentation faults in my error log coupled with > > > > the redirection page not loading on succesful authentication. > > > > > I have googled around a bit and seen a few other threads with LDAP > > > > authentication and apache segementation faults. However none of them > > > > seem to be quite the same issue that I am experiencing. The only thing > > > > I have managed to garner thus far is that there may be a version > > > > mismatch betweem the openldap libraries used to compile apache with > > > > and those used to compile the python-ldap module. > > > > > If anyone has any ideas about this or, miraculously, has a solution I > > > > would be most grateful. > > > > The version mismatch on shared library versions is indeed usually what > > > the problem is. > > > > You need to run 'ldd' on all Apache modules, all PHP modules if using > > > PHP, and Python LDAP modules and work out which LDAP client libraries > > > they use. > > > > Normally Apache mod_auth_ldap would use self contained LDAP client > > > implementation and so it shouldn't be an issue unless symbols not > > > being namespaced, but may be possible (not sure) to tell it to use > > > distinct LDAP client library as well. > > > > See: > > > > http://code.google.com/p/modwsgi/wiki/ApplicationIssues#MySQL_Shared_... > > > > This is about MySQL, but same sort of issue. See how 'ldd' command is > > > used in that case to check library versions and do similar thing for > > > LDAP stuff. > > > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
