#5411 [RFE] ipa-replica-manage: automatically clean dangling RUVs
Closed: Fixed None Opened 6 years ago by pvoborni.

ipa-replica-manage should be extended to automatically clean dangling RUVs so that errors caused by calls of clean-ruv are mitigated, e.g., in new sub-command.

  1. if master entry does not exists, clean all RUVs associated with this hostname for each suffices.
  2. if master entry exist, figure out what are correct and dangling RUVs, clean the dangling. It might require to be run it on the master.

Fixing this might made parts of #4987 not needed.

Additional considerations:

  • support aborting the task
  • support listing of RUVs from all suffices

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?

Metadata Update from @pvoborni:
- Issue assigned to stlaz
- Issue set to the milestone: FreeIPA 4.3.1

4 years ago

Login to comment on this ticket.

Metadata