If schema looks like this on disk (empty DESC): objectClasses: ( 2.5.6.0 NAME 'top' DESC '' ABSTRACT MUST objectClass X-ORIGIN ' RFC 2256' ) It looks like this when searched (no DESC keyword): objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 2256' ) This causes a problem during schema replication: 1) When schema is pushed to a consumer during replication it uses a MOD-REPLACE operation where each of the master's schema definitions is a value, including standard its schema. 2) On the consumer the schema replace operation callback modify_schema_dse() calls on schema_replace_objectclasses() or schema_replace_attributes(). These will parse the schema definition from each MOD value into objinfo or asyntaxinfo structs. 3) Then the consumer looks through existing in-memory definitions to see if any schema exists with the same OID. Lots of the incoming schema definitions will have collisions since both master and consumer should have the same standard schema files. 4) For each collision, further checking is performed using oc_equal() or attr_syntax_equal() to see if they really are identical. If they are truly identical, which most of them will be, then we throw that new MOD value out. If they don't compare equal then the incoming schema definition will be added on the consumer. This would be OK in some cases, it seems we have a half-baked feature where we can redefine standard schema over the wire. 5) However, we get an unexpected result here if the DESC is empty; they don't compare equal because the incoming schema definitions DESC is NULL and the existing schema definitions DESC is "". We end up with duplicate definitions, one in standard schema file and one in user schema file, where the only difference is that one has empty DESC, and the other has a missing DESC and is marked user-defined (all incoming schema definitions get marked user-defined).
To reproduce: - Setup 2 DS instances and configure them for replication. - Add a new custom attribute definition to the first master over LDAP. - Add a user entry to the first master (no need to use new schema). At this point, the 99user.ldif file on the first master should only contain your new attribute definition. The 99user.ldif file on the second master will contain this new attribute definition as well, but it also contain a number of other default schema definitions having to do with e-mail related objectclasses/attributes.
Created attachment 325750 [details] CVS Diffs The fix is to ensure that we list an empty DESC element in the LDAP entry representation of the schema when searching for it if that is the way it is defined on disk.
Checked into ldapserver (HEAD). Thanks to Noriko for her review! Checking in ldap/servers/slapd/schema.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/schema.c,v <-- schema.c new revision: 1.18; previous revision: 1.17 done
If I am correct in interpreting this bug: I should see an empty DESC element in the LDAP entry when searching the schema - I don't see this: attributeTypes: ( mytestattribute-oid NAME 'mytestattribute' SYNTAX 1.3.6.1.4 .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) 99user.ldif: attributeTypes: ( mytestattribute-oid NAME 'mytestattribute' SYNTAX 1.3.6.1.4 .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) nsSchemaCSN: 49bfae6a000000000000 Both replicas are the same. Is this correct?
(In reply to comment #4) > If I am correct in interpreting this bug: I should see an empty DESC element > in the LDAP entry when searching the schema - I don't see this: > > attributeTypes: ( mytestattribute-oid NAME 'mytestattribute' SYNTAX 1.3.6.1.4 > .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) > > 99user.ldif: > > attributeTypes: ( mytestattribute-oid NAME 'mytestattribute' SYNTAX 1.3.6.1.4 > .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) > nsSchemaCSN: 49bfae6a000000000000 > > Both replicas are the same. > > Is this correct? Yes, this looks correct as long as no other standard schema magically appeared in either 99user.ldif. The problem was that some standard schema had empty descriptions, which would cause those definitions to get replicated into the other masters 99user.ldif.
verified RHEL 5 <--> RHEL 4 DS 8.1
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html