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

Ade Lee alee at redhat.com
Mon Apr 14 14:42:12 UTC 2014


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

Thanks,
Ade

On Tue, 2014-04-08 at 09:52 -0400, Rob Crittenden wrote:
> Martin Kosek wrote:
> > 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.
> 
> Yes, that is a question I didn't ask: Is the DRM going to be configured 
> by default on all new installs?
> 
> > 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 think the decision on a separate sub-package will be dependent upon 
> whether it is default or not, otherwise we can get away with 
> freeipa-server-ca and just lump everything in there.
> 
> > 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.
> 
> I touched on some of that too, but some of this is just inevitable I 
> think which is why I didn't pound on it too hard. An abstraction would 
> be nice, but I'm not sure abstracting for two things, and only in the 
> installer, is worth the effort. I could be wrong.
> 
> rob
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-a-DRM-to-IPA.patch
Type: text/x-patch
Size: 73390 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140414/aca36bf6/attachment.bin>


More information about the Freeipa-devel mailing list