Hi,

this guide explains the possible strategies for disaster recovery: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/preparing_for_disaster_recovery_with_identity_management/index

And that one how to recover: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_disaster_recovery_with_identity_management/index

Hope this helps,

flo

Thanks Flo!

Fundamentally freeipa is having a tension in that restoration from system loss is almost never 'a committee or team  effort' but a one person task--- but freeipa now has such richness that few people have the bandwidth to know all the necessary details for each of the distinct complex subdomains freeipa integrates.   A goal yet to be attained is a freeipa 'best practice' advice that includes all the details necessary to restore prior functionality ( snapshot the vm?  ipa-backup? the CA thing? Kasp.db?  Subdomain account number ranges on replicas?  Does promoting a replica fix the SOA record?  Is when 'a database that's too old' a testable fact or like when your coffee temp is just right? ) .  Freeipa ought to have within itself such maps as necessary to itself comprehend the intended role of the system being restored then maneuver and marshal such file changes 'from what it used to be' to 'what it needs to be' to make the system fill its intended role -- without requiring the system-restore person to be expert in each of freeipa's 'deep dive expertise file areas'.

The rest of this post is detail on the above, and probably only interesting for few.

In general all the above advice flo linked to includes most, but not all required to actually accomplish restoration of the functional experience prior to the loss.  Perhaps the advice should be qualified to apply only when the supplemental packages to do with trust and dns are not in use.   You might consider advising folks to use ipa-healthcheck for the purpose of deciding  'how bad the current situation is' on this or that system.  Too is missing the advice relating to version management among 'masters' and 'replicas' (the order in which upgrades get installed among systems) and whether backups made by 'the last one' remain usable by 'the next one'.

Notice that the detail in the first link provided there makes the blanket statement affirming it is possible to replace a lost server by creating a new replica.  However, did the author take responsibility for all of freeipa's parts when that was written?  For example if the server holding the file kasp.db fails, does that statement yet apply?  Is there a comprehensive list of 'files that are exceptions to the rule' maintained by anyone (sub account number ranges on replicas)?

The next paragraph mentions VM snapshots, but leaves it to the reader to guess when  'a too outdated database' (4.2 sec 6) is or isn't the case.  Too, does not mention that's not an answer if replication is active (timing issues, the documentation is missing about whether and when to walk users through the 're-init' Rob mentioned was required upstream).  Might freeipa's replication setup itself notice when 'systemctl stop sssd;sss_cache -e;systemctl start sssd' is necessary and do that itself?

The last paragraph mentions idM backups, detailed in section 5, which too I think might require a list of important files not backed up, and might too include Rob's advise that such is only useful when 'everything has burned to the ground and a fresh install on all systems is the next step'.

Section 3.2 might make more clear freeipa does not just have two states, 'master' and the term rhel uses 'regular replica' relevant to integrity, but at least six major variants relevant to integrity:   replica without CA and not dnssec master,  replica with ca but not dnssec master, etc. .. and 'master with ca and dnssec db', etc.  It's likely this list may double in length in the case of KRA usage.  And potentially need to be entirely revised in light of sub-domain account number range allocation.  Also the freeipa instance mentioned in SOA records has a status of its own that needs thought in the 'promoting replica to master' advice.

Does the advice of 'hidden replica' saving the day cover such files on the same list as kasp.db?  If it's a manual step required as presently documented then ....?

Last: As freeipa is itself in the 'policy' services sector,   is not what ansible provides something the internal maps freeipa maintains a better place to capture and deploy that knowledge?

Thanks all!

Harry Coin