Some more info. Apache also segfaults when I succesfully sign in to the admin site.
On Nov 10, 9:53 am, huw_at1 <[EMAIL PROTECTED]> wrote: > 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 myapacheserver 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 myapacheserver > > > > > I am seeing alot ofsegmentationfaults 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 andapachesegementation 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 compileapachewith > > > > > 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 allApachemodules, all PHP modules if using > > > > PHP, and Python LDAP modules and work out which LDAP client libraries > > > > they use. > > > > > NormallyApachemod_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 -~----------~----~----~----~------~----~------~--~---
