Bug 1328936

Summary: objectclass values could be dropped on the consumer
Product: Red Hat Enterprise Linux 7 Reporter: Noriko Hosoi <nhosoi>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: nkinder, pkundal, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.5.2-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 20:41:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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