Those files plus various header files don't seem to correspond to what is being returned, but as I would expect, to various internal representations of the contextCSN.
contextCSN: 20080304184021.024760Z#000000#001#000000 Seems to be a date and timestamp, YYYYmmDDhhMMss.partOfSecond, followed by ???, then the rid, then ???.
From the code and struct definitions I would have expected the to see a
sid and some state indicator too.
I went looking in the schema files to see if contextCSN was mentioned with no success.
Obviously I don't know my way around the source code for OpenLDAP, but I'm willing to keep looking if you would give me another hint. I guess I would start trying to find where the contextCSN gets returned in the answer to a query, but this sounds like a difficult task going through lots of layers of the code. Again any help would be appreciated. Thanks. Roy
-----Original Message----- From: Gavin Henry [mailto:ghenry@suretecsystems.com] Sent: Tuesday, March 04, 2008 12:30 PM To: Marantz, Roy Cc: openldap-software@openldap.org Subject: RE: Testing the state of replicates
<quote who="Marantz, Roy">
I saw the admin24 section, but thought that the contextCSN was meant
to
be opaque.
I've looked at rfc4533, but reading sections 2.1.2 through 2.3 doesn't give me enough information to parse the contextCSN value into
something
I can understand. Do you know where I could get (or write) some code
to
decode the result?
Dig the main source. servers/slapd/syncrepl.c and servers/slapd/overlays/syncprov.c
Thanks for your help. Roy
-----Original Message----- From: Gavin Henry [mailto:ghenry@suretecsystems.com] Sent: Tuesday, March 04, 2008 10:49 AM To: Marantz, Roy Cc: openldap-software@openldap.org Subject: Re: Testing the state of replicates
Is there something I can query, like contextCSN, to indicate the last time syncrepl successfully finished resyncing the particular
database?
Any other way to do this or am I just trying to do something that is impossible?
See:
http://www.openldap.org/doc/admin24/replication.html#Syncrepl%20Details
"The consumer also stores its replica state, which is the provider's contextCSN received as a synchronization cookie, in the contextCSN attribute of the suffix entry. The replica state maintained by a consumer server is used as the synchronization state indicator when it performs subsequent incremental synchronization with the provider server. It is also used as a provider-side synchronization state indicator when it functions as a secondary provider server in a cascading replication configuration. Since the consumer and provider state information are maintained in the same location within their respective databases, any consumer can be promoted to a provider (and vice versa) without any special actions."
And more detail at:
http://www.rfc-editor.org/rfc/rfc4533.txt
For example:
[ghenry@suretec-master admin]$ ldapsearch -x -H ldap://127.0.0.1 -s 'base' contextCSN # extended LDIF # # LDAPv3 # base <dc=suretecsystems, dc=com> (default) with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# suretecsystems.com dn: dc=suretecsystems,dc=com contextCSN: 20080228163422.801358Z#000000#000#000000
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1 [ghenry@suretec-slave admin]$ ldapsearch -x -H ldap://127.0.0.1 -s 'base' contextCSN # extended LDIF # # LDAPv3 # base <dc=suretecsystems, dc=com> (default) with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# suretecsystems.com dn: dc=suretecsystems,dc=com contextCSN: 20080228163422.801358Z#000000#000#000000
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1