On 01/10/15 04:48 PM, Quanah Gibson-Mount wrote: > --On Thursday, October 01, 2015 12:26 PM -0400 Patrick > <pbrideau@kronostechnologies.com> wrote: > >> >> I've been trying to create a complex multi-master replication of >> cn=config for a week now... I'm using the core debian package: slapd >> 2.4.40+dfsg-1+deb8u1 >> >> >> I've seen someone claiming it could work but cannot find configs related >> to this kind of topology. >> http://www.slideshare.net/ghenry/openldap-replication-strategies >> (slide #24) >> >> >> When building a simple multimaster (two or three nodes) everything works >> as planned. But in the case some nodes cannot talk to others, i cannot >> find a way to make it works. >> >> >> Let's take this example >> >> +-------+ +-------+ +-------+ >> | ldap1 | <---> | ldap2 | <---> | ldap3 | >> +-------+ +-------+ +-------+ >> >> and say: >> olcSyncRepl: rid=001 >> searchbase="cn=config" >> type=refreshAndPersist >> provider=ldap://ldap1 >> olcSyncRepl: rid=002 >> searchbase="cn=config" >> type=refreshAndPersist >> provider=ldap://ldap2 >> olcSyncRepl: rid=003 >> searchbase="cn=config" >> type=refreshAndPersist >> provider=ldap://ldap3 >> >> Where initialy: >> ldap1 have rid=002 >> ldap2 have rid=001 and rid=003 >> ldap3 have rid=002 >> >> >> Soon everyone get rid=001 rid=002 rid=003 and ldap3 cannot talk to ldap1 >> and it does not work... >> >> And even if i don't care about the connexion between ldap1 and ldap3 >> failing, the replication does not work either... if ldap1 change >> something, it gets replicated to ldap2 but not ldap3. >> >> >> Also, i've been trying to use exattrs=Syncrepl but if someone change his >> Syncrepl, it get deleted on the other node... Someone seems to have >> seen this with memberof overlay ? >> >> http://www.openldap.org/lists/openldap-technical/201505/msg00124.html >> >> >> >> Anyone have references to help me get to my goal? > > While I avoid replicating cn=config, we have several customers with 3+ > MMR setups for their back-mdb databases that work just fine. You fail > to note what your *serverID* is set to on each master, as that's > required to be different. > > I would suggest you set your log level to "sync stats" and determine why > the various masters are unable to talk to one another. > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration Thanks for the reply. the serverID config where all set as: dn: cn=config objectClass: olcGlobal [...] olcServerID: 1 ldap://ldap1 olcServerID: 2 ldap://ldap2 olcServerID: 3 ldap://ldap3 Sorry it was not clear enough, it is by design that ldap1 and ldap3 cannot talk. They are in different networks and ldap2 is the one in between every networks. Without sync of cn=config, you replicate olcAccess,schemas,olcDbIndex, etc manually between servers? Patrick Brideau Administrateur Système Kronos Technologies - http://www.kronos-web.com tel: 418 877-5400 p.216
Attachment:
signature.asc
Description: OpenPGP digital signature