see also: #5404

related freeipa-devel thread

what about cleaning of ruvs in the ipaca backend ?

we want to deprecate ipa-csreplica-manage, so we will not enhance it. Should it be part of ipa-replica-mangage or a new command ?

The problem to detect dangling ruvs could be made part of the replication monitoring

This ticket talks about a new sub-command of ipa-replica-manage. It should handle both backends.

That said, long-term goal is issue the clean from API through LDAP -> topology plugin.

Question is whether it is worth to implemented a temporary solution(this) or do it in topo plugin right away.

ok, if it is to be done in ipa-replica-manage this could be a simple extension, not even a new subcommand. I tested list-ruv with a suffix option:

ipa-replica-manage list-ruv
vm-192.abc.idm.lab.eng.brq.redhat.com:389: 4
vm-110.abc.idm.lab.eng.brq.redhat.com:389: 3

ipa-replica-manage list-ruv -p password --suffix o=ipaca
vm-110.abc.idm.lab.eng.brq.redhat.com:389: 5
vm-192.abc.idm.lab.eng.brq.redhat.com:389: 6

one problem is that the ca suffix cannot be read as admin, either we add an aci to allow this or accept that for managing the CA suffix DM is to be used.

This option could be used for clean-ruv as well

To handle it in the topology plugin, the plugin would need to have a way to detect which replicaIDs are still valid and/ or a mechanism to trigger the cleanallruv task. This is done when a master is deleted, but if it has to be done separately for dangling ruv an artificial mod would need to be defined to trigger the plugin.

My (temporary) idea is:

ipa-replica-manage clean-dangling-ruvs

it will

• ask for DM password if not provided
• get list of masters
• connect to each master as DM and get replica ids from cn=replica,cn=$REALM,cn=mapping tree,cn=config and cn=o\3Dipaca,cn=mapping tree,cn=config (if ca is installed on that master)
  • continue if some master is down
• call get_ruv for both $REALM and ipaca suffix to get all RUVs on this master
• compare the list of (replica IDs, hostname) pairs with pairs from RUVs
  • call clean_ruv(with proper suffix) for the ruvs which are not in the first list
  • do not do ^^ for master which are not available atm (to avoid clearing valid ruvs)

The point here is that user would not specify any replica ID.

Question is whether #5396 is a prerequisite for this to be usable - i.e. that it would not hang forever.

Ok, this sounds good, not requiring to pass a replicaID to clean is a nice feature and it will work with any domainevel.
If domainlevel>0 we could enhance the topology pluging to maintain the replicaids in use in the shared tree, like the segments and the discovery phase (your steps 2 and 3) is simplified.

About 5396, I think it would be a nice to have, but not a prerequisite. There might be some cases where cleanallruv does not complete, but this is what we have for the main suffix already.

Not a blocker for 4.3 release.

ipa-4-3:

• abb8252 Listing and cleaning RUV extended for CA suffix
• 4401814 Automatically detect and remove dangling RUVs

master:

• bb78871 Listing and cleaning RUV extended for CA suffix
• c8eabaf Automatically detect and remove dangling RUVs

What is the exact procedure of getting these dangling RUVs? How do we test this?

Procedure to create dangling RUVs
https://bugzilla.redhat.com/show_bug.cgi?id=1212713#c10