On 10/18/23 07:30, Florence Blanc-Renaud via FreeIPA-users wrote:
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