Blob Blame History Raw
From 609ccb601843b97b25f2fde3c4981839822af503 Mon Sep 17 00:00:00 2001
From: Christian Heimes <cheimes@redhat.com>
Date: Tue, 17 Jul 2018 08:53:39 +0200
Subject: [PATCH] Fix KRA replica installation from CA master

ipa-replica-install --kra-install can fail when the topology already has
a KRA, but replica is installed from a master with just CA. In that
case, Custodia may pick a machine that doesn't have the KRA auditing and
signing certs in its NSSDB.

Example:
 * master with CA
 * replica1 with CA and KRA
 * new replica gets installed from master

The replica installer now always picks a KRA peer.

The change fixes test scenario TestInstallWithCA1::()::test_replica2_ipa_dns_install

Fixes: https://pagure.io/freeipa/issue/7518
See: https://pagure.io/freeipa/issue/7008
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
---
 ipaserver/install/server/replicainstall.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py
index 8826da232a90380084b0e4f3dca783125a5500da..e78a2b992fbd44b8ee3ccd8183ebd6e13dfd1749 100644
--- a/ipaserver/install/server/replicainstall.py
+++ b/ipaserver/install/server/replicainstall.py
@@ -1486,7 +1486,10 @@ def install(installer):
     otpd.create_instance('OTPD', config.host_name,
                          ipautil.realm_to_suffix(config.realm_name))
 
-    if ca_enabled:
+    if kra_enabled:
+        # A KRA peer always provides a CA, too.
+        mode = custodiainstance.CustodiaModes.KRA_PEER
+    elif ca_enabled:
         mode = custodiainstance.CustodiaModes.CA_PEER
     else:
         mode = custodiainstance.CustodiaModes.MASTER_PEER
-- 
2.17.1