On 10/02/2012 03:02 PM, Petr Viktorin wrote:
On 10/01/2012 05:02 PM, Ade Lee wrote:
On Mon, 2012-10-01 at 16:09 +0200, Martin Kosek wrote:
On 10/01/2012 03:35 PM, Petr Viktorin wrote:
On 09/27/2012 10:26 AM, Petr Viktorin wrote:
On 09/20/2012 05:58 AM, Ade Lee wrote:
Changes to use a single database for dogtag and IPA

      New servers that are installed with dogtag 10 instances will
      a single database instance for dogtag and IPA, albeit with
      suffixes.  Dogtag will communicate with the instance through a
      database user with permissions to modify the dogtag  suffix
      This user will authenticate using client auth using the
      for the instance.

      This patch includes changes to allow the creation of masters
      with single ds instances.

I have tested being able to create a master and a clone using f17 and
dogtag 10.  Note that you will need to use the latest builds on the
dogtag repo to get some changes that were checked in today.  We'll
off another official f18 dogtag build in a day or so.

This is a pretty big change - so I expect many issues to come up as
things get tested.  But as this will take awhile to get resolved, its
better to get this out for review as fast as possible.

Happy reviewing.


Attaching a rebased patch with a couple of style issues fixed.
- PEP8 compliance (remove trailing whitespace, use parentheses rather
than \ for line continuation, wrap touched lines at 80 characters)
- for files, use the with statement instead of the "open/close
- don't mix tabs and spaces in install/share/certmap.conf.template

I've also adjusted the spec file, as we need dogtag 10.0 and
now obsoletes pki-setup.

I still need selinux in permissive mode to install on f17, and I still
need to exclude *.i686 packages when updating.

Are the following limitations expected?

IPA and Dogtag have to be updated simultaneously; it's not possible
to have
current IPA master with Dogtag 10, or IPA with this patch with D9.

It is not possible to create a replica from a machine with a single
DS to an
older version without the patch -- the older version will try the
wrong ports.

In this case, I think we are covered - we do not support installation
of a
replica with a lower version than the master where the replica info
file was
created. Rob's patch 26dfbe61dd399e9c34f6f5bdeb25a197f1f461cb should
this for next version release. For 3.0 I think we will have to settle
with a
note in Documentation.

There is currently a dogtag bug where when the master is dogtag 9 (or
dogtag 9 converted to 10), and the clone is dogtag 10, the clone will
fail to get the installation token from the security domain.  This is
because the dogtag 10 code tries the new restful interface call -- which
is not present on a dogtag 9 subsystem.

This has been fixed in the latest dogtag 10 nightly builds.  And will be
in the next dogtag 10 official build, which we plan to create and
release today.

Incidentally, to see whats coming up in the new dogtag build, look for
the 10.0.0-0.X.a2 milestone (plus some of what is closed in 9.0.24)

Okay, testing with the dogtag-devel repo, on f17.

The following scenarios don't work:

- Start with a master on D9
- install a replica on D10, without a CA
- run ipa-ca-install on the replica
   ipa-replica-conncheck: error: no such option: --dogtag-master-ds-port

- Start with a master on D9
- install a replica without a CA (either Dogtag version)
- Update all machines
- run ipa-ca-install on the replica
com.netscape.certsrv.base.PKIException: Failed to obtain installation
token from security domain

I get the following errors in catalina.out on the replica:
08:40:11,149 DEBUG
(org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to
retrieve ServletContext: expandEntityReferences defaults to true
08:40:11,158 DEBUG
(org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to
retrieve ServletContext: expandEntityReferences defaults to true
CMS Warning: FAILURE: Cannot build CA chain. Error
java.security.cert.CertificateException: Certificate is not a PKCS #11
certificate|FAILURE: authz instance DirAclAuthz initialization failed
and skipped, error=Property internaldb.ldapconn.port missing value|

I did the second scenario again and got a slightly different error message: "White spaces are required between publicId and systemId." See attached logs. I started with IPA 2.2 (from f17 repos) on both machines, then updated to patched IPA w/ D10, then ran ipa-ca-install.


Attachment: replica-logs.tar.gz
Description: GNU Zip compressed data

Freeipa-devel mailing list

Reply via email to