[Freeipa-devel] [PATCH] - Add DRM to IPA
Ade Lee
alee at redhat.com
Thu Aug 21 13:48:07 UTC 2014
As agreed on #irc, disabling uninstallation for now.
Please apply this new patch on top of the big one.
Ade
On Thu, 2014-08-21 at 01:15 -0400, Ade Lee wrote:
> On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote:
> > Ade Lee wrote:
> > > On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote:
> > >> On 08/14/2014 10:53 AM, Martin Kosek wrote:
> > >>> On 08/13/2014 09:54 PM, Ade Lee wrote:
> > >>>> In Dogtag, we have decided to revert the name of the DRM to the old name KRA.
> > >>>> DRM was really only used in docs/marketing, whereas KRA is all over the code.
> > >>>> Soon, the code and the marketing/docs will match.
> > >>>>
> > >>>> The following patch changes all references to the DRM to KRA.
> > >>>> so for example, you need to run ipa-kra-install etc.
> > >>>>
> > >>>> Please apply this on top of the previous patch. I'll go ahead and squash them
> > >>>> before commit.
> > >>>>
> > >>>> Thanks,
> > >>>> Ade
> > >>>
> > >>> Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to
> > >>> KRA and assigned respective tickets to that. Let us use the KRA term for the
> > >>> Vault then.
> > >>>
> > >>> Martin
> > >>>
> > >>
> > >> ipa_drm_install.py: No newline at end of file
> > >> ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is
> > >> ipa-drm-install (with hyphens)
> > >>
> > > fixed
> > >>
> > >> The error I got previously was when running ipa-kra-install on a replica
> > >> that didn't have CA yet. It would be nice to provide a better message
> > >> for this case.
> > >>
> > > agreed. the problem here was that the check to see whether a ca was
> > > already installed locally was not working as expected.
> > >
> > > I have since added a new check - which should fail if a CA is not
> > > installed locally.
> > >
> > >>
> > >> On a replica with KRA, I get:
> > >> $ sudo ipa-kra-install --uninstall
> > >> Usage: ipa-kra-install [options] [replica_file]
> > >>
> > >> ipa-kra-install: error: Cannot uninstall. There is no KRA
> > >> installed on this system.
> > >>
> > >
> > > Not sure what happened there. With the latest code, that does not
> > > appear to happen for me. Let me know if it recurs.
> > >
> > >> I tested the kra plugin with this Python script:
> > >>
> > >> from ipalib import api
> > >> api.bootstrap(context='server', kra_host='localhost')
> > >> api.finalize()
> > >> api.Backend.kra.store_secret('test', 'tkey')
> > >>
> > >> which gives me:
> > >>
> > >> Traceback (most recent call last):
> > >> File "<stdin>", line 1, in <module>
> > >> File "ipaserver/plugins/dogtag.py", line 2012, in store_secret
> > >> self._setup()
> > >> File "ipaserver/plugins/dogtag.py", line 1965, in _setup
> > >> connection = PKIConnection('https', self.kra_host,
> > >> self.kra_port, 'kra')
> > >> File "/usr/lib/python2.7/site-packages/pki/client.py", line 36,
> > >> in __init__
> > >> self.hostname + ':' + self.port + '/' + \
> > >> TypeError: coercing to Unicode: need string or buffer, int found
> > >>
> > >>
> > >> Apparently, PKIConnection requires the port to be a string, but we pass
> > >> an int. I'd consider this an issue in pki.
> > >>
> > > Agreed. I will open a ticket to fix it in pki. For now though, I have
> > > cast to str().
> > >
> > >>
> > >> The kra_host='localhost' option to api.bootstrap is necessary because
> > >> kra_host is not added to default.conf on install. How is this planned to
> > >> work when the plugin is done?
> > >>
> > > I followed what was done for ca_host, but did not set the required
> > > default in constants.py. Thats fixed, so this should work now.
> > >
> > > After discussion with Endi, I also removed some functions in dogtag.py
> > > (the plugin) which basically just wrapped calls to the keyclient. There
> > > is no need to do this wrapping and it is much more flexible for IPA code
> > > to call the keyclient directly. Accordingly, I have added a method to
> > > get the keyclient. Your test code would look like this now:
> > >
> > > from ipalib import api
> > > from pki.key import KeyClient
> > > api.bootstrap(context='server')
> > > api.finalize()
> > > keyclient = api.Backend.kra.get_keyclient()
> > > keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
> > >
> > > I added a couple of directives in the proxy file to allow it to progress
> > > further and it now fails in trying to do the archive_key due to
> > > authentication issues.
> > >
> Did some more investigation on this. It turns out that the problem is
> in the PEM file that is generated (/etc/httpd/aliad/agent.pem)
>
> There are in fact two problems. One is that the agent.pem that is
> available there is for the IPA RA agent, who is not an agent on the KRA.
> Also, it appears that the PEM file itself may have some weirdness in its
> format.
>
> The PEM file is generated by the code _generate_pem_file() in dogtag.py.
> That code will need to be re-examined and fixed. I would like to leave
> that task to Endi - as he needs to decide how/which agent will be used
> to communicate with the KRA.
>
> If you use a valid agent PEM, then the above test code works.
>
> Here is what I did:
> $ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes
>
> And then I ran the following without issues:
>
> from ipalib import api
> from pki.key import KeyClient
> api.bootstrap(context='server')
> api.finalize()
> keyclient = api.Backend.kra.get_keyclient()
>
> infos = keyclient.list_keys()
> for info in infos.key_infos:
> print "{0} {1}".format(info.client_key_id, info.key_url)
>
> keyclient.archive_key('test3', KeyClient.PASS_PHRASE_TYPE,'tkey')
> print keyclient.retrieve_key(1).data
>
> You can also use the pki cli utility (pki key ...) to confirm that the
> KRA is in fact operational.
>
> > > It was never the intention of this patch to get the plugin completely
> > > working though. That was the goal of a follow on patch being written by
> > > Endi. This patch is already pretty long and touches a lot of code. I
> > > propose we let Endi fix the above issue.
> > >
> > > I have squashed the drm-> kra changes and created just a single patch,
> > > which is attached. This is the only patch needed.
> > >
> > > I'm also starting a new COPR build, just to be sure we all have the most
> > > up-to-date dogtag build.
> >
> > It doesn't look like the --no-host-dns option is used anywhere.
> >
>
> removed in attached patch.
>
> > I'm kinda with Petr, I don't know that an uninstall option is needed.
>
> > On a single master install I successfully did a kra install, uninstall,
> > re-install, so maybe the issue that Petr saw was related to cloning.
>
> I investigated this error. The failure to reinstall on the clone is due
> to a bug in the way pkidestroy handles the kra connector configuration
> that is created on the CA. I have opened up a ticket to address this,
> and will try to fix this issue within the next week or two.
>
> Once this is fixed, installing/uninstalling on either a master or clone
> should work without issues.
>
> As a workaround till then, after uninstalling the master and clone KRAs,
> check the CS.cfg of the master/clone CA and remove any entries that
> start with ca.connector.KRA.* And of course, restart the CA.
>
> I propose leaving this in -- it basically works right now - except for
> the issue above.
> >
> > There is no man page for ipa-kra-install
> >
> Can I add this in a separate patch?
>
> > Functionally the KRA itself seems to be working ok.
>
> Attached is a patch with a few basic changes - mostly additional URLs
> needed to make sure the script above runs. Please apply on top of the
> big one previously attached. I'll squash before commit.
>
> > rob
> >
> >
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-1-Some-additional-minor-changes.patch
Type: text/x-patch
Size: 3785 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140821/d2472562/attachment.bin>
More information about the Freeipa-devel
mailing list