aliasedObjectName: ou=foo,dc=test,dc=com
objectClass: top
objectClass: alias
If I add that entry after disabling schema checking, the entry can be added and the result in the directory is this. Note two aliasedObjectName attrs, one is wrong.:
dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com
aliasedObjectName: ou=foo,dc=test,dc=com
aliasedObjectName: "ou=foo,dc=test,dc=com"
objectClass: top
objectClass: alias
I then tried adding this entry again with no aliasedObjectName attribute. This will work also with schema checking on:
dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com
objectClass: top
objectClass: alias
And the result is this, which works even with schema checking on but yields the wrong aliaseObjectName attr (the "" shouldn't be there):
dn: aliasedobjectname="ou=foo,dc=test,dc=com",ou=bar,ou=test,dc=com
aliasedObjectName: "ou=foo,dc=test,dc=com"
objectClass: top
objectClass: alias
For some reason, it's perfectly fine from the directory point of view when you replicate instead of
ldifimport (until you try to import/export to ldif) so I assume there's some difference in how entries are
parsed and added for the two methods there. Don't know if any of this
tells you anything, just thought I should mention my findings.
I'm now searching for a workaround that would allow me to still use replication for the migration step. is there f.ex. a way to make the server normalize either on input or output when doing ldif import/export? can you see a better option than to fall back on ldif processing/converting?. So far the only alternative to ldif processing I see is a script to walk the whole directory and modify the aliasedObjectName after replica initialization is complete at some point and the replication agreement is removed.