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
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
