Ticket 47676 : Replication of the schema fails 'master branch' -> 1.2.11 or 1.3.1
Bug Description:
Since https://fedorahosted.org/389/ticket/47490 and https://fedorahosted.org/389/ticket/47541 a supplier schema is
pushed to the consumer at the condition that the consumer schema is not a superset of the supplier schema.
With https://fedorahosted.org/389/ticket/47647, the objectclass 'print-uri' has been removed from master.
Starting in 1.3.1, unhashed#user#password pseudo attribute as been removed from the schema.
A consequence is that replication of the schema fails: master->1.2.11 and master->1.3.1
Fix Description:
Replication plugin initialization (multimaster_start) creates the three following entries
dn: cn=replSchema,cn=config
objectClass: top
objectClass: nsSchemaPolicy
cn: replSchema
dn: cn=consumerUpdatePolicy,cn=replSchema,cn=config
objectClass: top
objectClass: nsSchemaPolicy
cn: consumerUpdatePolicy
schemaUpdateObjectclassAccept: printer-uri-oid
schemaUpdateAttributeAccept: 2.16.840.1.113730.3.1.2110
schemaUpdateObjectclassReject: dummy-objectclass-name
schemaUpdateAttributeReject: dummy-attribute-name
dn: cn=supplierUpdatePolicy,cn=replSchema,cn=config
objectClass: top
objectClass: nsSchemaPolicy
cn: supplierUpdatePolicy
schemaUpdateObjectclassAccept: printer-uri-oid
schemaUpdateAttributeAccept: 2.16.840.1.113730.3.1.2110
schemaUpdateObjectclassReject: dummy-objectclass-name
schemaUpdateAttributeReject: dummy-attribute-name
schemaUpdateObjectclassAccept, schemaUpdateAttributeAccept, schemaUpdateObjectclassReject and schemaUpdateAttributeReject
are optional multi-valued attribute.
The values are strings representing objectclass/attribute name or OID.
During a replication session, if the consumer schema needs to be updated (because nsSchemaCSN differs) the checkings are:
On supplier side:
OBJECTCLASSES
For each objectclass OC in the consumer schema:
if it exists in 'cn=supplierUpdatePolicy,cn=replSchema,cn=config'
schemaUpdateObjectclassAccept: <oc_name or oc_oid>
then this OC is "accepted" without checking that
- OC exists in supplier schema
- supplier's OC >= consumer's OC
schemaUpdateObjectclassReject: <oc_name or oc_oid>
then the supplier schema is not pushed (rejected)
If none of these values exists, then it does the "normal" processing to determine if the schema can be updated:
(if Supplier's OC < consumer's OC then schema is not pushed)
ATTRIBUTES
It does the same processing as above for each attribute, looking for values
schemaUpdateAttributeAccept and schemaUpdateAttributeReject
On consumer side:
OBJECTCLASSES
It does the same processing as above for each OC in the supplier schema, checking against
entry 'cn=consumerUpdatePolicy,cn=replSchema,cn=config'
ATTRIBUTES
It does the same processing as above for each AT in the supplier schema, checking against
entry 'cn=consumerUpdatePolicy,cn=replSchema,cn=config'
https://fedorahosted.org/389/ticket/47676
Reviewed by: Rich Megginson (Thanks Rich!)
Platforms tested: F17/F19(jenkins)
Flag Day: no
Doc impact: no