8:54 a.m.
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.
10:35 a.m.
--On Wednesday, August 31, 2011 5:54 PM +0200 Clément OUDOT
<clem.oudot(a)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
10:41 a.m.
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.
11:06 a.m.
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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
12:25 p.m.
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.
1:04 p.m.
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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
2:16 p.m.
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.
1:30 a.m.
2011/8/31 Michael Ströder <michael(a)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.
4228
days inactive
4229
days old
openldap-technical@openldap.org
7 comments
4 participants
participants (4)
-
Clément OUDOT -
Emmanuel Lecharny -
Michael Ströder -
Quanah Gibson-Mount