389-ds-base

Clone
Source Code
GIT

#48799 objectclass values could be dropped on the consumer
Closed: wontfix None Opened 8 years ago by nhosoi.

Closed: wontfix
Reopen Issue

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.

https://tools.ietf.org/html/rfc4512#section-3.3 says this:

"When creating an entry or adding an 'objectClass' value to an entry,
all superclasses of the named classes SHALL be implicitly added as
well if not already present. That is, if the auxiliary class 'x-a'
is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
causes 'x-b' to be implicitly added (if is not already present).
"

In addition, we should check to see what openldap does.

FYI: the entry objectclass customPerson is added by "modify" accepts the attribute types belonging to the, e.g., inetorgperson, person, etc. on the consumer server. It's just missing the objectclass values.

The inconsistency between add and modify is not nice, IMHO.

I checked the build from the master branch. It shares the same symptom.

I assume the fix is the drop of the && !repl_op?

If so, looks good. Ack,

FYI I'm writing the test case for this now.

branch master
commit f5f40a2da9bbcd7613536f3f4ec66bebfe08c802
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
5ddd7b9..016f0f9 master -> master

branch 389-ds-base-1.2.11
commit f5f40a2da9bbcd7613536f3f4ec66bebfe08c802
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
2e30d12..a80b2d8 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

Test case still needs review + ack for commit, but has been run on these commits.

Ack on the attachment 0001-Ticket-48799-Test-cases-for-objectClass-values-being.patch​.

Thanks, William!

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1328936

Hi Noriko and William,

could you please merge the test case as well?

Thanks!

Replying to [comment:10 vashirov]:

Hi Noriko and William,

could you please merge the test case as well?

Thanks!
Oops. Thanks for finding it out, Viktor!

Pushed to master (on behalf of William :)
0f4f838..dcec327 master -> master
commit dcec327

Pushed to 389-ds-base-1.3.4:
c0ad918..85f0212 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 85f0212

Metadata Update from @nhosoi:
- Issue set to the milestone: 1.2.11.33
7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1859

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
3 years ago

Login to comment on this ticket.

Metadata
None
None
None
None
major
ack
Community
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.