--On Thursday, October 01, 2015 12:26 PM -0400 Patrick <pbrideau(a)kronostechnologies.com&gt; 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

Patrick wrote: > dn: cn=config > objectClass: olcGlobal > [...] > olcServerID: 1 ldap://ldap1 > olcServerID: 2 ldap://ldap2 > olcServerID: 3 ldap://ldap3 Note that 1. you should probably use FQDNs instead of short names 2. you must explicitly start slapd to -h ldap://ldap1 etc. to really assign the server-ID to a certain replica. BTW: Personally I prefer to not replicate cn=config (I'm using static configuration anyway) and just add one server ID per instance to avoid the strong dependency on -h option. Ciao, Michael.

Yeah, replicating cn=config is only viable if all servers work with identical configuration. Making this configuration work would require adding a qualifier to the syncrepl config to restrict which server nodes it activates on. I think it would be worthwhile to add a feature for this, but it doesn't exist at the moment. Feel free to submit an Enhancement request to the ITS.

2. you must explicitly start slapd to -h ldap://ldap1 etc. to really assign the server-ID to a certain replica.

Yes, this works. But in many cases the system's canonical hostname is not the service's hostname. This will be even more true with today's IPv6 setups.