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

[Martin Kosek]

On 04/07/2014 10:40 PM, Rob Crittenden wrote:
> Ade Lee wrote:
>>      This patch adds the capability of installing a Dogtag DRM
>>      to an IPA instance.  With this patch, when ipa-server-install
>>      is run, a Dogtag CA and a Dogtag DRM are created.  The DRM
>>      shares the same tomcat instance and DS instance as the Dogtag CA.
>>      Moreover, the same admin user/agent (and agent cert) can be used
>>      for both subsystems.  Certmonger is also confgured to monitor the
>>      new subsystem certificates.
>>
>>      It is also possible to clone the DRM.  When the IPA instance is
>>      cloned, if --enable-ca and --enable-drm are specified, the DRM
>>      is cloned as well.
>>
>>      Installing a DRM requires the user to have a Dogtag CA instance.
>>      We can look into possibly relaxing that requirement in a later patch.
>>
>>      I am still working on patches for a ipa-drm-install script, which
>>      would be used to add a DRM to an existing master (that includes
>>      a dogtag CA), or an existing clone.
>>
>>     Please review,
>>
>>     Thanks,
>>     Ade
> 
> Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be
> pushed ASAP.

Oops, looks like a change that should go to IPA 3.3.x. What is the implication?

> freeipa-spec.in needs a dependency on pki-kra.

Let us stop here. Please see a following RFE I filed:
https://fedorahosted.org/freeipa/ticket/4058

I would prefer it KRA files and specifics would be in a new subpackage like
freeipa-server-kra. Otherwise we will need to rework it again when we would be
splitting CA to freeipa-server-pki in 4.1.

I would prefer to start the right modularization now as I do not think that
every FreeIPA server needs to run CA/KRA, i.e. it  does not need to have the
bits installed either.

I am also quite worried about the duplication that the new drminstance.py
introduces. There is a lot of functions which do more or less the same thing
and have most of the handling code the same with only a very small and
predictable pki/kra change. For example __http_proxy function seems to be
exactly the same.

It would be great to avoid this duplication and rather have some common ground
utilized by both PKI and KRA. Otherwise it will be very difficult to maintain
the new code.

Martin