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 IPANew servers that are installed with dogtag 10 instances will use a single database instance for dogtag and IPA, albeit with different suffixes. Dogtag will communicate with the instance through a database user with permissions to modify the dogtag suffix only. This user will authenticate using client auth using the subsystem cert for the instance. This patch includes changes to allow the creation of masters and clones 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 kick 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. AdeAttaching 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 sandwich" - 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 pki-server 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 ensure 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. https://fedorahosted.org/pki/ticket/334 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: 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.
Description: GNU Zip compressed data
_______________________________________________ Freeipa-devel mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-devel