e35d201 Ticket 47676 : Replication of the schema fails 'master branch' -> 1.2.11 or 1.3.1

Authored and Committed by tbordaz 9 years ago
    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
    
        
file modified
+5 -0
file modified
+296 -8
file modified
+36 -0