I have a single master replicating to 2 slaves. The master is Fedora Directory Server v1.0.4 The slaves are 389-DirectoryServer v1.2.10.
This has been working fine.
I tried to replace the single master with the same ds software as the slaves (389-DirectoryServer v1.2.10), but I could not get replication to work.
I'm hoping someone can help me see what I did wrong.
What I did: ----------- 1) deleted the replication agreements from the Fedora ds master. (Not sure this was necessary. Thought it might leave the slave replicas in a state that would more cleanly accept new replication agreements).
2) replaced the fedora ds master with new o.s. running 389-ds v1.2.10. Created new slapd instance, and loaded it with the same schema and data as was used in the fedora ds DIT.
3) created replication agreements (on the new master) with the 2 slaves.
What I see: ----------- a) Immediately, the replication status was: "nsds5replicaLastInitStatus: 3 Replication error acquiring replica: permission denied"
b) On the master, /var/log/dirsrv/slapd-madds1/errors says this: "NSMMReplicationPlugin - agmt="cn=o-ihccom-to-madds2" (madds2:389): Unable to acquire replica: permission denied. The bind dn "uid=replica-manager,cn=config" does not have permission to supply replication updates to the replica. Will retry later."
c) On the slaves, /var/log/dirsrv/slapd-madds2/errors says this: "NSMMReplicationPlugin - conn=34 op=3 replica="dc=example,dc=com": Unable to acquire replica: error: permission denied"
d) The following query on a slave, shows that the bind-dn used by the master is correct: ldapsearch -x -LLL -D 'cn=directory manager' -W -b cn=config -s sub objectclass=nsds5replica yields output like this: dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: nsds5replica objectClass: extensibleObject cn: replica nsDS5ReplicaRoot: dc=example,dc=com nsDS5ReplicaType: 2 nsDS5ReplicaBindDN: uid=replica-manager,cn=config nsDS5Flags: 0 nsDS5ReplicaId: 65535 nsState:: //8AAAAAAADDxzdRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== nsDS5ReplicaName: edb50b02-86af11e2-9dc2a557-8005a77d nsds5ReplicaChangeCount: 0 nsds5replicareapactive: 0
Thanks for any insight you offer.
----- Original Message -----
From: "Jon Detert" jdetert@infinityhealthcare.com To: "General discussion list for the 389 Directory server project." 389-users@lists.fedoraproject.org Sent: Thursday, March 7, 2013 10:37:54 AM Subject: [389-users] Single Master replication : after master o.s. + dirsrv upgrade, replication fails with nsds5replicaLastInitStatus=3
I have a single master replicating to 2 slaves. The master is Fedora Directory Server v1.0.4 The slaves are 389-DirectoryServer v1.2.10.
This has been working fine.
I tried to replace the single master with the same ds software as the slaves (389-DirectoryServer v1.2.10), but I could not get replication to work.
I'm hoping someone can help me see what I did wrong.
Problem solved, thanks to a reply Rich made to another email I sent today (thread: [389-users] nsDS5ReplicaCredentials confusion).
The problem was:
1) I trusted that the 'reversible encryption' value of the nsDS5ReplicaCredentials attribute, that was generated by fedora-ds v1.0.4, would work the same under 389-ds v1.2.10. It does not.
2) I did not know the actual (i.e. clear-text) value of the password for the dn used in the supplier's replication agreement to bind to the consumer. All I had was the non-reversible hash.
3) Even if I reset the password of the bind-dn (on the consumer), I didn't know how to generate the hash that I see in the nsDS5ReplicaCredentials attribute when I query the replication agreement on the supplier.
Rich answered all these problem points in my other post today (thread: [389-users] nsDS5ReplicaCredentials confusion).
Thanks,
Jon
389-users@lists.fedoraproject.org