https://bugzilla.redhat.com/show_bug.cgi?id=612771 https://bugzilla.redhat.com/attachment.cgi?id=432203&action=diff https://bugzilla.redhat.com/attachment.cgi?id=432203&action=edit (In reply to comment #7)
> (From update of attachment 431976 [details]) > An entry may already have an nsUniqueID attribute - in that case, we should use > it. I was hoping we could use an attribute already in the entry for the > renaming - I guess when you're not using replication, the nsUniqueID is not > generated? If so, perhaps we could just use entryid instead of nsuniqueid?
Thanks, Rich! Fixed it. I confirmed nsUniqueId is always assigned regardless of the replication use. Now, upgradednformat utility picks up UUID from the entry and add nsuniqueid=<UUID> to the DN if duplicated DN is found. (The upgrade fails if UUID is not found in the entry, which should not happen.) Since it always uses the existing UUID, we don't have to reindex nsuniqueid. Thus, I removed the following special treatment for nsuniqueid since it is not needed any longer.
> Also, at > https://bugzilla.redhat.com/attachment.cgi?id=431976&action=diff#a/ldap/servers/slapd/back-ldbm/import.c_sec1 > - nsuniqueid will never have a DN value?
Thanks, --noriko
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
