An update on this.
'which python' returns:
libpython2.5.so.1.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000039a4a00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000039a4600000)
libutil.so.1 => /lib64/libutil.so.1 (0x00000039b3400000)
libm.so.6 => /lib64/libm.so.6 (0x00000039a4200000)
libc.so.6 => /lib64/libc.so.6 (0x00000039a3e00000)
/lib64/ld-linux-x86-64.so.2 (0x00000039a2c00000)
This explains why I cannot compile mod_python without first setting
the LD_LIBRARY_PATH to '/usr/local/lib'. I don't know if this is the
reason why the mod_python compilation continuously compiles with the
python library as static. I upgraded my apache to the latest version
however I still am getting segmentation faults on user authentication.
Which potentially suggests that the problem is not apache and is
something else like this issue.
On Nov 11, 10:54 am, huw_at1 <[EMAIL PROTECTED]> wrote:
> I'm having difficulty getting the mod_python.so to link dynamically.
> I'm trying to compile the python interpreter with the "--enable-
> shared" and compiling mod_python with the "--with-python" flags.
> However the "ldd" always shows the mod_python.so as not dynamically
> linking to the python libraries.
>
> On Nov 11, 12:44 am, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
