Hello,
I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html
But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112
So can you confirm that OpenLDAP 2.4 does not support persistent search control? Is this feature planned?
Thanks for your help,
Clément.
--On Wednesday, August 31, 2011 5:54 PM +0200 Clément OUDOT clem.oudot@gmail.com wrote:
Hello,
I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html
But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112
So can you confirm that OpenLDAP 2.4 does not support persistent search control? Is this feature planned?
A quick grep through the source would to me indicate that it is not supported, since the only occurrence of it is where it is defined in ldap.h. I.e., no code taking action on it.
quanah@zre-ldap001:~/src/openldap/openldap-2-4$ find . -name "*" | xargs grep LDAP_CONTROL_PERSIST_REQUEST ./include/ldap.h:#define LDAP_CONTROL_PERSIST_REQUEST "2.16.840.1.113730.3.4.3"
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Clément OUDOT wrote:
I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html
draft-ietf-ldapext-psearch is not supported in OpenLDAP. This standard has serious deficiencies anyway making it almost unusable. I know what I'm talking about since I have to use that with eDirectory in a customer project.
But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112
This mentions syncrepl (see RFC 4533) as noted in this blog entry.
Ciao, Michael.
On 8/31/11 7:41 PM, Michael Ströder wrote:
Clément OUDOT wrote:
I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html
draft-ietf-ldapext-psearch is not supported in OpenLDAP. This standard has serious deficiencies anyway making it almost unusable. I know what I'm talking about since I have to use that with eDirectory in a customer project.
But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112
This mentions syncrepl (see RFC 4533) as noted in this blog entry.
The funny thing is that the way SyncRepl is implemented, it uses a mechanism which is a persistentSearch for the RefreshAndPersist mode.
What kind of deficiencies have you found that make the original PSearch spec unusable ? What would be needed to use the same mechanism than in Syncrepl to get it working ?
Emmanuel Lecharny wrote:
What kind of deficiencies have you found that make the original PSearch spec unusable ?
psearch is completely state-less. If a connector using it does not work it will miss deletes. Also restarting the connector will return *all* entries as results in a first phase. Your connector will not know when this first phase ends until it reaches the first result with ECN control attached.
Ciao, Michael.
On 9/1/11 9:25 PM, Michael Ströder wrote:
Emmanuel Lecharny wrote:
What kind of deficiencies have you found that make the original PSearch spec unusable ?
psearch is completely state-less. If a connector using it does not work it will miss deletes. Also restarting the connector will return *all* entries as results in a first phase. Your connector will not know when this first phase ends until it reaches the first result with ECN control attached.
Thanks. Yeah, but it's much more a lack of features than deficiencies.
For instance, a client requesting a PSearch may expect to receive everything again, in order to load a local storage.
But yes, PSearch could be greatly improved. And the syncrepl mechanism could be a good starting point for a better PSearch...
Emmanuel Lecharny wrote:
On 9/1/11 9:25 PM, Michael Ströder wrote:
Emmanuel Lecharny wrote:
What kind of deficiencies have you found that make the original PSearch spec unusable ?
psearch is completely state-less. If a connector using it does not work it will miss deletes. Also restarting the connector will return *all* entries as results in a first phase. Your connector will not know when this first phase ends until it reaches the first result with ECN control attached.
Thanks. Yeah, but it's much more a lack of features than deficiencies.
Hmm...
For instance, a client requesting a PSearch may expect to receive everything again, in order to load a local storage.
But yes, PSearch could be greatly improved. And the syncrepl mechanism could be a good starting point for a better PSearch...
It does not make sense to improve draft-ietf-ldapext-psearch since the server vendors who already implemented the current (expired) version of the I-D won't modify their implementations. And any client/connector implementor who wants to access OpenLDAP should implement syncrepl.
Ciao, Michael.
2011/8/31 Michael Ströder michael@stroeder.com:
Clément OUDOT wrote:
I tried to know if the persistent search control (OID 2.16.840.1.113730.3.4.3) was supported in OpenLDAP. The latests messages I read were saying "no", as we can see in this discussion: http://www.openldap.org/lists/openldap-technical/201008/msg00246.html
draft-ietf-ldapext-psearch is not supported in OpenLDAP. This standard has serious deficiencies anyway making it almost unusable. I know what I'm talking about since I have to use that with eDirectory in a customer project.
But this blog entry is saying this control was introduced in OpenLDAP 2.2: http://www.connexitor.com/blog/pivot/entry.php?id=112
This mentions syncrepl (see RFC 4533) as noted in this blog entry.
Hi,
thanks for the precision. The reason why I mentioned that blog entry was because it was pointed in another blog entry explaining how use OpenSSO with OpenLDAP : http://blogs.oracle.com/indira/entry/using_openldap_as_user_data
See the first point of the Limitations chapter.
But the comments on the connexitor blogs are quite false: even if OpenLDAP support some kind of persistent search with the syncprov overlay, it is not the psearch control used by OpenSSO, so until OpenSSO use the other control, the persistent search of OpenSSO will not be used on an OpenLDAP instance.
Clément.
openldap-technical@openldap.org
-
Clément OUDOT -
Emmanuel Lecharny -
Michael Ströder -
Quanah Gibson-Mount