Re: Initializing cn=config from existing multi-master setup via syncrepl - "new entry is older than ours"

[Thomas Chemineau <tchemineau@linagora.com>]

Hi,

> My question could be put more broadly: how can you tell syncrepl that
> is really *just* a slave, and replace everything it has with content
> from the master, even if one of it's own entries is more recent
> according to the CSN? The current behavior is to keep the most recent
> modification, thus comprising the replica's integrity.

Well, as said Jonathan, with an minimalistic slapadd (just few entries
such as cn=config; cn=schema,cn=config; olcDatabase={0}config,cn=config
and olcDatabase{-1}frontend,cn=config), all entire cn=config will be
replicated except those four entries due to the CSN. The idea is to add
a fictive CSN into the slapadd :

8<------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 2
entryCSN: 20000101000000.000000Z#000000#001#000000
createTimestamp: 20000101000000Z
modifyTimestamp: 20000101000000Z

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret
olcSyncRepl: rid=001 provider=ldap://server1/ binddn="cn=config"
  bindmethod=simple credentials=secret searchbase="cn=config"
  type=refreshAndPersist retry="5 5 300 5" timeout=3
entryCSN: 20000101000000.000000Z#000000#001#000000
createTimestamp: 20000101000000Z
modifyTimestamp: 20000101000000Z

[...]
8<------------

In this case, all cn=config branch will be replicated, because of old
CSN compared to the provider (server1). The replica will become a
provider because of its reference in olcSyncRepl attribute on the
primary provider (server1).

All work fine.

But, there are still problems. I saw one when the replica started, when
it attempts to replicate the oldDatabase={0}config,cn=config, that
force OpenLDAP to stop.

8<--------
Config: ** successfully added syncrepl "ldap://192.168.101.12/";
ldif_read_file: read entry file:
"/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif"
=> str2entry: "dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
olcRootPW:: c2VjcmV0
olcSyncrepl: {0}rid=001 provider=ldap://192.168.101.11/
  binddn="cn=config" bindmethod=simple credentials=linagora
  searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5"
  timeout=3
entryCSN: 20000101000000.000000Z#000000#001#000000
createTimestamp: 20000101000000Z
modifyTimestamp: 20000101000000Z
structuralObjectClass: olcDatabaseConfig
entryUUID: d7843fc4-93b8-433d-85d2-cc398eb3ee2a
creatorsName: cn=config
modifiersName: cn=config
"
>>> dnPrettyNormal: <olcDatabase={0}config>
=> ldap_bv2dn(olcDatabase={0}config,0)
<= ldap_bv2dn(olcDatabase={0}config)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(olcDatabase={0}config)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(olcDatabase={0}config)=0 
<<< dnPrettyNormal: <olcDatabase={0}config>, <olcDatabase={0}config>
>>> dnNormalize: <cn=config>
=> ldap_bv2dn(cn=config,0)
<= ldap_bv2dn(cn=config)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=config)=0 
<<< dnNormalize: <cn=config>
>>> dnNormalize: <cn=config>
=> ldap_bv2dn(cn=config,0)
<= ldap_bv2dn(cn=config)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=config)=0 
<<< dnNormalize: <cn=config>
>>> dnNormalize: <cn=config>
=> ldap_bv2dn(cn=config,0)
<= ldap_bv2dn(cn=config)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=config)=0 
<<< dnNormalize: <cn=config>
<= str2entry(olcDatabase={0}config) -> 0x2886a38
<= acl_access_allowed: granted to database root
ldif_write_entry: wrote entry "olcDatabase={0}config,cn=config"
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
ldap_msgfree
slapd: result.c:112: ldap_result: Assertion `ld != ((void *)0)' failed.
Abandon
8<--------

By restarting it, it seams that all datas has been replicated
successfully and OpenLDAP will not stop anymore.

Any idea ? A bug ?

Cheers,
Thomas.