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
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-20 16:09 UTC by Noriko Hosoi
Modified: 2016-11-03 20:41 UTC (History)
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:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2594 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.