I have two issues.<br><br>1. Multi-master replication does not seem to work reliably for me, changes on master1 often do not get replicated to master2 or vice versa.<br><br>One thing I think is a bit weird is that I have to use &quot;mirrormode on&quot; but reading the documentation mirrormode is not really multi-master, its master w/ failover basically.  All writes should go to one master but I want true multi-master where writes can go to either master at any time.<br>
<br>If I remove mirrormode on I get &quot;unwilling to perform&quot; or update referrals when trying to write to my masters.  Should I be using mirrormode for multi-master replication?<br><br>2. I am not sure my overlays are ordered in the best way and wonder if this misordering is a part of the replication problems I am seeing.<br>
<br>Can anyone offer any suggestions as to what I might have wrong for multi-master replication or for the proper stacking order of my overlays?<br><br>I am using openldap 2.4.11 and I am configuring everything with slapd.conf.<br>
<br>I am trying to update to 2.4.16 but I need a reliable RPM for it.  It is company policy that the build tools do not go on production servers so I must find an RPM or build an RPM on our build box.<br><br>--- Begin master1 slapd.conf ---<br>
...globals, schema and such...<br><br>password-hash   {SSHA}<br><br>ServerID 1<br><br># access.conf contains all access statements which get rsynced<br># to all master and slave ldap servers<br>include /etc/openldap/access.conf<br>
<br>authz-policy both<br>sizelimit unlimited<br><br>database        bdb<br>suffix          &quot;dc=example,dc=com&quot;<br>rootdn          &quot;cn=Manager,dc=example,dc=com&quot;<br>rootpw          secret<br>directory       /var/lib/ldap<br>
<br>index objectClass                       eq,pres<br>index ou,cn,mail,surname,givenname      eq,pres,sub<br>index uidNumber,gidNumber,loginShell    eq,pres<br>index uid                               eq,pres,sub<br>index nisMapName,nisMapEntry            eq,pres,sub<br>
index member,uniqueMember,memberOf      eq,pres<br>index entryCSN,entryUUID                eq<br><br>overlay accesslog<br>logdb cn=log<br>logops writes session<br>logpurge 7+00:00 1+00:00<br><br>overlay ppolicy<br>ppolicy_default    cn=ppolicy_default,ou=policies,dc=example,dc=com<br>
ppolicy_use_lockout true<br><br>syncrepl rid=001<br>        provider=ldap://master2/<br>        bindmethod=simple<br>        binddn=&quot;cn=replicator,dc=example,dc=com&quot;<br>        credentials=secret<br>        searchbase=&quot;dc=example,dc=com&quot;<br>
        schemachecking=off<br>        type=refreshAndPersist<br>        starttls=yes<br>        tls_reqcert=never<br>        retry=&quot;60 5 600 +&quot;<br><br>overlay syncprov<br>syncprov-checkpoint 100 10<br><br>mirrormode on<br>
<br>overlay unique<br>unique_uri &quot;ldap:///o=*,dc=example,dc=com?uid?sub?(objectClass=posixAccount)&quot;<br>unique_uri &quot;ldap:///o=*,dc=example,dc=com?uidNumber?sub?(objectClass=posixAccount)&quot;<br>unique_uri &quot;ldap:///o=*,dc=example,dc=com?cn?sub?(objectClass=posixGroup)&quot;<br>
<br>overlay dynlist<br>dynlist-attrset posixGroup memberURL memberUid:uid<br><br>overlay memberof<br>memberof-refint TRUE<br>memberof-dangling error<br>--- End master1 slapd.conf ---<br><br>Master2 slapd.conf is identical except for being ServerID 2 and its syncrepl provider is master1.<br>