Re: Repair replication

[Mark Reynolds <mareynol@xxxxxxxxxx>]

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:

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users