Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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

Summary:	replicated MODRDN fails breaking replication.
Product:	Red Hat Enterprise Linux 7	Reporter:	German Parente <gparente>
Component:	389-ds-base	Assignee:	mreynolds
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	7.4	CC:	amsharma, lkrispen, msauton, nkinder, rmeggins
Target Milestone:	rc	Keywords:	ZStream
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.3.7.5-4.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1508978 (view as bug list)		Environment:
Last Closed:	2018-04-10 14:21:13 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:
Bug Depends On:
Bug Blocks:	1508978

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