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.
git patch file (master) 0001-Ticket-48799-objectclass-values-could-be-dropped-on-.patch
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.
attachment 0001-Ticket-48799-Test-cases-for-objectClass-values-being.patch
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!
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
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Log in to comment on this ticket.