[csw-users] PHP - Solaris LDAP libraries vs. OpenLDAP libraries

Thu Feb 17 21:31:35 CET 2005

I don't mind at all.  I was contemplating bringing this to the attention of
the PHP developers, but I believe the problem, if there is one, is in the
OpenLDAP libraries, which don't seem to be compatible with Solaris when you
are using native LDAP client as your name switching service.

As an FYI, my web applications don't even use LDAP for authentication.
Simply linking PHP using --with-ldap=/opt/csw/ at compile time will cause it
to link to the OpenLDAP libraries, and when Apache tries to load the PHP
module, it causes a segfault.

I was also able to reproduce this using both the stock Apache that ships
with Solaris (adding PHP using apxs of course), or the Blastwave Apache with
their compiled version of mod_php.

Also, you can easily tell which version of LDAP is linked against by either
using ldd or creating a phpinfo.php page with this in it: 

<?php
echo phpinfo();
?>

That will tell you what the configure string was, so you can see what
libraries it's linked against.

Good luck.  My recommendation:  LDAP is not ready for primetime, especially
with Solaris.  I've ran into so many bugs that I feel like I'm beta testing
Sun's client for them.  Did you know that ldapaddent doesn't even work if
you are using SSL?  This bug was fixed in Solaris 10, and they've given me a
T-patch for Solaris 9, but come on folks...  We are at rev. 39 of the 108993
patch (which is a monster patch, btw), and somehow Sun's QA folks never
noticed that if you're using SSL to encrypt client/server LDAP communication
tools like ldapaddent and ldapsearch break.  

-----Original Message-----
From: users-bounces at lists.blastwave.org
[mailto:users-bounces at lists.blastwave.org] On Behalf Of Neal A. Lucier
Sent: Thursday, February 17, 2005 1:05 PM
To: questions and discussions
Subject: Re: [csw-users] PHP - Solaris LDAP libraries vs. OpenLDAP libraries

Do you mind if I repost this on the comp.unix.solaris newsgroup?

I currently have an apache/php/openldap/openssl (not blastwave) server 
on a machine that is an NIS client but in the very near future will be 
an LDAP client to a JS Directory Server.  The php/ldap code currently 
works fine to connect to said JS Directory Server, but now you have me 
very frightened.

Thanks,
Neal A. Lucier
nlucier at math.purdue.edu

