[Freeipa-devel] [PATCH] Add DRM to IPA

[Rob Crittenden]

Ade Lee wrote:
> Attached is a patch that adds the script ipa-drm-install.
>
> This script will be used to install a drm in any ipa server that
> contains a Dogtag CA.  Right now, it works for a master.  I will add
> logic in a subsequent patch to allow the installation on a replica using
> the same script.
>
> This patch is to applied on top of the previous one.
> So, patch 2 and then patch 3.
>
> I will create a patch to address the issues mentioned below, as well as
> some other formatting issues reported by pycharm.

I think the ipa-dns-install change should be committed separately. It is 
surprising that pylint didn't catch that.

Please a comment to find_subject_base() that it can only be executed 
AFTER the ipa server is configured, the api is initialized elsewhere and 
requires that a ticket already have been acquired. I understand why this 
call is here, we just need to be clear it is used post-install and 
requires some pre-setup by the caller.

Need a man page for ipa-drm-install.

Running the uninstaller completes, then proceeds to install the DRM.

I don't think the certmonger warnings apply because some of the certs 
are duplicates of the CA certs, so if you untracked them you would 
eventually end up not renewing the subsystem certs and your clone CA 
would fail.

nit, some trailing white space after add_record_to_hosts()

The tool failed to add a DRM in my test. The debug log doesn't seem to 
contain anything interesting at all. The drm install log contained:

2014-04-21T19:00:44Z DEBUG Starting external process
2014-04-21T19:00:44Z DEBUG args=/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ
2014-04-21T19:01:09Z DEBUG Process finished, return code=1
2014-04-21T19:01:09Z DEBUG stdout=Loading deployment configuration from 
/tmp/tmpWcj8rJ.
Installing KRA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into 
/etc/sysconfig/pki/tomcat/pki-tomcat/kra/deployment.cfg.

Installation failed.


2014-04-21T19:01:09Z DEBUG stderr=
2014-04-21T19:01:09Z CRITICAL failed to configure KRA instance Command 
'/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ' returned non-zero exit 
status 1

>
> Thanks,
> Ade
>
> On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote:
>> Ade Lee wrote:
>>> Attached a new patch to address some of the concerns below, specifically
>>> I created a new base class DogtagInstance, in which much of the common
>>> CA/KRA code is placed.  I'm sure we could go further in reducing
>>> duplication, and I'm open to further suggestions and refinements.
>>>
>>> I did not tackle the packaging and spec file dependencies, because I'd
>>> like some clearer direction on how we want to proceed here.  In any
>>> case, I think the splitting of the ipa packages into ca and possibly kra
>>> packages should be a separate patch.
>>>
>>> As before, with this patch you can:
>>> - install a ca and drm using ipa-server-install
>>> - install a ca and drm replica using
>>>      ipa-replica-prepare <hostname>
>>>      ipa-replica-install --setup-ca --setup-drm <replia file>
>>>
>>> You need to use a PKI build from the 10.2 (master) branch).  One such
>>> build is given below:
>>> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo
>>
>> The terms KRA and DRM tend to be used interchangeably. Should we pick one?
>>
>> Need to bump the version number in install/conf/ipa-pki-proxy.conf so
>> that upgrades get the new LocationMatch.
>>
>> ipa-replica-install still uses the if/then to set the value of
>> enable_drm when it can be reduced like you did in ipa-server-install.
>>
>> In ipa-server-install you have an extra comment, probably left for
>> yourself: # code to create drm here
>>
>> In dogtaginstance.py there are a few direct references to DRM in
>> comments and output.
>>
>> cainstance.py doesn't need to override is_installed.py
>>
>> I also don't think you need the explicit definitions for enable,
>> start_instance, etc. Those should be inherited from the DogtagInstance
>> class, in both cainstance.py and drminstance.py.
>>
>> I think spawn_instance should take an option to add things to nolog in
>> case there are server-independent things we don't want to log.
>>
>> I don't want to pile too much on, but it seems to me that if we are
>> going to copy in default.conf then we can do away with realm_info
>> completely and just use default.conf. Both would need to be supported
>> for a while though. Martin, what do you think?
>>
>> I still have quite a bit of functional testing to go. I've only
>> installed a fresh standalone master. Still need to do upgrade and
>> replication testing.
>>
>> rob
>>
>