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
-~----------~----~----~----~------~----~------~--~---