Luke Youngblood wrote:
> Thanks for the quick response.  Yes, actually there is something else you
> need to do in order to reproduce the segfault.  You have to have an LDAP
> server and do an "ldapclient init" so that your Solaris box is using LDAP
> for it's nsswitch service.  For example, nsswitch.conf would have:
> 
> hosts:  files ldap
> ...
> 
> This isn't very easy to setup unless you have a Java System Directory
Server
> or other LDAP server on your network.
> 
> Apparently, mod_php is causing the segfault when it tries to do a
> getservbyname on mysql or something similar, which goes through the nss.
> Also, here is the response I got from Sun support.  Maybe it will help you
> in troubleshooting:
> 
> Review of the core file via dbx clearly shows the "php" module being
> loaded which results in an illegal instruction.
> Understand, we at Sun are not responsible for "php" or their instruction
> set.
> 
> detected a multithreaded program
> program terminated by signal ILL (illegal opcode)
> 0x000c54b0: unimp 0x38
> (/usr/dist/share/forte_dev,v6.2/SUNWspro/WS6U2/bin/sparcv9/dbx) where
> current thread: t at 1
> 
> 
>>From the stack we see in threads 23 to 19 the "php" module being
> loaded` followed by a bunch of instruction sets the module is involking.
> The occurance of the illegal instruction was ldapssl_init where we
> called 0xc5d00 "192.168.250.217".
> 
> =>[1] 0xc54b0(0xd6578, 0x27c, 0x7, 0xfdc6e000, 0x73, 0x73), at 0xc54af
> [2] ldapssl_init(0xc5d00, 0x27c, 0x1, 0x0, 0x0, 0x342e3400), at
> 0xfdbb279c
> [3] openConnection(0x1, 0x0, 0xae5d0, 0xa, 0xc538c, 0x1), at 0xfdd1238c
> [4] makeConnection(0x1, 0xc5d00, 0xae5d0, 0xfdd224e4, 0xfdd224e0,
> 0xc538c), at 0xfdd1199c
> [5] __s_api_getConnection(0x1, 0xc6a70, 0x0, 0xc6a90, 0xc6a60, 0x1),
> at 0xfdd13438
> [6] get_current_session(0xc5340, 0xfdd0a440, 0xc5430, 0x5,
> 0xfdd0a440, 0xff00), at 0xfdd09848
> [7] search_state_machine(0x5, 0x0, 0xfdd20000, 0x1, 0xd, 0xe), at
> 0xfdd0a5ec
> [8] __ns_ldap_list(0xc5340, 0xc5c88, 0xc538c, 0x3, 0x0, 0x0), at
> 0xfdd0b0f0
> [9] _nss_ldap_lookup(0xc5f90, 0xffbff510, 0xfdd4eed0, 0xffbff338,
> 0x0, 0xfdd3b234), at 0xfdd3aa64
> [10] getbyname(0xc5f90, 0xffbff510, 0x30, 0xc5f28, 0xfdd63c30, 0x0),
> at 0xfdd3a084
> [11] nss_search(0x2, 0xfdd39fa8, 0xc52e8, 0xffbff510, 0x0,
> 0xff23f01c), at 0xff1ce6a4
> [12] _switch_getservbyname_r(0xfe9cc540, 0xfe9cc918, 0xc4e7c,
> 0xc4e8c, 0x400, 0x75647000), at 0xff2b90d4
> [13] _get_hostserv_inetnetdir_byname(0xc5298, 0xffbff644, 0xffbff63c,
> 0xff39a000, 0x0, 0x0), at 0xff29aa8c
> [14] getservbyname_r(0xfe9cc540, 0xfe9cc918, 0xc4e7c, 0xc4e8c, 0x400,
> 0xc4e30), at 0xff385928
> [15] OnMySQLPort(0xfea1de74, 0x0, 0x3, 0x0, 0x0, 0x0), at 0xfe8dba9c
> [16] zend_register_ini_entries(0xfea0cae0, 0x8, 0x0, 0x0, 0x0, 0x0),
> at 0xfe9b5b24
> [17] zm_startup_mysql(0x1, 0x8, 0xfe8dbb2c, 0x0, 0x0, 0x0), at 0xfe8dbb58
> [18] zend_startup_module(0xfea0c948, 0x0, 0x0, 0x0, 0x0, 0x0), at
> 0xfe9adf4c
> [19] php_startup_extensions(0xfea190d8, 0xfea190f4, 0x0, 0x0, 0x0,
> 0x0), at 0xfe97ada4
> [20] php_startup_internal_extensions(0x0, 0x2800, 0xfe9ddf60, 0x2,
> 0x3, 0x0), at 0xfe9c8610
> [21] php_module_startup(0xfea139c8, 0xfea139ac, 0x1, 0x0, 0x1, 0x0),
> at 0xfe97b38c
> [22] php_apache_startup(0xfea18d54, 0x1, 0xfea19f84, 0xfe97b400, 0x0,
> 0x1d3f0), at 0xfe9c6220
> [23] php_init_handler(0x7aa28, 0x7a9f0, 0x2, 0x7ea20, 0x6ff38, 0x0),
> at 0xfe9c72f0
> [24] ap_init_modules(0x7a9f0, 0x7aa28, 0x71f2c, 0x71f42, 0x5c653,
> 0x0), at 0x1e1fcy
> [25] main(0x1, 0xffbffc14, 0xffbffc1c, 0x6fc00, 0x0, 0x0), at 0x28dbc
> 
> The question is what is the php_module module doing? Unfortunately,
> Sun is not not the designer of the third party modules and we know very
> little regarding what the php_module module doing. Recommendation is to
> contact those responsible for "PHP" .
> 
> -----Original Message-----
> From: users-bounces at lists.blastwave.org
> [mailto:users-bounces at lists.blastwave.org] On Behalf Of Mark Round
> Sent: Thursday, February 17, 2005 4:47 AM
> To: questions and discussions
> Subject: Re: [csw-users] PHP - Solaris LDAP libraries vs. OpenLDAP
libraries
> 
> Hi,
> 
> I'll certainly look into it - as long as the package works on Solaris
> 8 through 9, with no extra effort required on the user's behalf, it
> should be OK. However, I'm a little confused about the segfaulting
> issue - would you mind clarifying it for me ?
> 
> I'm running a test box here, Solaris 10 / Sparc. I've got the Sun
> provided ldap libraries :
> 
> # pkgchk -l -p /usr/lib/libldap.so.5
> 
> Pathname: /usr/lib/libldap.so.5
> Type: regular file
> Expected mode: 0755
> Expected owner: root
> Expected group: bin
> Expected file size (bytes): 365728
> Expected sum(1) of contents: 65246
> Expected last modification: Jan 23 01:41:59 2005
> Referenced by the following packages:
>         SUNWcsl
> Current status: installed
> 
> # pkginfo SUNWcsl
> system      SUNWcsl Core Solaris, (Shared Libs)
> 
> And I've also got Blastwave packages of Apache (1.3.33) and mod_php
> (4.3.10, my current testing package with PostgreSQL 8.0 and MySQLi
> support, but still linking against OpenLDAP) :
> 
> # ldd /opt/csw/apache/libexec/libphp4.so
> ....
> libldap.so.2 =>  /opt/csw/lib/sparcv8/libldap.so.2
> 
> Yet when I start up Apache all seems fine. Granted, I'm not actually
> trying to use any of the LDAP functions, as I don't have a server to
> test against, but I don't get any segfaults. Same thing on a stock
> Solaris 8 box (although that only has libldap.so.4).
> 
> Is there some other SUNW package that I should install in order to
> duplicate this behaviour ? Does this happen at every startup of Apache
> ?
> 
> Thanks,
> 
> -Mark
> _______________________________________________
> users mailing list
> users at lists.blastwave.org
> https://lists.blastwave.org/mailman/listinfo/users
> 
> _______________________________________________
> users mailing list
> users at lists.blastwave.org
> https://lists.blastwave.org/mailman/listinfo/users

_______________________________________________
users mailing list
users at lists.blastwave.org
https://lists.blastwave.org/mailman/listinfo/users