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
