Bug 1623935

Summary:	upgrade of 389-ds-base could remove replication agreements.
Product:	Red Hat Enterprise Linux 7	Reporter:	German Parente <gparente>
Component:	389-ds-base	Assignee:	German Parente <gparente>
Status:	CLOSED ERRATA	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	7.5	CC:	aadhikar, cpelland, mreynolds, nkinder, pasik, rmeggins, spichugi, tbordaz, vashirov
Target Milestone:	rc
Target Release:	7.7
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.9.1-4.el7	Doc Type:	If docs needed, set a value
Doc Text:	Cause: The upgrade script that rebuild the dse.ldif ignore entries starting with 'cn=->...' Consequence: if an replication agreement is named such a way 'cn=->...' it is removed and there is no more replication from the upgrade host to the consumer. Fix: By default if mozldap fails to normalize an entry DN, keep the entry in the dse.ldif Result: replication agreement starting with 'cn=->..' remain in the dse.ldif	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-06 12:58:42 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-08-30 13:38:12 UTC

Description of problem:

when a replication agreement starts with "cn=->...", the upgrade is removing the entry.

I have checked upgrade from  1.3.6.1-26.el7_4 to 1.3.7.5-25.el7_5

I don't see yet what is removing the agremeent. It could be 

setup-ds.pl -u

but I have not seen yet the root cause.

Still checking.



Version-Release number of selected component (if applicable):  389-ds-base-1.3.7.5-25.el7_5



How reproducible: easily reproducible.

Comment 2 mreynolds 2018-09-13 15:37:40 UTC

Upstream ticket:
https://pagure.io/389-ds-base/issue/49946

Comment 5 Akshay Adhikari 2019-03-28 09:44:03 UTC

Build Tested on: 389-ds-base-1.3.9.1-3.el7.x86_64

Steps:

1) To perform an upgrade be on the older rpms.

[root@qeos-5 upstream]# rpm -qa | grep 389
389-ds-base-debuginfo-1.3.8.4-23.el7_6.x86_64
389-ds-base-libs-1.3.8.4-23.el7_6.x86_64
389-ds-base-snmp-1.3.8.4-23.el7_6.x86_64
389-ds-base-1.3.8.4-23.el7_6.x86_64

2) Create a working replication and search for the agreement.

[root@qeos-5 upstream]# ldapsearch -D "cn=Directory Manager" -p 39001 -h `hostname` -b "cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" -w password

dn: cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: 002
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaBindDN: cn=qeos-5.lab.eng.rdu2.redhat.com:63701,ou=Services,dc=exa
 mple,dc=com
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaTimeout: 5
description: 002
nsDS5ReplicaHost: qeos-5.lab.eng.rdu2.redhat.com
nsDS5ReplicaPort: 39002
nsDS5ReplicaCredentials:: e0FFUy1UVWhOUjBOVGNVZFRTV0l6UkZGRlJrUlVRbTFOUlZWSFEx
 TnhSMU5KWWpORVVVVkdSRVJCTkVKRFVtdGFWRlY1V2xSc2JWbDVNV3RPUkdoclRUSkpkdzBLVGxNe

3) Perform an upgrade to the latest packages.

[root@qeos-5 upstream]# yum update 389-ds-base*
  
[root@qeos-5 upstream]# rpm -qa | grep 389
389-ds-base-debuginfo-1.3.9.1-3.el7.x86_64
389-ds-base-libs-1.3.9.1-3.el7.x86_64
389-ds-base-snmp-1.3.9.1-3.el7.x86_64
389-ds-base-1.3.9.1-3.el7.x86_64

4) Try to search for the agreement again.

[root@qeos-5 upstream]# ldapsearch -D "cn=Directory Manager" -p 39001 -h `hostname` -b "cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" -w password
# extended LDIF
#
# LDAPv3
# base <cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

[root@qeos-5 upstream]# ldapsearch -D "cn=Directory Manager" -p 39001 -h `hostname` -b "cn=-\3E002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" -w password
# extended LDIF
#
# LDAPv3
# base <cn=-\3E002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

Observations:

1) The agreement is deleted even without running setup-ds.pl -u

2) Patch is not back-ported, file: /usr/lib64/dirsrv/perl/FileConn.pm does'nt have the changes.


Marking as failedQA.

Comment 6 Akshay Adhikari 2019-04-04 05:18:53 UTC

Build Tested on: 389-ds-base-1.3.9.1-4.el7.x86_64

Steps:

1) To perform an upgrade be on the older rpms.

[root@host-8-241-102 suites]# rpm -qa | grep 389
389-ds-base-1.3.8.4-23.el7_6.x86_64
389-ds-base-libs-1.3.8.4-23.el7_6.x86_64
389-ds-base-snmp-1.3.8.4-23.el7_6.x86_64
389-ds-base-debuginfo-1.3.8.4-23.el7_6.x86_64

2) Create a working replication and search for the agreement.

[root@host-8-241-102 suites]# ldapsearch -D "cn=Directory Manager" -p 39001 -h `hostname` -b "cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" -w password
dn: cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: 002
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaBindDN: cn=host-8-241-102.host.centralci.eng.rdu2.redhat.com:63701
 ,ou=Services,dc=example,dc=com
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaTimeout: 5
description: 002
nsDS5ReplicaHost: host-8-241-102.host.centralci.eng.rdu2.redhat.com
nsDS5ReplicaPort: 39002
nsDS5ReplicaCredentials:: e0FFUy1UVWhOUjBOVGNVZFRTV0l6UkZGRlJrUlVRbTFOUlZWSFEx

3) Perform an upgrade to the latest packages.

[root@host-8-241-102 suites]# yum update 389-ds-base

4) Run the setup-ds.pl -u command to upgrade the instances.

[root@host-8-241-102 suites]# setup-ds.pl -u

5) Restart the instances if upgraded in Online mode.

6) Search for the replication agreement again.

[root@host-8-241-102 suites]# ldapsearch -D "cn=Directory Manager" -p 39001 -h `hostname` -b "cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config" -w password
dn: cn=->002,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: 002
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaBindDN: cn=host-8-241-102.host.centralci.eng.rdu2.redhat.com:63701
 ,ou=Services,dc=example,dc=com
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaTimeout: 5
description: 002
nsDS5ReplicaHost: host-8-241-102.host.centralci.eng.rdu2.redhat.com
nsDS5ReplicaPort: 39002
nsDS5ReplicaCredentials:: e0FFUy1UVWhOUjBOVGNVZFRTV0l6UkZGRlJrUlVRbTFOUlZWSFEx

Agreement is there even after the upgrade, Marking it as VERIFIED.

Comment 8 errata-xmlrpc 2019-08-06 12:58:42 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-2019:2152