Need to update the entryUUID attribute

[muralicbe1983]

We have setup OpenDJ v5.0.1 in our environment. As part of migration from our previous Forgerock directory services v7.3.5 we have done the export-ldif and imported in OpenDJ. while exporting we excluded this entryUUID attribute.
Now, after we migrated we have one application which is connecting now to OpenDJ looks for entryUUID and nsuniqueID attributes values which already stored in their Db. as checking the values got mismatch and their connectivity fails.
when we checked in OpenDJ vs FRDS there are 2 groups where these entryUUID and nsuniqueID values are not identitical. Now we need to set the same entryUUID in OpenDJ.
As both these entryUUID and nsuniqueID are set as NO-USER-MODIFICATION at schema level. we need to understand how we can set the nsuniqueID values to the entryUUID and it also shouldn't impact our replication topology.
Need inputs on how we can update the entryUUID value.
we have dedicated replication servers with user stores.

[vharseko]

Hi @muralicbe1983,

Why the values differ. When an entry arrives through import-ldif without an entryUUID, OpenDJ does not keep the old one: the EntryUUID plugin derives a new UUID from the entry's normalized DN. So excluding entryUUID from the export gave every imported entry a new UUID, not just those two groups — the two groups are simply the entries whose UUIDs your application had stored. If the application stores UUIDs of other entries as well, expect the same mismatch there.

nsUniqueId is a plain stored operational attribute in OpenDJ (from the Sun DS schema); nothing on the server generates or derives it, so it holds whatever the LDIF contained.

How to set them. OpenDJ has a replication repair request control, OID 1.3.6.1.4.1.26027.1.5.2 (it is in the supportedControl list of the root DSE), which is meant precisely for this: with it, an administrator can write NO-USER-MODIFICATION attributes such as entryUUID, and the change is applied locally only — it is not sent to the replication servers, no CSN is generated and ds-sync-hist is not touched. Run it as cn=Directory Manager, and send the control non-critical (the default for -J <oid>):

ldapmodify -h <ds-host> -p 1389 -D "cn=Directory Manager" -w <password> \
  -J 1.3.6.1.4.1.26027.1.5.2 <<EOF
dn: cn=group1,ou=groups,dc=example,dc=com
changetype: modify
replace: entryUUID
entryUUID: <value from FRDS>
-
replace: nsUniqueId
nsUniqueId: <value from FRDS>
EOF

Because the change is deliberately not replicated, run the same modification against every DS replica (the dedicated replication servers hold no entries and need nothing). Do it while nothing else writes to those two groups, then verify on each replica:

ldapsearch -h <ds-host> -p 1389 -D "cn=Directory Manager" -w <password> \
  -b "cn=group1,ou=groups,dc=example,dc=com" -s base "(objectClass=*)" entryUUID nsUniqueId

Once all replicas carry the same values, the topology stays consistent: later changes to these groups replicate as usual (replication resolves entries by DN, and the messages carry the new UUID), the stored generation id is unaffected, and no re-initialization is needed. The only thing to avoid is fixing some replicas and not others — an initialize from an unfixed replica would bring the old UUIDs back.

This is verified on the current code with a replicated suffix: without the control the modify is refused with CONSTRAINT_VIOLATION; with it the entry gets the new entryUUID/nsUniqueId, nothing reaches the replication server, and subsequent ordinary changes to the entry are replicated normally.

Alternatives.

• The heavy option is export-ldif on one replica → edit the two entries in the LDIF → import-ldif → dsreplication initialize-all from that replica. It works but re-initializes the whole topology for two entries. On 5.0.1 do not use import-ldif --includeBranch for this: that release replaced the rest of the backend on a partial import (Partial import-ldif with --includeBranch/--excludeBranch destroys all entries outside the imported scope #692, fixed in 5.1.2).
• Releases ≥ 5.0.3 also accept the Relax Rules control (-J relaxrules, needs the bypass-acl privilege). It is not in 5.0.1, and on a replicated suffix it is the worse tool: the change is likewise local-only, but the replication layer additionally logs a spurious "Internal Error: Operation ... was not found in pending list". Stick with the repair control for replicated data.