On Nov 10, 8:53 pm, 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.
Solve the static vs shared library issue for mod_python first and then
we can see.
> 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?
No changes required to Django user application code. Just how you
configure Apache and how you need to use a WSGI script file as bridge
to Django application is different.
The mod_wsgi module isn't a replacement for mod_python as mod_wsgi
only supports Python web application supporting WSGI interface, as
nearly all do these days. The mod_python module provides its own
framework for developing web applications as well.
Graham
> 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
-~----------~----~----~----~------~----~------~--~---
