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.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
04-23-2012, 05:06 PM
Herb Burnswell
Repair replication
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-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@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.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
04-23-2012, 05:19 PM
Mark Reynolds
Repair replication
Glad you got it working Herb!
Looks like we need to improve some replication logging.
Cheers,
Mark
On 04/23/2012 01:06 PM, Herb Burnswell wrote:
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:
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@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.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Repair replication
