Hi!
What I would like to understand:
1. How do I query a master for the cookie? 2. How do I query a slave for the coolie? 3. How do I query the master in a human readable format for all changes based on a cookie which I present?
My apologies if these questions should have been answered by reading the documentation; I did not find it there, unfortunately.
I am sure someone who is a bit more into this can just reply with three simple ldadpsearch statemenets.
Regards, Torsten
On Thu, 5 Nov 2009, Torsten Schlabach (Tascel eG) wrote:
- How do I query a master for the cookie?
- How do I query a slave for the coolie?
$ ldapsearch -xLLLH ldap://localhost/ -s base -b "dc=rutgers,dc=edu" contextCSN dn: dc=rutgers,dc=edu contextCSN: 20070613170816.000000Z#000000#000#000000
Works on either a slave or a master.
- How do I query the master in a human readable format for all changes
based on a cookie which I present?
See -E sync option, described in ldapsearch(1) man page, for the syntax (it depends on what method you desire, for example you must choose refreshOnly/refreshAndPersist). One completed example is at http://www.openldap.org/lists/openldap-technical/200909/msg00202.html
(not sure if you'll consider it human-readable, but that's a whole different story...it's plain text output, at least?)
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi!
What I would like to understand:
- How do I query a master for the cookie?
- How do I query a slave for the coolie?
- How do I query the master in a human readable format for all changes
based on a cookie which I present?
My apologies if these questions should have been answered by reading the documentation; I did not find it there, unfortunately.
I am sure someone who is a bit more into this can just reply with three simple ldadpsearch statemenets.
1. Request a provider ldapsearch -D cn=replicator,o=avci,c=de -w secret \ -H ldap://localhost -b o=avci,c=de -s sub \ -E '!sync=ro/rid=042'
as result all entries are presented and in addtion a control control: 1.3.6.1.4.1.4203.1.9.1.3 false MIQAAAA5BDRyaWQ9MDQ2LGNzbj0yMDA5MTEwMz IwMjkwOC4yMzA2MzJaIzAwMDAwMCMwMDAjMDAwMDAwAQH/
the base64 encoded value is the cookie, which may be used to request changes.
2. Request a consumer ldapsearch -Y external -ZZ -H ldap://localhost:9004 -b o=avci,c=de \ -s base contextcsn
-Dieter
Hi!
Thanks for that ...
When I try to use anything like
-E'!sync=ro/rid=042,csn=20090928054615.449093Z#000000#000#000000'
I get
# search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context
# numResponses: 1
Does that mean, something with my ldapsearch (client side) is wrong or does it mean something is missing on my server?
Regards, Torsten
Dieter Kluenter schrieb:
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi!
What I would like to understand:
- How do I query a master for the cookie?
- How do I query a slave for the coolie?
- How do I query the master in a human readable format for all changes
based on a cookie which I present?
My apologies if these questions should have been answered by reading the documentation; I did not find it there, unfortunately.
I am sure someone who is a bit more into this can just reply with three simple ldadpsearch statemenets.
- Request a provider
ldapsearch -D cn=replicator,o=avci,c=de -w secret \ -H ldap://localhost -b o=avci,c=de -s sub \ -E '!sync=ro/rid=042'
as result all entries are presented and in addtion a control control: 1.3.6.1.4.1.4203.1.9.1.3 false MIQAAAA5BDRyaWQ9MDQ2LGNzbj0yMDA5MTEwMz IwMjkwOC4yMzA2MzJaIzAwMDAwMCMwMDAjMDAwMDAwAQH/
the base64 encoded value is the cookie, which may be used to request changes.
- Request a consumer
ldapsearch -Y external -ZZ -H ldap://localhost:9004 -b o=avci,c=de \ -s base contextcsn
-Dieter
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi!
Thanks for that ...
When I try to use anything like
-E'!sync=ro/rid=042,csn=20090928054615.449093Z#000000#000#000000'
I get
# search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context
# numResponses: 1
Does that mean, something with my ldapsearch (client side) is wrong or does it mean something is missing on my server?
This is rather strange. What is your OpenLDAP version? The result code 12 indicates that sync control is unavailable, for more info on this see RFC 4511, section 4.1.9 and 4.1.11
What is the result of ldapsearch -b "" -s base supportedControl | egrep "1.9.1.1" it should be: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
-Dieter
Hi Dieter!
v014ldap:/# ldapsearch -x -D 'cn=admin,dc=nodomain' -w XXXX -b "" -s base supportedControl | egrep "1.9.1.1" supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 v014ldap:/# ldapsearch -x -D 'cn=admin,cn=config' -w XXXXXX -b "" -s base supportedControl | egrep "1.9.1.1" supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
Looks good, doesn't it?
I am at 2.4.11.
I know, I should upgrade to 2.4.19.
I am currently trying to do that. But I cannot find any .deb (Debian / Ubuntu) package for 2.4.19. There is some stuff for 2.4.17 or so in Debian testing, but I guess you want me to use the really latest stuff.
Unfortunately, I am struggling for 1/2 day today with getting the 2.4.19 package compiled.
Just because I am courious:
a) What does that supportedControl atrribute mean? (I guess it means syncprov available, doesn'it ?) b) I am sure there are tons more of those diagnostic attributes like this one. I know for example that I can ask for SASL mechanisms supported, etc. Are those options documented anywhere?
Regards, Torsten
Dieter Kluenter schrieb:
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi!
Thanks for that ...
When I try to use anything like
-E'!sync=ro/rid=042,csn=20090928054615.449093Z#000000#000#000000'
I get
# search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context
# numResponses: 1
Does that mean, something with my ldapsearch (client side) is wrong or does it mean something is missing on my server?
This is rather strange. What is your OpenLDAP version? The result code 12 indicates that sync control is unavailable, for more info on this see RFC 4511, section 4.1.9 and 4.1.11
What is the result of ldapsearch -b "" -s base supportedControl | egrep "1.9.1.1" it should be: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
-Dieter
Hi Torsten,
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi Dieter!
v014ldap:/# ldapsearch -x -D 'cn=admin,dc=nodomain' -w XXXX -b "" -s base supportedControl | egrep "1.9.1.1" supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 v014ldap:/# ldapsearch -x -D 'cn=admin,cn=config' -w XXXXXX -b "" -s base supportedControl | egrep "1.9.1.1" supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
Looks good, doesn't it?
Yes.
I am at 2.4.11.
I know, I should upgrade to 2.4.19.
I am not commenting on this.
I am currently trying to do that. But I cannot find any .deb (Debian / Ubuntu) package for 2.4.19. There is some stuff for 2.4.17 or so in Debian testing, but I guess you want me to use the really latest stuff.
Unfortunately, I am struggling for 1/2 day today with getting the 2.4.19 package compiled.
Just because I am courious:
a) What does that supportedControl atrribute mean? (I guess it means syncprov available, doesn'it ?)
Yes.
b) I am sure there are tons more of those diagnostic attributes like this one. I know for example that I can ask for SASL mechanisms supported, etc. Are those options documented anywhere?
All controls and extended operations are documented in their relevant RFC, for syncprov this is RFC 4533. I am not aware of a digest of all relevant OID's. But Michael Stroeder has undergone the work to add a description to all OID's, so web2ldap displays the description of the presented OID's.
Back to your problem. The only other reasons could be - access control - wrong search base in search string - no activation of syncprov overlay
-Dieter
Hi!
web2ldap
Never seen that one before, thanks. So far we have been using either phpldapadmin (for web) or GQ LDAP client (desktop).
- no activation of syncprov overlay
We found out already that it's "available", see below.
So is there a difference between "it's available", "it's loaded" and "it's actually active"?
Regards, Torsten
Dieter Kluenter schrieb:
Hi Torsten,
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi Dieter!
v014ldap:/# ldapsearch -x -D 'cn=admin,dc=nodomain' -w XXXX -b "" -s base supportedControl | egrep "1.9.1.1" supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 v014ldap:/# ldapsearch -x -D 'cn=admin,cn=config' -w XXXXXX -b "" -s base supportedControl | egrep "1.9.1.1" supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
Looks good, doesn't it?
Yes.
I am at 2.4.11.
I know, I should upgrade to 2.4.19.
I am not commenting on this.
I am currently trying to do that. But I cannot find any .deb (Debian / Ubuntu) package for 2.4.19. There is some stuff for 2.4.17 or so in Debian testing, but I guess you want me to use the really latest stuff.
Unfortunately, I am struggling for 1/2 day today with getting the 2.4.19 package compiled.
Just because I am courious:
a) What does that supportedControl atrribute mean? (I guess it means syncprov available, doesn'it ?)
Yes.
b) I am sure there are tons more of those diagnostic attributes like this one. I know for example that I can ask for SASL mechanisms supported, etc. Are those options documented anywhere?
All controls and extended operations are documented in their relevant RFC, for syncprov this is RFC 4533. I am not aware of a digest of all relevant OID's. But Michael Stroeder has undergone the work to add a description to all OID's, so web2ldap displays the description of the presented OID's.
Back to your problem. The only other reasons could be
- access control
- wrong search base in search string
- no activation of syncprov overlay
-Dieter
"Torsten Schlabach (Tascel eG)" tschlabach@tascel.net writes:
Hi!
web2ldap
Never seen that one before, thanks. So far we have been using either phpldapadmin (for web) or GQ LDAP client (desktop).
- no activation of syncprov overlay
We found out already that it's "available", see below.
So is there a difference between "it's available", "it's loaded" and "it's actually active"?
Yes, there are differences. If you search rootdn for particular features like controls, the returned result only indicates that these features are known to the DSA, but that does not always indicate that controls are supported by the DSA. You may read ldap.h for controls not implemented in slapd. In OpenLDAP, if you configure an overlay module to be loaded by means of moduleload in slapd.conf, this overlay module is loaded but the overlay itself is still not active, this has to be done by the parameter 'overlay' and additional configuration paramters, if applicable.
-Dieter
--On Friday, November 06, 2009 3:39 PM +0100 "Torsten Schlabach (Tascel eG)" tschlabach@tascel.net wrote:
Hi!
Thanks for that ...
When I try to use anything like
-E'!sync=ro/rid=042,csn=20090928054615.449093Z#000000#000#000000'
I get
# search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context
# numResponses: 1
Does that mean, something with my ldapsearch (client side) is wrong or does it mean something is missing on my server?
Is the syncprov overlay loaded?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi!
Is the syncprov overlay loaded?
Well, in the log of the server I can find lines like:
Nov 8 19:03:18 v014ldap slapd[23199]: syncprov_search_response: cookie=rid=004,sid=000,csn=20091104001407.996360Z#000000#000#000000 Nov 8 19:03:21 v014ldap slapd[23199]: begin get_filter Nov 8 19:03:21 v014ldap slapd[23199]: PRESENT Nov 8 19:03:21 v014ldap slapd[23199]: end get_filter 0 Nov 8 19:03:21 v014ldap slapd[23199]: do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT Nov 8 19:03:21 v014ldap slapd[23199]: begin get_filter Nov 8 19:03:21 v014ldap slapd[23199]: PRESENT Nov 8 19:03:21 v014ldap slapd[23199]: end get_filter 0 Nov 8 19:03:21 v014ldap slapd[23199]: do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT
I guess this means it's loaded, isn't it?
Regards, Torsten
Quanah Gibson-Mount schrieb:
--On Friday, November 06, 2009 3:39 PM +0100 "Torsten Schlabach (Tascel eG)" tschlabach@tascel.net wrote:
Hi!
Thanks for that ...
When I try to use anything like
-E'!sync=ro/rid=042,csn=20090928054615.449093Z#000000#000#000000'
I get
# search result search: 2 result: 12 Critical extension is unavailable text: critical control unavailable in context
# numResponses: 1
Does that mean, something with my ldapsearch (client side) is wrong or does it mean something is missing on my server?
Is the syncprov overlay loaded?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Sunday, November 08, 2009 7:05 PM +0100 "Torsten Schlabach (Tascel eG)" tschlabach@tascel.net wrote:
Hi!
Is the syncprov overlay loaded?
Well, in the log of the server I can find lines like:
I guess this means it's loaded, isn't it?
You read your configuration and see if the server as a module load statement for the syncprov overlay in the database section, if it is slapd.conf, or dump the config database and see if the cn=config related version of it.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Aaron Richton -
Dieter Kluenter -
Quanah Gibson-Mount -
Torsten Schlabach (Tascel eG)