How can I delete dangling RUVs from IPA CA tree?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Identity Management System

Issue

  • There are still dangling replication update vectors (RUVs) in the LDAP database which lead to those entries in dirsrv error log:
attrlist_replace - attr_replace (nsslapd-referral, ldap://ldap2.domain389/o%3Dipaca) failed.

Resolution

Starting with RHEL-7.3, a new sub-command to ipa-replica-manage is available to clean dangling RUVs from the CA tree:

# ipa-replica-manage clean-dangling-ruv

If you are in a lower version, while the tools ipa-replica-manage can be used to list and clean dangling RUVs from the IPA userRoot database, the tools ipa-csreplica-manage don't have such options available for the ipaca database. The following instructions show, how those RUVs can be identified and deleted with ldapsearch and ldapmodify.

  1. Get list of replicas with CA:
 # ipa-csreplica-manage list
  1. For each replica(here ipa1.example.test) get list of RUVs and its replica ID:

RHEL 7:

 # ldapsearch -x -h ipa1.example.test -D "cn=Directory Manager" -W -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" | grep "nsds50ruv\|nsDS5ReplicaId"

RHEL6:

# ldapsearch -D "cn=Directory Manager" -W -b o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))'  -p 7389 -h localhost

Replica ID looks like:

 nsDS5ReplicaId: 6`

RUV looks like:

nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e7
  1. Find all RUVs which doesn't have existing replica ID.

  2. Run clearuv task for each dangling RUV identified in step 3, here the RUV is 3.

RHEL 7:

# ldapmodify -ZZ -D "cn=directory manager" -W -a
dn: cn=clean 3, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 3
cn: clean 3

RHEL6:

# ldapmodify -ZZ -D "cn=directory manager" -W -a -p 7389 -h localhost
dn: cn=clean 3, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 3
cn: clean 3

Here is a full example:

# ipa-csreplica-manage list
Directory Manager password:

ipa1.example.test: master
ipa2.example.test: master
ipa3.example.test: master

# ldapsearch -ZZ -h ipa1.example.test ...
nsDS5ReplicaId: 6
nsds50ruv: {replicageneration} 56f3e283000000060000
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2
nsds50ruv: {replica 5 ldap://ipa2.example.test:389} 56f3e2
nsds50ruv: {replica 8 ldap://ipa3.example.test:389} 56f3e7

# ldapsearch -ZZ -h ipa2.example.test ...
nsDS5ReplicaId: 5
nsds50ruv: {replicageneration} 56f3e283000000060000
nsds50ruv: {replica 5 ldap://ipa2.example.test:389} 56f3e2
nsds50ruv: {replica 8 ldap://ipa3.example.test:389} 56f3e7
nsds50ruv: {replica 3 ldap://ipa4.example.test:389} 56f3e1
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2

# ldapsearch -ZZ -h ipa3.example.test ...
nsDS5ReplicaId: 8
nsds50ruv: {replicageneration} 56f3e283000000060000
nsds50ruv: {replica 8 ldap://ipa3.example.test:389} 56f3e7
nsds50ruv: {replica 5 ldap://ipa2.example.test:389} 56f3e2
nsds50ruv: {replica 9 ldap://ipa2.example.test:389} 56f3d2
nsds50ruv: {replica 6 ldap://ipa1.example.test:389} 56f3e2

Here the correct replica IDs are 6, 5 and 8. Dangling are 3, 9. So the cleanall ruv task would be run for 3, 9.

Root Cause

In a replicated environment, when you decommission a master without removing all the replication agreements that points to this master, the meta-data is still contained in the other servers.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments