Failures have been seen during non-CA replica installation, frequently when certmonger is trying to retrieve certificates, getting CA_REJECTED:
2022-11-22T14:30:11Z DEBUG Cert request 20221122143010 failed: CA_REJECTED (Server at https://ipa.example.test/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)).)
The working assumption is that there is no affinity during installation so it is a race between the installer and replication.
At least one user in this situation was able to successfully install by doing a client promotion installation with:
These steps are not always successful but it they may be part of an eventual solution.
I have confirmed that modifying the settings prior to install are overwritten during the installation resulting in a correct configuration.
Metadata Update from @rcritten: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=2149344
Metadata Update from @rcritten: - Issue assigned to rcritten
A question is: do we automatically switch to a server that provides the new service (CA or KRA) or fail?
My feeling is that in the promotion case we change the server because otherwise users are going to end up deleting agreements, twiddling with config files, etc.
For a non-promotion replica install (with --server) failing is fine since we prevent a bad setup.
master:
ipa-4-9:
ipa-4-11:
ipa-4-10:
Metadata Update from @frenaud: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @abbra: - Custom field changelog adjusted to Replica installation process now happens against a chosen server, not only for Kerberos authentication but also for all IPA API and CA requests. This helps to avoid incomplete replicated details when adding a new replica to a complex topology.
Log in to comment on this ticket.