Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87702
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain kippdata.de designates 195.227.30.149 as permitted sender)
To: PHP internals <internals@lists.php.net>
References: <5582BC3E.30109@opensides.be> <55C8FFF9.40509@kippdata.de>
 <2E228E18-2AC9-4FA5-AB11-4F7C3365EB0B@heigl.org>
Cc: Andreas Heigl <andreas@heigl.org>,
        =?UTF-8?Q?C=c3=b4me_BERNIGAUD?= <come.bernigaud@opensides.be>
Message-ID: <55C92754.8040308@kippdata.de>
Date: Tue, 11 Aug 2015 00:36:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <2E228E18-2AC9-4FA5-AB11-4F7C3365EB0B@heigl.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] LDAP module requirements?
From: rainer.jung@kippdata.de (Rainer Jung)

Hi Andreas and all,

Am 10.08.2015 um 22:15 schrieb Andreas Heigl:
> Hi Rainer.
>
>> Am 10.08.2015 um 21:48 schrieb Rainer Jung <rainer.jung@kippdata.de>:
>>
>> Hi,
>>
>>> Am 18.06.2015 um 14:40 schrieb Côme BERNIGAUD:
>>> Hello,
>>>
>>> The code of the LDAP module have some ifdefs like
>>> LDAP_API_FEATURE_X_OPENLDAP to test if we are building against openldap
>>> or something else.
>>> Is there an exaustive list of the LDAP libs PHP is supposed to be
>>> buildable against?
>>>
>>> The following page suggest it should always be openldap, is that the case?
>>> http://php.net/manual/en/ldap.requirements.php
>>> (if so, could ifdefs of LDAP_API_FEATURE_X_OPENLDAP be safely removed?)
>>>
>>> What is the oldest openldap version supposed to be supported by each PHP
>>> version?
>>
>> being late to this discussion: I do ship PHP with ldap extension on Solaris using the Solaris ldap client libs. This worked well until and including 5.6.11. It is broken starting with 5.6.12, because now OpenLDAP is assumed and all or some compatibility ifdefs have been removed.
>>
>> Is their any interest to keep compatibility with Solaris ldap? If not, would it be possible to keep it for 5.6 and not drop it in a minor release? I saw, that the docs mention OpenLDAp as a requirement, but it worked for years very well with Solaris ldap client.
>>
>> The build for 5.6 currently issues the following warnings due to new incompatibilties:
>>
>> .../ext/ldap/ldap.c: In function 'ldap_control_find':
>> .../ext/ldap/ldap.c:77:3: warning: implicit declaration of function 'ldap_find_control' [-Wimplicit-function-declaration]
>>    return ldap_find_control(oid, ctrls);
>>    ^
>> .../ext/ldap/ldap.c:77:3: warning: return makes pointer from integer without a cast
>> .../ext/ldap/ldap.c: In function 'zif_ldap_connect':
>> /shared/build/autobuild/workdirs/20150810_145109/bld/php56/ext/ldap/ldap.c:370:3: warning: implicit declaration of function 'ldap_initialize' [-Wimplicit-function-declaration]
>>    rc = ldap_initialize(&ldap, url);
>>    ^
>> .../ext/ldap/ldap.c: In function 'zif_ldap_explode_dn':
>> .../ext/ldap/ldap.c:1308:2: warning: implicit declaration of function 'ldap_memvfree' [-Wimplicit-function-declaration]
>>   ldap_memvfree((void **)ldap_value);
>>   ^
>> .../ext/ldap/ldap.c: In function 'zif_ldap_set_rebind_proc':
>> .../ext/ldap/ldap.c:2563:34: warning: passing argument 2 of 'ldap_set_rebind_proc' from incompatible pointer type
>>    ldap_set_rebind_proc(ld->link, _ldap_rebind_proc, (void *) link);
>>                                   ^
>> In file included from .../ext/ldap/php_ldap.h:30:0,
>>                  from .../ext/ldap/ldap.c:45:
>> /usr/include/ldap.h:1205:26: note: expected 'int (*)(struct LDAP *, char **, char **, int *, int,  void *)' but argument is of type 'int (*)(struct LDAP *, const char *, ber_tag_t,  ber_int_t,  void *)'
>> LDAP_API(void) LDAP_CALL ldap_set_rebind_proc(LDAP *ld,
>>                           ^
>
> Sorry to hear that the build against the Solaris LDAP client fails nowmduentonthe cleanup. Come asked a long while ago whether there are any other libs used. And as the dicumentation states that the build should link against OpenLDAP we went ahead and removed those ifdefs.

Yeah I should have noticed the discussion when it happened 2 months ago.

> Can you give us a link to the Solaris LDAP lib? We'll then check what's possible and what not. The reason behind the cleanup (and therefore removal of ifdefs) was that we wanted to optimize PHPs ldap-functions and remove those calls to long-deprecated functions in the OpenLDAP library. Sonwe'll have to check what's possible with the Solaris lib.

The Solaris LDAP client is not open source. It has slapd as a common 
historical origin just like the Netscape LDAP variant. The current 
problems should be mostly around the above four compiler warnings. I can 
test any patches you want me to test.

The man pages documenting the interface functions are readable under

http://docs.oracle.com/cd/E19253-01/816-5170/6mbb5es45/index.html

The introduction page with a list of all interfaces is

http://docs.oracle.com/cd/E19253-01/816-5170/ldap-3ldap/index.html

I found a publicly available ldap.h which is apart from non-functional 
whitespace changes identical to the one on our system:

https://java.net/projects/solaris/sources/on-src/content/usr/src/head/ldap.h

> Out of interest: What is for you the benefit of using the Solaris-ldap lib instead of the OpenLDAP lib? I'd like to get a feeling for the issue!

This is about providing PHP for the Solaris platform. On that platform 
the Solaris ldap client is always installed. In theory you could remove 
it but most enterprise installations use it one way or another, so you 
can't get rid of it.

If PHP would only support the OpenLDAP client, we would have to bundle 
that client together with PHP to make the PHP ldap extension work. This 
would be feasible in principle, but there will be practical problems. 
For instance if PHP is running inside the Apache web server (mod_php, 
not FPM) and we activate the ldap extension, the Apache process will 
load two ldap client libraries. The platform one, because it will be 
used e.g. to resolve users etc. and the OpenLDAP one, because the PHP 
extension is linked against it. Both will define common symbols with 
incompatible implementations, so we would have to play dirty tricks to 
make sure, that the httpd binary resolves all ldap symbols in the 
platform libs, and the PHP ldap extension resolves the same symbols in 
the OpenLDAP lib. It is doable, but one would typically prefer to stick 
to the platform libs.

Thanks for your consideration.

Rainer