Re: [Freeipa-devel] [PATCH] 749 use hostname consistently in ipa-client-install
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.
[snip]
@@ -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
ca_external_helper=/usr/libexec/certmonger/ipa-submit?
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.)
Cheers,
Nalin
Good idea, switched to use id=IPA instead.
rob
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.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
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.
[snip]
@@ -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
ca_external_helper=/usr/libexec/certmonger/ipa-submit?
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.)
Cheers,
Nalin
Good idea, switched to use id=IPA instead.
rob
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.
Martin
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
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
