With what previous PHP version? And do you use the same openldap library version as you did with the previous PHP version?

I'm not sure what version of the OpenLDAP client libs I was using. It's whatever ships with FC1.

--Dave

By the way, I doubt it's an LDAP client lib problem, as ldapsearch worked consistently in all cases.

Then please dig into which library FC1 uses.

Does this help:

$ rpm -qi openldap
Name        : openldap                     Relocations: (not relocateable)
Version     : 2.1.22                            Vendor: Red Hat, Inc.
Release     : 8                             Build Date: Thu 23 Oct 2003 10:26:42 AM EDT
Install Date: Sat 22 Nov 2003 01:03:19 PM EST      Build Host: bugs.devel.redhat.com
Group       : System Environment/Daemons    Source RPM: openldap-2.1.22-8.src.rpm
Size        : 1584111                          License: OpenLDAP
Signature   : DSA/SHA1, Tue 28 Oct 2003 06:49:57 PM EST, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.openldap.org/
Summary     : The configuration files, libraries, and documentation for OpenLDAP.
Description :
OpenLDAP is an open source suite of LDAP (Lightweight Directory Access
Protocol) applications and development tools. LDAP is a set of
protocols for accessing directory services (usually phone book style
information, but other information is possible) over the Internet,
similar to the way DNS (Domain Name System) information is propagated
over the Internet. The openldap package contains configuration files,
libraries, and documentation for OpenLDAP.



$ rpm -ql openldap
/usr/lib/liblber.so.2
/usr/lib/liblber.so.2.0.122
/usr/lib/libldap.so.2
/usr/lib/libldap.so.2.0.122
/usr/lib/libldap_r.so.2
/usr/lib/libldap_r.so.2.0.122

In response to you inquiry, a peer of mine reports the following:

> I have just tested the same code on Mandrake 10, php 4.3.7, and it works
> fine.
> 
> The system that I was having the problem on is RHEL3, php 4.3.4.   I will
> do a little recompiled of PHP
> and see how it goes.
> 
> It appears that, on the system with the problem.  when  this bit of code
> runs
> 
> // Fetch basic RootDSE attributes using the + and *.
> $r = @ldap_read( $ds, '', 'objectClass=*', array( '+', '*' ) );
> 
> 
> The ldap server receives a search, with base "dc=example,dc=com", which is
> a little strange,
> as I can't find the string "dc=example" anywhere in the php or ldap server
> source. Guess it must be comming from somwhere however.
> 
> I would be happy fix the problem, except it appears to be nothing to do
> with the PHP code, but rather PHP, or the openldap libraries it's compiled
> against. Do you know about the Monitor back end for openldap?  I found
> that
> when I was looking around at this problem, and that backend appears to
> provide some usful information also.
> 
> It may not be very ustul, but here is a list of the system libaries
> versions that does not work.
> 
> [nelg@cub nelg]$ rpm -qi openldap
> Name        : openldap                     Relocations: (not relocatable)
> Version     : 2.0.27                            Vendor: Red Hat, Inc.
> Release     : 11                            Build Date: Sat 20 Sep 2003
> 09:23:05 NZST
> Install Date: Fri 29 Aug 2003 00:37:34 NZST      Build Host:
> bugs.devel.redhat.com
> Group       : System Environment/Daemons    Source RPM:
> openldap-2.0.27-11.src.rpm
> Size        : 1153098                          License: OpenLDAP
> Signature   : DSA/SHA1, Thu 25 Sep 2003 05:41:52 NZST, Key ID
> 219180cddb42a60e
> Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> URL         : http://www.openldap.org/
> Summary     : The configuration files, libraries, and documentation for
> OpenLDAP.
> 
> [nelg@cub nelg]$ rpm -qi php-ldap
> Name        : php-ldap                     Relocations: (not relocatable)
> Version     : 4.3.4                             Vendor: (none)
> Release     : 1mdk                          Build Date: Mon 17 May 2004
> 08:44:12 NZST
> Install Date: Mon 17 May 2004 08:44:35 NZST      Build Host:
> 10-1-3-251.tcs.ac.nz
> Group       : Development/Languages         Source RPM:
> php-ldap-4.3.4-1mdk.src.rpm
> Size        : 70198                            License: PHP License
> Signature   : (none)
> URL         : http://www.php.net
> Summary     : A module for PHP applications that use LDAP.
>

Search for ldap.conf (your filesystem and google)..
That's where the example.com comes from. 

ldap.conf has nothing to do with this bug. I am performing an ldap_read() and explicitly specificying my own search base (the empty string, ""). In this case, PHP and the LDAP libraries should not be reading the "base" directive in ldap.conf.

Despite this glaringly obvious fact, I tried removing the "base" directive from ldap.conf to see if that fixed it. It had no effect on the bug. So I tried changing the "base" directive from dc=example,dc=com to the correct one, dc=phpldapadmin,dc=com, but PHP still searches with base dc=example,dc=com (yes I restarted my web server and LDAP server). So then I tried creating ~apache/.ldaprc and setting the base to dc=phpldapadmin,dc=com there. Still no effect on the bug.

This is a bug. No matter what setting I have for my base in ldap.conf, PHP should is NOT using the base I specify in my call to ldap_read().

Perhaps PHP is interpreting a base of "" to mean "the default base DN specified somewhere else". This is NOT the desired behavior. The RFCs state that when searching with a base DN set to the empty string and a scope of "base", that the RootDSE entry should be returned. Note also that other versions of PHP work just fine with no changes to the LDAP libraries. See comments from other users as well.

Also note that ldapsearch works just fine, so it's obviously not the LDAP client libraries. This is a PHP bug.

--Dave

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I'm seeing this problem in Fedora Core 3 - which is using php 4.3.10.

Withouth having to create my own php - any tips on how this can be resolved?

Is there a fix in the code available?

After installing the new PHP version, and commenting out the BASE line in both my ldap.conf files (one in /etc and one in /etc/openldap), it now works as expected!

Good work!

--Dave

Considering we didn't change anything in ext/ldap between this period and that I did mention ldap.conf once before -> bogus.
(it wasn't PHP bug after all, was it? :)

Indeed. Please accept my humble apology.

--Dave

Whatever the case, it may be worth investigating why PHP's ldap_read() failed in this case while the command line ldapsearch continued to function properly despite the ldap.conf settings.