1506831 – replicated MODRDN fails breaking replication.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1506831 - replicated MODRDN fails breaking replication.

Summary: replicated MODRDN fails breaking replication.

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	389-ds-base
Sub Component:
Version:	7.4
Hardware:	All
OS:	Linux
Priority:	urgent
Severity:	urgent
Target Milestone:	rc
Target Release:	---
Assignee:	mreynolds
QA Contact:	Viktor Ashirov
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1508978
TreeView+	depends on / blocked

Reported:	2017-10-26 22:31 UTC by German Parente
Modified:	2021-03-11 16:07 UTC (History)
CC List:	5 users (show)
Fixed In Version:	389-ds-base-1.3.7.5-4.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	1508978 (view as bug list)
Environment:
Last Closed:	2018-04-10 14:21:13 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	389ds 389-ds-base issues 2490	0	None	None	None	2020-09-13 22:03:38 UTC
Red Hat Product Errata	RHBA-2018:0811	0	None	None	None	2018-04-10 14:22:03 UTC

Description German Parente 2017-10-26 22:31:25 UTC

Description of problem:


I am logging this bug by request of development team that wanted it open to investigate the logs.

What happened at customer site is:

two nodes in replication, in sync

MODRDN of same rdn (cn=x) from ou=z,dc=com to new superior ou=y,dc=com  in node 02.

In node 01, the MODRDN fails with err=1.

After checking, in node 01:

cn=x,ou=z,dc=com
cn=x,ou=y,dc=com

are both present.

We are not sure from GSS side this is a bug. We just need help to understand how this situation could have happened.

Ludwig, I add you in copy since you have asked to open this bug.

Feel free to close it if it's not a bug and a root cause can be explained.

Thanks a lot.

German.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 20 Amita Sharma 2017-12-11 07:50:51 UTC

389-ds-base-1.3.7.5-10.el7.x86_64

1. Add test entries
[root@vm-idm-003 export]# ldapadd -x -h localhost -p 30100 -D "cn=directory manager" -w Secret123 -f data.ldif
adding new entry "ou=A,dc=example,dc=com"

adding new entry "ou=B,dc=example,dc=com"

adding new entry "ou=C,dc=example,dc=com"

adding new entry "uid=test_A,ou=A,dc=example,dc=com"

adding new entry "uid=test_B,ou=B,dc=example,dc=com"

2. Do modrdn on M1 and M2 one by one

On M1, move test user from OU A -> C 
=====================================
/usr/lib64/dirsrv/slapd-M2/stop-slapd
[root@vm-idm-003 export]# ldapmodify -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF
> dn: uid=test_A,ou=A,dc=example,dc=com
> changetype: modrdn
> newrdn: uid=test_A
> deleteoldrdn: 1
> newsuperior: ou=C,dc=example,dc=com
> EOF
modifying rdn of entry "uid=test_A,ou=A,dc=example,dc=com"

On M2, move test user from OU B -> C 
=====================================
[root@vm-idm-003 export]# /usr/lib64/dirsrv/slapd-M1/stop-slapd 
[root@vm-idm-003 export]# /usr/lib64/dirsrv/slapd-M2/start-slapd 
[root@vm-idm-003 export]# ldapmodify -x -h localhost -p 30102 -D "cn=Directory Manager" -w Secret123 << EOF
> dn: uid=test_B,ou=B,dc=example,dc=com
> changetype: modrdn
> newrdn: uid=test_B
> deleteoldrdn: 1
> newsuperior: ou=C,dc=example,dc=com
> EOF
modifying rdn of entry "uid=test_B,ou=B,dc=example,dc=com"

[root@vm-idm-003 export]# /usr/lib64/dirsrv/slapd-M1/start-slapd

3. Check ou=C on M1 and M2 ->
[root@vm-idm-003 export]# ldapsearch -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 -b "ou=C,dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <ou=C,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# C, example.com
dn: ou=C,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: C
description: C

# test_A, C, example.com
dn: uid=test_A,ou=C,dc=example,dc=com
uid: test_A
cn: test_A
sn: Chassin
givenName: Peter
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: A
mail: test_A
telephoneNumber: +1 408 555 2816
facsimileTelephoneNumber: +1 408 555 3372
roomNumber: 4524
userPassword:: e1NTSEE1MTJ9TnBMYWExc2J6OGtxNnJiK1ZQMkY4UzlPQmxyS3pRUFNsMTROL21
 tVktIV0ttNUhsUUdpQm9wSkhoaVJBR3pITjVGTmVDenQrV2FLblBFeUYrRzFIbVpzUHlsa3pydWlq

