Bug 1623112

Summary:	ipa-replica-install defines nsds5replicabinddngroup before the group contains the DN of the replication manager
Product:	Red Hat Enterprise Linux 7	Reporter:	Florence Blanc-Renaud <frenaud>
Component:	ipa	Assignee:	IPA Maintainers <ipa-maint>
Status:	CLOSED ERRATA	QA Contact:	ipa-qe <ipa-qe>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	7.5	CC:	ndehadra, pvoborni, rcritten, tscherf
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ipa-4.6.4-7.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1623669 (view as bug list)		Environment:
Last Closed:	2018-10-30 11:00:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1623669

Description Florence Blanc-Renaud 2018-08-28 13:43:19 UTC

Cloned from upstream: https://pagure.io/freeipa/issue/7617

### Issue
The issue is related to the way 389-ds manage nsds5replicabinddngroup

When the replica LDAP entry is created, if it contains nsds5replicabinddngroup, then the group is fetched. So if at that time the group does not contains the DN of the replication manager, replication will fail until the group is updated and fetched again.

With current setting (nsDS5ReplicaBindDnGroupCheckInterval=60s) that means that replication will fail during the next 60s of the creation of the replica entry.

The way group is fetched is improved with https://pagure.io/389-ds-base/issue/49818. 
But ipa-replica-install against a master not containing #49818, replication will be delayed by 60s

#### Steps to Reproduce
1. ipa-server-install + ipa-replica-install
Check in master and consumer error logs 

    Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.

#### Actual behavior
replication is delayed by 60 sec

#### Expected behavior
if the group contains the replication manager DN, the first replication session should succeed

#### Version/Release/Distribution
 since 4.5

Comment 2 Florence Blanc-Renaud 2018-08-28 13:46:32 UTC

Upstream ticket:
https://pagure.io/freeipa/issue/7617

Comment 3 Florence Blanc-Renaud 2018-08-28 14:40:10 UTC

Fixed upstream
master:
    811b0fd Tune DS replication settings
    02f4a7a DS replication settings: fix regression with <3.3 master


ipa-4-6:
    6ba653c Tune DS replication settings
    2563f6f DS replication settings: fix regression with <3.3 master

ipa-4-5:
    ec60901 replicainstall: DS SSL replica install pick right certmonger host
    5ef8333 Fix race condition in get_locations_records()
    a9cc862 Tune DS replication settings
    79fe981 Auto-retry failed certmonger requests
    f3dd0cb Wait for client certificates
    f4ee36a DS replication settings: fix regression with <3.3 master

ipa-4-7:
    30443d1 DS replication settings: fix regression with <3.3 master

Comment 7 Nikhil Dehadrai 2018-09-05 11:59:18 UTC

389-ds-base-1.3.8.4-13.el7.x86_64
ipa-server-4.6.4-8.el7.x86_64

Verified the bug on the basis of following observations:
1. Verified that when ipa Master and replica is installed, then "Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later." message is not received on replica server. 


Console:
[root@vm-idm-039 ~]# rpm -q ipa-server
ipa-server-4.6.4-8.el7.x86_64
[root@vm-idm-039 ~]# rpm -q 389-ds-base
389-ds-base-1.3.8.4-13.el7.x86_64

[root@vm-idm-039 ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
[root@vm-idm-039 ~]# tail -1 /var/log/ipareplica-install.log 
2018-09-05T11:37:27Z INFO The ipa-replica-install command was successful

[root@vm-idm-039 ~]# grep -rn "Unable to acquire replica: permission denied" /var/log/ipareplica-install.log

[root@vm-idm-039 ~]# grep -rn "Unable to acquire replica: permission denied" /var/log/
[root@vm-idm-039 ~]# 

Thus on the basis of above observations, marking the status of bug to 'VERIFIED'.

Comment 9 errata-xmlrpc 2018-10-30 11:00:22 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3187