Bug 1598159

Summary: If a replica is created with a bindDNGroup, this group is taken into account only after bindDNGroupCheckInterval seconds
Product: Red Hat Enterprise Linux 7 Reporter: German Parente <gparente>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED DUPLICATE QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.7-AltCC: msauton, nkinder, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-07-09 09:37:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description German Parente 2018-07-04 13:37:33 UTC 
Description of problem:

this is RHEL7 bug from upstream 

https://pagure.io/389-ds-base/issue/49818

Discussion in this upstream bug.

Issue Description

When a replica is created, the time of the last_group_check is set at the current time.
So if the a replica contains a nsds5replicabinddngroup, this group will only be uploaded after a delay of nsDS5ReplicaBindDnGroupCheckInterval.

So in the period [replica_creation, replica_creation+nsDS5ReplicaBindDnGroupCheckInterval] any incoming replication connections, within will fail with NSDS50_REPL_PERMISSION_DENIED , even if the group actually contains the bound DN.

On the supplier side we can see message like

[29/Jun/2018:17:21:58.943439172 +0200] - ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=meTo<server_fqdn>" (<server>:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.


Version-Release number of selected component (if applicable): 1.3.7.5-24.el7_5
Comment 2 Viktor Ashirov 2018-07-09 09:37:33 UTC 

*** This bug has been marked as a duplicate of bug 1598478 ***