Hi,

I am trying to get cn=config replication working as demonstrated by the test059-slave-config test script, but have run into a problem with schema replication. This is the same issue raised on the list previously by Christopher Strider Cook [1], but I thought I'd bring it up again as it's been seven years, so perhaps there are new ideas in this space. Furthermore, I can demonstrate how to reproduce the problem with a simpler configuration than that described by Christopher.

[1]: https://www.openldap.org/lists/openldap-technical/201106/msg00157.html

test059-slave-config describes two configuration trees, cn=config as used by a master server, and cn=config,cn=slave which is replicated to any number of replica servers. Furthermore, there is a syncrepl agreement defined on the cn=config,cn=slave database that replicates the master schema from cn=schema,cn=config into the replica configuration tree as cn=schema,cn=config,cn=slave.

If you make any changes to the cn=config,cn=slave tree however, the next time the master is restarted, it will complain that the "consumer state is newer than provider". At this point, I'm considering ditching the schema replication, and maintaining it independently on the master and replica servers. It's probably not much of an imposition seeing as I will need to maintain the rest of the master and replica configuration independently anyway. Nevertheless, I thought I'd raise the issue here to see if anyone had any clever solutions to this problem.

Here's how to reproduce the issue (OpenLDAP 2.4.46 on Linux 4.15.12):

1. Download and build OpenLDAP 2. Run test059-slave-config:

./run test059-slave-config

3. Start a slapd using the provider config created by the test script:

/home/richard/working/openldap-2.4.46/tests/../servers/slapd/slapd -F  /home/richard/working/openldap-2.4.46/tests/testrun/cfpro.d -h ldap://localhost:9011/ -d 0x4105

4. Make a change under cn=config,cn=slave:

$ ldapadd -x -h localhost -p 9011 -D cn=config -w EMWRueBU     dn: olcBackend=bdb,cn=config, cn=slave     objectClass: olcBackendConfig     olcBackend: bdb

adding new entry "olcBackend=bdb,cn=config, cn=slave"     ^C

5. Restart the slapd instance:

^C /home/richard/working/openldap-2.4.46/tests/../servers/slapd/slapd -F  /home/richard/working/openldap-2.4.46/tests/testrun/cfpro.d -h ldap://localhost:9011/ -d 0x4105

...SNIP...     5b3b0202 conn=1005 op=1 SRCH base="cn=schema,cn=config" scope=2 deref=0 filter="(objectClass=*)"     5b3b0202 conn=1005 op=1 SRCH attr=* +     5b3b0202 send_ldap_result: conn=1005 op=1 p=3     5b3b0202 send_ldap_result: err=0 matched="" text=""     5b3b0202 send_ldap_result: conn=1005 op=1 p=3     5b3b0202 send_ldap_result: err=53 matched="" text="consumer state is newer than provider!"     5b3b0202 send_ldap_response: msgid=2 tag=101 err=53     ber_flush2: 52 bytes to sd 16     read1msg: ld 0x7fd46c109ba0 msgid 2 all 0     ber_get_next     5b3b0202 conn=1005 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider!     ber_get_next: tag 0x30 len 50 contents:     read1msg: ld 0x7fd46c109ba0 msgid 2 message type search-result     ber_scanf fmt ({eAA) ber:     read1msg: ld 0x7fd46c109ba0 0 new referrals     read1msg:  mark request completed, ld 0x7fd46c109ba0 msgid 2     request done: ld 0x7fd46c109ba0 msgid 2     res_errno: 53, res_error: <consumer state is newer than provider!>, res_matched: <>     ldap_free_request (origid 2, msgid 2)     5b3b0202 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT     ldap_parse_result     ber_scanf fmt ({iAA) ber:     ber_scanf fmt (}) ber:     ldap_err2string     5b3b0202 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform     ldap_err2string

Any suggested workarounds would be appreciated.

Regards,