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
>>>> DRM was really only used in docs/marketing, whereas KRA is all over the
>>>> 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
>>>> before commit.
>>> 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.
>> ipa_drm_install.py: No newline at end of file
>> ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is
>> ipa-drm-install (with hyphens)
>> 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.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
>> 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
> 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.
> 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.
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.
There is no man page for ipa-kra-install
Functionally the KRA itself seems to be working ok.
Freeipa-devel mailing list