[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] [PATCH] 749 use hostname consistently in ipa-client-install

Martin Kosek wrote:
On Mon, 2011-03-07 at 11:52 -0500, Rob Crittenden wrote:
Nalin Dahyabhai wrote:
On Fri, Mar 04, 2011 at 05:59:26PM -0500, Rob Crittenden wrote:
If a hostname was provided it wasn't used to configure either
certmonger or sssd. This resulted in a non-working configuration.
@@ -241,6 +242,81 @@ def stop_tracking(secdir, request_id=None, nickname=None):

      return (stdout, stderr, returncode)

+def _find_ipa_submit_ca():
+    """
+    Look through all the certmonger CA files to find the one that
+    defines ipa-submit as the ca_external_helper.
+    We can use find_request_value because the ca files have the
+    same file format.
+    """
+    fileList=os.listdir(CA_DIR)
+    for file in fileList:
+        value = find_request_value('%s/%s' % (CA_DIR, file), 'ca_external_helper')
+        if value is not None and value.startswith('/usr/libexec/certmonger/ipa-submit'):
+            return '%s/%s' % (CA_DIR, file)

This should work, but could I get you to change the test here to look
for "id=IPA" instead of

The "ipa-getcert" command-line tool is hard-coded to ask certmonger to
use the CA with an "id" of "IPA", and that's how certmonger figures out
which file's settings to use.

I can imagine having another CA configuration for certmonger on the
system that told it to call its ipa-submit helper with a different set
of arguments.  In that setup, the one with "id=IPA" would still be the
one that certmonger would use on behalf of ipa-getcert.  (I don't have a
good idea of _why_ someone would do that, but there you go.)



Good idea, switched to use id=IPA instead.


ACK, nice work.

Tested with ticket 748. Everything worked with both --hostname set and
without it, uninstallation was also correct.

I just run into an issue (not patch related) when certmonger kept
showing me CA_UNCONFIGURED certificate tracking status. As we found out,
this was caused by SELinux. However, new SElinux policy
selinux-policy-3.9.7-33.fc14 should fix it.


I need to do some further investigation to see how this affects other distros, we may need to update the low-bar for selinux policy in our spec file. I'll open a new ticket for that.

pushed to master

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]