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



_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to