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,

Richard Gray | Operations Technical Lead
DDI: +64 9 950 2196 Fax: +64 9 302 0518
Mobile: +64 21 050 8178 Freephone:0800 SMX SMX (769 769)
SMX Limited: Level 15, 19 Victoria Street West, Auckland, New Zealand
Web: http://smxemail.com
SMX |
Cloud Email Hosting & Security

This email has been filtered by SMX. For more information visit smxemail.com.