# test_B, C, example.com
dn: uid=test_B,ou=C,dc=example,dc=com
uid: test_B
cn: test_B
sn: Chassin
givenName: Peter
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: B
mail: test_B
telephoneNumber: +1 408 555 2816
facsimileTelephoneNumber: +1 408 555 3372
roomNumber: 4524
userPassword:: e1NTSEE1MTJ9OHh1bVNGWTBlb2dpdFVTL2hBTGE2WWlBVnMzSTV5Si9vaW94SzR
 SWnRlclZVYytrclZsRVcvbEV3dzhFamVVdnREUXN5YVNaTGxxQzRKdTgzbjRZbVpXalNQc3p3YU9y

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3
[root@vm-idm-003 export]# ldapsearch -x -h localhost -p 30102 -D "cn=Directory Manager" -w Secret123 -b "ou=C,dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <ou=C,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# C, example.com
dn: ou=C,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: C
description: C

# test_A, C, example.com
dn: uid=test_A,ou=C,dc=example,dc=com
uid: test_A
cn: test_A
sn: Chassin
givenName: Peter
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: A
mail: test_A
telephoneNumber: +1 408 555 2816
facsimileTelephoneNumber: +1 408 555 3372
roomNumber: 4524
userPassword:: e1NTSEE1MTJ9TnBMYWExc2J6OGtxNnJiK1ZQMkY4UzlPQmxyS3pRUFNsMTROL21
 tVktIV0ttNUhsUUdpQm9wSkhoaVJBR3pITjVGTmVDenQrV2FLblBFeUYrRzFIbVpzUHlsa3pydWlq

# test_B, C, example.com
dn: uid=test_B,ou=C,dc=example,dc=com
uid: test_B
cn: test_B
sn: Chassin
givenName: Peter
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: B
mail: test_B
telephoneNumber: +1 408 555 2816
facsimileTelephoneNumber: +1 408 555 3372
roomNumber: 4524
userPassword:: e1NTSEE1MTJ9OHh1bVNGWTBlb2dpdFVTL2hBTGE2WWlBVnMzSTV5Si9vaW94SzR
 SWnRlclZVYytrclZsRVcvbEV3dzhFamVVdnREUXN5YVNaTGxxQzRKdTgzbjRZbVpXalNQc3p3YU9y

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3
[root@vm-idm-003 export]#

Hence Verified.

Comment 21 Amita Sharma 2017-12-11 09:42:23 UTC

Tested with latest build and with same uid this time ->

ldapadd -x -h localhost -p 30100 -D "cn=directory manager" -w Secret123 << EOF
dn: uid=test1,ou=A,dc=example,dc=com
cn: test
sn: Chassin
givenName: Peter
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: A
uid: test1
mail: test
telephoneNumber: +1 408 555 2816
facsimileTelephoneNumber: +1 408 555 3372
roomNumber: 4524
userPassword:: YmFyYml0YWw=

ldapadd -x -h localhost -p 30102 -D "cn=directory manager" -w Secret123 << EOF
dn: uid=test1,ou=B,dc=example,dc=com
cn: test
sn: Chassin
givenName: Peter
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: A
uid: test1
mail: test
telephoneNumber: +1 408 555 2816
facsimileTelephoneNumber: +1 408 555 3372
roomNumber: 4524
userPassword:: YmFyYml0YWw=

/usr/lib64/dirsrv/slapd-M1/stop-slapd
ldapmodify -x -h localhost -p 30102 -D "cn=Directory Manager" -w Secret123 << EOF
dn: uid=test1,ou=B,dc=example,dc=com
changetype: modrdn
newrdn: uid=test1
deleteoldrdn: 1
newsuperior: ou=C,dc=example,dc=com
EOF

/usr/lib64/dirsrv/slapd-M2/stop-slapd
/usr/lib64/dirsrv/slapd-M1/start-slapd
ldapmodify -x -h localhost -p 30100 -D "cn=Directory Manager" -w Secret123 << EOF
dn: uid=test1,ou=A,dc=example,dc=com
changetype: modrdn
newrdn: uid=test1
deleteoldrdn: 1
newsuperior: ou=C,dc=example,dc=com
EOF

Works fine.

Comment 24 errata-xmlrpc 2018-04-10 14:21:13 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:0811

Note You need to log in before you can comment on or make changes to this bug.