Test script and data file
pkitest.tgz

The the attached test script, you will notice that there is a hack in there that takes the first objectClasses value from the list and duplicates it at the end of the list. This is to work around a problem where PerLDAP does a value replace modify for the first value of a multi-valued attribute, but does a value add modify for each of the rest of the values. For online schema updates, we reject replace operations in 389 with err=53. Duplicating the value to the end of the list ensures that the first value does actually get added by retrying it, even though it fails with err=53 the first time. This is related to the PerLDAP update() subroutine, which is buggy.

This workaround is what is broken with 389-ds-base-1.2.10 on RHEL6. The value that is duplicated at the end of the list appears to be added correctly to 389 based on the return value (err=0), yet it never shows up in the schema in 99user.ldif.

I was able to reproduce the issue on rhel 6.2 with the "master" source code base.

As for the error 53, I got these messages when turning on trace function calls:

[16/May/2012:13:58:58 -0400] - => send_ldap_result 53::attributeTypes: Replace is not allowed on the subschema subentry
[16/May/2012:13:59:13 -0400] - => send_ldap_result 53::objectClasses: Replace is not allowed on the subschema subentry

So, the add is changed to a replace. Not sure if that's perldap or DS making the change - probably perldap.

Still investigating...

Although perldap is saying that "dateOfCreate" adds successfully the second time, it never actually hits the DS:

conn=4 op=0 BIND dn="cn=dm" method=128 version=3
conn=4 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=dm"
conn=4 op=1 SRCH base="cn=schema" scope=0 filter="(objectClass=)" attrs=" aci aci"
conn=4 op=1 RESULT err=0 tag=101 nentries=1 etime=0
conn=4 op=2 MOD dn="cn=schema"
conn=4 op=2 RESULT err=53 tag=103 nentries=0 etime=1 --> add dateOfCreate (mod op replace - rejected)
conn=4 op=3 MOD dn="cn=schema"
conn=4 op=3 RESULT err=0 tag=103 nentries=0 etime=1 --> add dateOfModify (mod op add - accepted)
conn=4 op=4 MOD dn="cn=schema"
conn=4 op=4 RESULT err=53 tag=103 nentries=0 etime=1 --> add tokenRecord (mod op replace - rejected)
conn=4 op=5 MOD dn="cn=schema"
conn=4 op=5 RESULT err=0 tag=103 nentries=0 etime=1 --> add tokenActivity (mod op add - accepted)
conn=4 op=6 UNBIND
conn=4 op=6 fd=65 closed - U1

perl version is: v5.10.1
perldap version: perl-Mozilla-LDAP-1.5.3-4.el6.x86_64

Per my testing, it's perldap that is not working correctly.

Still investigating...

Ok, turns out we needed a better "hack" fix in the perl script.

I modified the function:

I've attached the new function (in schema_fix attachment)

The reason the old code didn't work was because there was a duplicate value in the array of attribute values. Perldap must have truncated it, and never sent the second attempt of the first value. This fix just appends a dummy value to the array, which consumes the error 53.

the fixed schema function
schema_fix

Closing as invalid since this is not a 389 bug.

Added initial screened field value.

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/373

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.