Russ and Mark thank you for your suggestions.
I finally managed to get replication working... After simplifying to just
working on the dual masters A & B and still seeing the same error, a dug
more into something that Rich said previously.
He mentioned that the password (nsDS5ReplicaCredentials) listed in the
replication agreement should be hashed and my master A system was printing
it in plain text in the dse.ldif file. I compared the dse.ldif files from
master A & B and found a typo on A:
dn: cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: DES
nsslapd-pluginPath: /opt/fedora-ds/lib/des-plugin.so
nsslapd-pluginInitfunc: des_init
nsslapd-pluginType: reverpwdstoragescheme
nsslapd-pluginEnabled: on
nsslapd-pluginarg0: nsmultiplexorcredentials
nsslapd-pluginarg1: nsds5eeplicaCredentials
^^^^
nsslapd-pluginId: des-storage-scheme
nsslapd-pluginVersion: 7.1
nsslapd-pluginVendor: Fedora Project
nsslapd-pluginDescription: DES storage scheme plugin
So, steps were:
- stop server master A
- replace typo 'e' with correct 'R' = nsds5ReplicaCredentials
- restart server master A
- reset replication agreement credentials with ldapmodify (password now
hashed in dse.ldif)
Replication began to work in about 5 minutes.
Rich and all, thanks for your help I definitely learned quite a bit.
Hopefully this will help someone who runs into replication issue in the
future.
Thanks,
Herb
On Mon, Apr 23, 2012 at 7:21 AM, Mark Reynolds <mareynol(a)redhat.com> wrote:
Hi Herb,*
*While working on a different replication issue I accidentally reproduced
your issue. My issue was a typo in the password in the repl agreement. I
know you said you passwords were the same, but maybe there is still a
mismatch. Also, if the root dn specified in the agreement doesn 't match
what is setup in the consumer config you'll get the same error. So it's
either the password, or the bind dn.
So I would like you to try two more things:
[1] Make sure the repl bind dn's are set correctly on all the server's
agreements/config: nsDS5ReplicaBindDN
- I saw in your last email that you still had "cn=replication, cn=config"
as your bind dn. It should be "cn=replication manager,cn=config" -
assuming you did create this account.
- Please make sure the bind dn is set correctly for every
agreement/replica, and then try to reinit. Just grep for
"nsDS5ReplicaBindDN" from the dse.ldif on every server. The edits must be
done while the server is stopped or else you will lose your changes.
[2] If [1] doesn't work. Then stop all the servers, and in the dse.ldif,
set all the passwords in plain text for the replication manager, and the
agreements. This needs to be done across the board. Start the servers,
and reinit.
- If this works, you can go back in a reset the password with ldapmodify
to encrypt the passwords.
Hope this helps,
Mark
*
*
On 04/20/2012 03:24 PM, Herb Burnswell wrote:
Unable to acquire replica: permission denied. The bind dn "cn=replication
manager,cn=config" does not have permission to supply replication updates
to the replica. Will retry later.