1328936 – objectclass values could be dropped on the consumer

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 1328936 - objectclass values could be dropped on the consumer

Summary: objectclass values could be dropped on the consumer

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

Reported:	2016-04-20 16:09 UTC by Noriko Hosoi
Modified:	2020-09-13 21:42 UTC (History)
CC List:	3 users (show)
Fixed In Version:	389-ds-base-1.3.5.2-1.el7
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2016-11-03 20:41:15 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	389ds 389-ds-base issues 1859	0	None	None	None	2020-09-13 21:42:51 UTC
Red Hat Product Errata	RHSA-2016:2594	0	normal	SHIPPED_LIVE	Moderate: 389-ds-base security, bug fix, and enhancement update	2016-11-03 12:11:08 UTC

Description Noriko Hosoi 2016-04-20 16:09:34 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/48799

Reproducer:
{{{
1- Define a new custom objectclass on both supplier and consumer like:
attributeTypes: ( 10.0.9.2342.19200300.100.1.1 NAME 'customManager'
  EQUALITY distinguishedNameMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  X-ORIGIN 'user defined' )
objectclasses: ( 1.3.6.1.4.1.4843.2.1 NAME 'customPerson' SUP inetorgperson STRUCTURAL MAY (customManager) X-ORIGIN 'user defined' )

2- add a new user test on the supplier:
    dn: cn=Test User,ou=people,dc=example,dc=com
    changetype: add
    loginshell: /bin/bash
    uidnumber: 1111212
    gidnumber: 100
    objectclass: posixAccount
    objectclass: account
    objectclass: top
    uid: testuser
    gecos: Test User
    cn: Test User (testuser)
    homedirectory: /home/testuser
    passwordexpirationtime: 20160710184141Z
    userpassword: *

3- assign customPerson objectclass to testuser:
    dn: cn=Test User,ou=people,dc=example,dc=com
    changetype: modify
    add: objectclass
    objectclass: customPerson
    -
    add: sn
    sn: User
    -
    add: customManager
    customManager: cn=my manager,ou=people,dc=example,dc=com

4- On the supplier, objectclass: inetorgperson/organizationalPerson/person are automaticlally added.  But they are not on the consumer.

Supplier:
# dbscan -f id2entry.db4 -K 14 | egrep -i objectclass
  objectClass;vucsn-57168a6f000000010000: posixAccount
  objectClass;vucsn-57168a6f000000010000: account
  objectClass;vucsn-57168a6f000000010000: top
  objectClass;vucsn-57168b02000000010000: customPerson
  objectClass: inetOrgPerson
  objectClass: organizationalPerson
  objectClass: person

Consumer:
# dbscan -f id2entry.db4 -K 14 | egrep -i objectclass
  objectClass;vucsn-57168a6f000000010000: posixAccount
  objectClass;vucsn-57168a6f000000010000: account
  objectClass;vucsn-57168a6f000000010000: top
  objectClass;vucsn-57168b02000000010000: customPerson
}}}

An application expects to see objectclass values on the consumer to verify the replication was successful.  Since they are not found, the application retries endlessly.

This bug is currently observed on 1.2.11 (in 389-ds-base-1.2.11 branch as well as in 389-ds-base-1.2.11.15-72.el6_7).  But master may share the same issue.  Need to double check.

It is likely a regression introduced by this fix:
https://fedorahosted.org/389/ticket/17

Another note: the unfilled objectclass values is observed only in the modify-add case.  If an entry with objectclass: top and customerPerson is added, the objectclass values in-between are properly added on the supplier as well as on the consumer.

Comment 1 Noriko Hosoi 2016-04-20 16:11:40 UTC

Note: the reproducer is implemented as a CI test: 
 0001-Ticket-48799-Test-cases-for-objectClass-values-being.patch

Comment 3 Punit Kundal 2016-06-23 13:52:21 UTC

DS Version:
389-ds-base-1.3.5.6-1.el7.x86_64
389-ds-base-libs-1.3.5.6-1.el7.x86_64

Steps Performed for the purpose of verfication:
1. Created two standalone DS instances
[root@ds ~]# netstat -ntpl | grep ns-slapd
tcp6       0      0 :::389                  :::*                    LISTEN      8881/ns-slapd      
tcp6       0      0 :::1389                 :::*                    LISTEN      9464/ns-slapd      
 
