[OPENDJ-5686] Updating schema fails due to the order of attributeTypes and ObjectClasses in an LDIF file Created: 12/Nov/18  Updated: 08/Nov/19  Resolved: 16/Jan/19

Status: Done
Project: OpenDJ
Component/s: core server
Affects Version/s: 3.5.3, 3.0.0
Fix Version/s: 4.0.0

Type: Bug Priority: Major
Reporter: Julie Evans Assignee: Matthew Swift
Resolution: Duplicate Votes: 0
Labels: release-notes

Attachments: File addSchema.ldif     File deleteSchema.ldif    
Issue Links:
Duplicate
duplicates OPENDJ-3089 Fold server's Schema functionality in... Done
Epic Link: Bugs 7.0
Story Points: 0.5
Dev Assignee: Matthew Swift
Support Ticket IDs:

 Description   

When creating an LDIF file using ldif-diff to compare 99-user.ldif files then using the output file to update schema using ldapmodify the following error occurs:

Processing MODIFY request for cn=schema MODIFY operation failed Result Code: 21 (Invalid Attribute Syntax)

Additional Information: An error occurred while attempting to decode the object class "( examplePerson-oid NAME 'examplePerson' DESC 'Example person' SUP top AUXILIARY MAY ( exampleAttr1 ) )": The definition for the objectclass with OID examplePerson-oid declared that it should include optional attribute "exampleAttr". No attribute type matching this name or OID exists in the server schema

When adding attributeTypes and objectClasses attributes, the attributeTypes must exist before adding the objectClasses that reference them. When deleting schema attributes this is reversed, the objectClasses attribute must be deleted before the attributeTypes that are referenced in the objectClasses attribute.

The server should only check for consistent “linkage” between attributes and objectclasses after making all the changes, before committing them.

 



 Comments   
Comment by Matthew Swift [ 14/Nov/18 ]

This is not a bug in the ldif-diff tool: it's creating a perfectly valid LDAP modify request. As per the LDAP RFCs a modify request should be processed atomically and constraint validation should only be performed once all modifications have been applied. In other words, I think the bug is in the server because it appears to be applying one modification at a time.

Comment by Nicolas Capponi [ 15/Jan/19 ]

I've done the setup for a server and run the command: ldapmodify -p 1389 -D "cn=Directory Manager" -w password -f /path/to/ldifs/addSchema.ldif
I obtain the described error (Invalid Attribute Syntax) for versions 3.0.0 and 3.5.3 but NOT for the other versions, i.e 5.0.0, 5.5.0 and 6.0.0.
Am I testing the correct thing ?

Comment by Matthew Swift [ 16/Jan/19 ]

I agree with you Nicolas Capponi. After looking at org.opends.server.backends.SchemaBackend#replaceEntry0() I am unable to see how this bug can exist in recent versions of DJ. The SchemaBackend processes the schema changes atomically and only checks for consistency once all of the modifications have been applied.

From what I can see the broken behavior described in this issue was fixed when OPENDJ-3089 was resolved in 5.0.

Jules Evans - from what we can tell, this bug is a duplicate of OPENDJ-3089 and does not impact versions 5.0 onward. Therefore, I propose that we close it as a duplicate of OPENDJ-3089 and remove the affects version "6.0" which seems invalid. Do you agree?

Comment by Julie Evans [ 16/Jan/19 ]

Matthew Swift Yes I agree to close it as a duplicate. Thanks guys. Will there be a backport of this to 3.0.0? Ericsson are escalating for a patch.

Comment by Matthew Swift [ 16/Jan/19 ]

There's very little hope of back-porting the fix. AFAIK, the bug was present since the earliest days of OpenDS and was only fixed as a side-effect of very significant internal changes to the server code-base during development of DJ 5.0. In other words, back-porting the changes is not feasible and, if it were possible, would introduce significant risk of regressions. It's safer to upgrade.

Comment by Matthew Swift [ 16/Jan/19 ]

Closing as fixed in 4.0.0 (this was an internal version which corresponds to DJ 5.0.0).

Comment by Matthew Swift [ 07/Nov/19 ]

Moved to closed state because the fixVersion has already been released.

Generated at Mon Nov 30 02:07:56 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.