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
>> 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/", line 2012, in store_secret
>>          self._setup()
>>        File "ipaserver/plugins/", line 1965, in _setup
>>          connection = PKIConnection('https', self.kra_host, 
>> self.kra_port, 'kra')
>>        File "/usr/lib/python2.7/site-packages/pki/", 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  Thats fixed, so this should work now.
> After discussion with Endi, I also removed some functions in
> (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.
> 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

Reply via email to