2. Added custom schema elements to the supplier
[root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: (10.0.9.2342.19200300.100.1.1 NAME 'customManager'
  EQUALITY distinguishedNameMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  X-ORIGIN 'user defined' )
modifying entry "cn=schema"
 
[root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.4843.2.1 NAME 'customPerson' SUP inetorgperson STRUCTURAL MAY (customManager) X-ORIGIN 'user defined' )
modifying entry "cn=schema"

Performed the same steps on the consumer for adding schema elements
 
3. Configured replication between supplier and consumer
Replication Agreement
dn: cn=ExAgr1,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5ReplicationAgreement
cn: ExAgr1
nsDS5ReplicaHost: localhost
nsDS5ReplicaPort: 1389
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaRoot: dc=example,dc=com
description: agreement between supplier and consumer
nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
 RERBNEJDUXdZak14WWpGbE9TMDRNMkZqTTJZNA0KTUMxaVpXWmhNVFkzWlMweE1URXdZMkV4WXdBQ
 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRHJycTRFNVVTOEZPQW
 U3cS9BVVhCTg==}GPzaAogD6dzloXUxYSZLWg==
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20160622101532Z
modifyTimestamp: 20160622155134Z
nsds50ruv: {replicageneration} 576a62c30000002f0000
nsds50ruv: {replica 47 ldap://ds.example.com:389} 576a65f50000002f0000 576a699
 60000002f0000
nsruvReplicaLastModified: {replica 47 ldap://ds.example.com:389} 00000000


4. Added a new user entry on the supplier as below:
[root@ds ~]# ldapadd -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: cn=Test User,ou=people,dc=example,dc=com
objectClass: posixAccount
objectClass: account
objectClass: top
loginshell: /bin/bash
uidnumber: 1111212
gidnumber: 100
uid: testuser
gecos: Test User
cn: Test User (testuser)
homedirectory: /home/testuser
passwordexpirationtime: 20160710184141Z
userpassword: secret123
adding new entry "cn=Test User,ou=people,dc=example,dc=com"
 
5. Performed an ldapsearch
On Supplier:
[root@ds ~]# ldapsearch -xLLL -b 'cn=Test User,ou=people,dc=example,dc=com' -h localhost -p 389
dn: cn=Test User,ou=People,dc=example,dc=com
objectClass: posixAccount
objectClass: account
objectClass: top
loginShell: /bin/bash
uidNumber: 1111212
gidNumber: 100
uid: testuser
gecos: Test User
cn: Test User (testuser)
cn: Test User
homeDirectory: /home/testuser
 
On Consumer:
[root@ds ~]# ldapsearch -xLLL -b 'cn=Test User,ou=people,dc=example,dc=com' -h localhost -p 1389
dn: cn=Test User,ou=People,dc=example,dc=com
objectClass: posixAccount
objectClass: account
objectClass: top
loginShell: /bin/bash
uidNumber: 1111212
gidNumber: 100
uid: testuser
gecos: Test User
cn: Test User (testuser)
cn: Test User
homeDirectory: /home/testuser
 
As can be seen above, the entry has been replicated to the consumer
 
6. Performed modification of the entry on the supplier and added custom objectClass and attribute
to the entry as below:
[root@ds ~]# ldapmodify -x -D 'cn=Directory Manager' -w secret123 -h localhost -p 389
dn: cn=Test User,ou=People,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: customPerson
-
add: sn
sn: User
-
add: customManager
customManager: cn=my manager,ou=people,dc=example,dc=com
modifying entry "cn=Test User,ou=People,dc=example,dc=com"
 
7. Scanned the id2entry database:
On Supplier:
[root@ds ~]# dbscan -f /var/lib/dirsrv/slapd-supplier/db/userRoot/id2entry.db -K 13 | egrep -i objectClass
        objectClass;vucsn-576a67d60000002f0000: posixAccount
        objectClass;vucsn-576a67d60000002f0000: account
        objectClass;vucsn-576a67d60000002f0000: top
        objectClass;vucsn-576a69960000002f0000: customPerson
        objectClass: inetOrgPerson
        objectClass: organizationalPerson
        objectClass: person
 
On Consumer:
[root@ds ~]# dbscan -f /var/lib/dirsrv/slapd-consumer/db/userRoot/id2entry.db -K 13 | egrep -i objectClass
        objectClass;vucsn-576a67d60000002f0000: posixAccount
        objectClass;vucsn-576a67d60000002f0000: account
        objectClass;vucsn-576a67d60000002f0000: top
        objectClass;vucsn-576a69960000002f0000: customPerson
        objectClass: inetOrgPerson
        objectClass: organizationalPerson
        objectClass: person
 
As can be seen above, no objectClass values have been dropped on the consumer

Comment 5 errata-xmlrpc 2016-11-03 20:41:15 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://rhn.redhat.com/errata/RHSA-2016-2594.html

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