[Issue 10424] New: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base
https://bugs.openldap.org/show_bug.cgi?id=10424
Issue ID: 10424 Summary: When using more than one syncrepl directive on a single DB, the contextCSN should be stored accordingly to the replication base Product: OpenLDAP Version: 2.6.10 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: elecharny@apache.org Target Milestone: ---
Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it:
{0}rid=004 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="olcDatabase={-1}frontend,cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off
If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry.
Would I like to replicate, says, 'cn=config' with another syncrepl directive like:
olcSyncrepl: {0}rid=001 provider=ldaps://openldap1:10636 bindmethod=simple binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com" credentials=blah tls_cacert=/opt/application/openldap/ssl/ca.crt tls_cert=/opt/application/openldap/ssl/openldap-common.crt tls_key=/opt/application/openldap/ssl/openldap-common.key tls_reqcert=demand tls_protocol_min=3.3 searchbase="cn=config" scope="base" type=refreshAndPersist retry="30 +" timeout=1 schemachecking=off
where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case).
I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database.
https://bugs.openldap.org/show_bug.cgi?id=10424
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.6.12 Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=10424
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.12 |2.6.13
https://bugs.openldap.org/show_bug.cgi?id=10424
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.13 |2.6.14
https://bugs.openldap.org/show_bug.cgi?id=10424
--- Comment #1 from Ondřej Kuzník ondra@mistotebe.net --- On Tue, Jan 13, 2026 at 01:37:24PM +0000, openldap-its@openldap.org wrote:
Trying to replicate cn=config but parially, I tried to set many syncrepl directives so that each oe of them just replicate the single element it is configured for. Here is an exemple thet replicate the frontend database and only it: [...]
If I have this single syncrepl directive, all is ok, it replicates the frontend data and only this entry.
Would I like to replicate, says, 'cn=config' with another syncrepl directive like: [...]
where the search base is different, then suddenly I get some 'CSN too old' errors, which make totally sense as we only have one single contextCSN stored in the root entry (cn=config in my use case).
I know I'm really border line here (and the rational is that I want a partial replication of cn=config because the two servers are a bit different), but I would suggest that the contextCSN to be stored in the entry associated to the searchBase, not at the root of the database.
Hi Emmanuel, yes, this is currently not supported, each DB is expected to only have one consumer (searchbase post suffixmassage) set up taking full ownership of that subtree.
That's it and changing it would probably be a bigger piece of work, potentially blocked on splitting syncrepl into its own overlay which hasn't really happened yet.
Regards,
https://bugs.openldap.org/show_bug.cgi?id=10424
--- Comment #2 from elecharny@apache.org --- Hi Ondřej,
Indeed, I can see the huge required change it would require.
I just wanted to create the issue (or rather a feature request) so that we have it in the list of 'good to have' for a future release.
I wasn't able to set the ticket 'importance' to 'feature request', but that was the spirit.
It's more like a X.500 thing where we would store the contextCSN in a subentry, allowing a partial replication of a DIT...
But LDAP is not X.500 for very good reasons ;-)
https://bugs.openldap.org/show_bug.cgi?id=10424
--- Comment #3 from Howard Chu hyc@openldap.org --- Actually since we already have a sync_use_subentry option, this wouldn't be too difficult to support. It just would create the subentry under the consumer's searchbase instead of under the context entry.
https://bugs.openldap.org/show_bug.cgi?id=10424
--- Comment #4 from elecharny@apache.org --- Indeed.
And actually that was the reason I was thinking it would be a good addition.
My initial request was not exactly clear in this respect when I mentioned the possibility to store the contextCSN on a subentry, as it's currently supported, but the meat in this proposal is elsewhere, as you said.
Thanks for the heads up!
https://bugs.openldap.org/show_bug.cgi?id=10424
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- On Wed, Feb 11, 2026 at 03:42:42PM +0000, openldap-its@openldap.org wrote:
Actually since we already have a sync_use_subentry option, this wouldn't be too difficult to support. It just would create the subentry under the consumer's searchbase instead of under the context entry.
It's not "just" the subentry, sure, that bit is "easy", it's that the rest of syncrepl expects there to be one context for each DB, this would need to be split up per "sub-suffix" as well and then there's the interaction with accesslog and especially syncprov (just *what* is the right information to even forward?).
It might not be "hard to do" but the question I can't answer yet is "is it hard to do *right*?" That's without considering whether our testing infrastructure is capable of covering a reasonable chunk of what we need to test.
https://bugs.openldap.org/show_bug.cgi?id=10424
--- Comment #6 from elecharny@apache.org --- And more important: is there a critical need for that ? ;-)
It's more an intellectual exercise atm: "what if? And what would be the impact and the effort?"
Anyway, we should just sleep on that, and maybe have a discussion at LdapCON in November about the pros and cons;-)
Anyway, thanks for the nice feedback, Ondrej!
https://bugs.openldap.org/show_bug.cgi?id=10424
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|When using more than one |When using more than one |syncrepl directive on a |syncrepl directive on a |single DB, the contextCSN |single DB, the contextCSN |should be stored |should be stored according |accordingly to the |to the replication base |replication base |
-
openldap-its＠openldap.org