Martin Kosek wrote:
On 08/30/2012 02:53 PM, Rob Crittenden wrote:
Martin Kosek wrote:
Current objectclass updates in a form of "replace" update instruction
dependent on exact match of the old object class specification in the
update instruction and the real value in LDAP. However, this approach is
very error prone as object class definition can easily differ as for
example because of unexpected X-ORIGIN value. Such objectclass update
failures may lead to serious malfunctions later.

Add new update instruction type "replaceoc" with the following format:
This update instruction will always replace an objectclass with
specified OID with the new definition.

This works ok. Martin and I had a conversation in IRC about it.

This moves from replacing a specific bit of schema with a new one, in all
cases. I wonder if we should be more conservative and know what we're replacing
in advance.


You are right, I was too harsh when replacing the objectclasses. This would
cause issues when LDAP update would be run on a replica with lower version and
older objectclass definitions.

I came up with an alternative solution and instead of always replacing the
objectclass I rather reverted to old-OC:new-OC style which should be safer.
Now, the LDAP updater always normalizes an objectclass before comparing it
using python-ldap objectclass model. With this approach, objectclasses
differing only in X-ORIGIN or white spaces should match and be updated.



I think this:

+                            for value in replaced_values:
+                                entry_values.remove(old)

Should be:

+                                entry_values.remove(value)

I'm still doing other testing but this is what I've found so far.


Freeipa-devel mailing list

Reply via email to