Re: [Freeipa-devel] [PATCH] 0038 cert-request: remove allowed extensions check
Fraser, Continuing the discussion started previously, the question is whether IPA should check for the presence of certain extensions. There seem to be two kinds of problems which could be encountered here: 1. User could include a CSR which includes an extension that is not valid for the profile. 2. User could include data for an extension that is invalid. The original allowed extensions check attempted to address problem (1) by allowing only extensions that were valid for the small set of profiles used by IPA. Now that custom profiles are available, though, this is no longer sufficient. I do believe that it would be useful to provide the user with feedback if a particular extension is not supported by the profile when the CSR is submitted to IPA. This should most likely be a non-fatal notification, because the CA will end up ignoring the extension. With the Dogtag profile API, it is possible to enumerate the extensions that are included in a cert for a particular profile. Couldn't this data be used as the basis for this check? For problem (2), although some validation could be done in IPA, this is most probably something that should be left to Dogtag itself. I believ e the error reporting from Dogtag has been sufficiently improved so that these types of validation errors would be reported back to IPA. Ade On Thu, 2015-08-13 at 15:54 +1000, Fraser Tweedale wrote: The attached patch fixes https://fedorahosted.org/freeipa/ticket/5205 Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Need to figure out how to make a schema change
In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. Thanks, Ade -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 11 - re-enable uninstall option in ipa-kra-install
Re-enable uninstall feature for ipa-kra-install The underlying Dogtag issue (Dogtag ticket 1113) has been fixed. We can therefore re-enable the uninstall option for ipa-kra-install. Also, fixes an incorrect path in the ipa-pki-proxy.conf, and adds a debug statement to provide status to the user when an uninstall is done. Also, re-added the no_host_dns option which is used when unpacking a replica file. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 Please review. A new COPR Dogtag build with the relevant fix for ticket 1113 has been built. (pki-core-10.2.0-0.8.fc20) Please update your Dogtag build to this version. Thanks, Ade From b039bc0a8ddc88e90830626f3b812e8ee29e7e08 Mon Sep 17 00:00:00 2001 From: Ade Lee a...@redhat.com Date: Mon, 1 Sep 2014 22:49:54 -0400 Subject: [PATCH] Re-enable uninstall feature for ipa-kra-install The underlying Dogtag issue (Dogtag ticket 1113) has been fixed. We can therefore re-enable the uninstall option for ipa-kra-install. Also, fixes an incorrect path in the ipa-pki-proxy.conf, and adds a debug statement to provide status to the user when an uninstall is done. Also, re-added the no_host_dns option which is used when unpacking a replica file. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 --- install/conf/ipa-pki-proxy.conf | 2 +- ipaserver/install/dogtaginstance.py | 4 ipaserver/install/ipa_kra_install.py | 13 + 3 files changed, 10 insertions(+), 9 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 57175390b89ac2b13adef8862c42359f46434924..2370b4d7a7467a7e47c0d223915e018c9a009e83 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -19,7 +19,7 @@ ProxyRequests Off /LocationMatch # matches for agent port and eeca port -LocationMatch ^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector|^/kra/rest/agent/keyrequests|^/kra/rest/agent/keys|^/kra/rest/admin/kraconnector/remove +LocationMatch ^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector|^/kra/rest/agent/keyrequests|^/kra/rest/agent/keys|^/ca/rest/admin/kraconnector/remove NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/ipaserver/install/dogtaginstance.py b/ipaserver/install/dogtaginstance.py index c872f31037d5c559178123f0ba535aa567bf722f..f4c4e552d8183e1b87663e20b4bf5364f920f1b4 100644 --- a/ipaserver/install/dogtaginstance.py +++ b/ipaserver/install/dogtaginstance.py @@ -332,6 +332,10 @@ class DogtagInstance(service.Service): def stop_tracking_certificates(self, dogtag_constants, reqs=None): Stop tracking our certificates. Called on uninstall. +self.print_msg( +Configuring certmonger to stop tracking system certificates +for %s % self.subsystem) + cmonger = services.knownservices.certmonger services.knownservices.messagebus.start() cmonger.start() diff --git a/ipaserver/install/ipa_kra_install.py b/ipaserver/install/ipa_kra_install.py index 2c4f2dcaa159bc5834c81b579100b46af54ad09c..207b8c412ee119b0deef9b423b9e2007c26d3c43 100644 --- a/ipaserver/install/ipa_kra_install.py +++ b/ipaserver/install/ipa_kra_install.py @@ -49,6 +49,11 @@ class KRAInstall(admintool.AdminTool): super(KRAInstall, cls).add_options(parser, debug_option=True) parser.add_option( +--no-host-dns, dest=no_host_dns, action=store_true, +default=False, +help=Do not use DNS for hostname lookup during installation) + +parser.add_option( -p, --password, dest=password, sensitive=True, help=Directory Manager (existing master) password) @@ -115,14 +120,6 @@ class KRAUninstaller(KRAInstall): super(KRAUninstaller, self).run() dogtag_constants = dogtag.configured_constants() -# temporarily disable uninstall until Dogtag ticket: -# https://fedorahosted.org/pki/ticket/1113 is fixed -# TODO(alee) remove this once the above ticket is fixed -raise admintool.ScriptError( -Uninstall is temporarily disabled. To uninstall, please -use ipa-server-install --uninstall -) - kra_instance = krainstance.KRAInstance( api.env.realm, dogtag_constants=dogtag_constants) kra_instance.stop_tracking_certificates(dogtag_constants) -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] add man page for ipa-kra-install
Looks good to me. Thanks. Ade On Tue, 2014-08-26 at 14:13 +0200, Petr Viktorin wrote: On 08/25/2014 06:37 PM, Ade Lee wrote: New patch attached. If OK, please commit for me. Thanks, Ade I missed the argument list, where you have a deprecated option, and you list -U for both --unattended and --uninstall. Here's an updated patch, I can push if it looks OK to you. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
We plan to do an alpha build of Dogtag 10.2 on Fedora 21 at the end of this week. Ade On Mon, 2014-08-25 at 13:14 +0200, Petr Viktorin wrote: On 08/22/2014 03:28 PM, Petr Vobornik wrote: [...] Should the requirement of Dogtag 10.2 be reflected in a spec file? Yes. Sorry for forgetting that point in he review. We can do two things here: 1) Require Dogtag 10.2 (and ask developers to add the vakwetu-dogtag repo for ipa master) or 2) Disable ipa-kra-install and the kra plugin if pki.crypto is not importable How soon will 10.2 be available? If it will take a while I'd rather do 2) but it does mean more churn in the repo. Thoughts? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] add man page for ipa-kra-install
What if I add the following first paragraph? The KRA (Key Recovery Authority) is a component used to securely store secrets such as passwords, symmetric keys and private asymmetric keys. It is used as the back-end repository for the IPA Password Vault. Ade On Mon, 2014-08-25 at 10:28 +0200, Petr Viktorin wrote: On 08/24/2014 06:28 PM, Ade Lee wrote: Added man pages for ipa-kra-install. And its not even Tuesday yet :) Please review, Ade If I was new to this, I think I'd be quite lost. I think the man page should briefly explain what KRA is -- just a sentence would be fine. At the very least expand the acronym. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] add man page for ipa-kra-install
New patch attached.
If OK, please commit for me.
Thanks,
Ade
On Mon, 2014-08-25 at 18:25 +0200, Petr Viktorin wrote:
On 08/25/2014 06:17 PM, Ade Lee wrote:
What if I add the following first paragraph?
The KRA (Key Recovery Authority) is a component used to securely store
secrets such as passwords, symmetric keys and private asymmetric keys.
It is used as the back-end repository for the IPA Password Vault.
Ade
Perfect.
On Mon, 2014-08-25 at 10:28 +0200, Petr Viktorin wrote:
On 08/24/2014 06:28 PM, Ade Lee wrote:
Added man pages for ipa-kra-install. And its not even Tuesday yet :)
Please review,
Ade
If I was new to this, I think I'd be quite lost.
I think the man page should briefly explain what KRA is -- just a
sentence would be fine. At the very least expand the acronym.
From ea23a915a74834005b584996c868fb4acfbf5e5b Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Sun, 24 Aug 2014 12:19:55 -0400
Subject: [PATCH] Added man page for ipa-kra-install
---
freeipa.spec.in | 1 +
install/tools/man/Makefile.am | 1 +
install/tools/man/ipa-kra-install.1 | 50 +
3 files changed, 52 insertions(+)
create mode 100644 install/tools/man/ipa-kra-install.1
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 3079625aecb9d6067cb3315d64de727b5204f8ab..6df4f06f2925700a35a4fc608c379ac400caa888 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -712,6 +712,7 @@ fi
%{_mandir}/man1/ipa-server-install.1.gz
%{_mandir}/man1/ipa-dns-install.1.gz
%{_mandir}/man1/ipa-ca-install.1.gz
+%{_mandir}/man1/ipa-kra-install.1.gz
%{_mandir}/man1/ipa-compat-manage.1.gz
%{_mandir}/man1/ipa-nis-manage.1.gz
%{_mandir}/man1/ipa-managed-entries.1.gz
diff --git a/install/tools/man/Makefile.am b/install/tools/man/Makefile.am
index f9f75f183c406a2159c025b17e5bf463a46e12d2..38c049c79fbd2ce22888b47ee576c4574e98c45b 100644
--- a/install/tools/man/Makefile.am
+++ b/install/tools/man/Makefile.am
@@ -15,6 +15,7 @@ man1_MANS = \
ipa-dns-install.1 \
ipa-adtrust-install.1 \
ipa-ca-install.1 \
+ ipa-kra-install.1 \
ipa-ldap-updater.1 \
ipa-compat-manage.1 \
ipa-nis-manage.1 \
diff --git a/install/tools/man/ipa-kra-install.1 b/install/tools/man/ipa-kra-install.1
new file mode 100644
index ..60b53b0e9389762df3d656d105a1e5cabb89f7f0
--- /dev/null
+++ b/install/tools/man/ipa-kra-install.1
@@ -0,0 +1,50 @@
+.\ A man page for ipa-kra-install
+.\ Copyright (C) 2014 Red Hat, Inc.
+.\
+.\ This program is free software; you can redistribute it and/or modify
+.\ it under the terms of the GNU General Public License as published by
+.\ the Free Software Foundation, either version 3 of the License, or
+.\ (at your option) any later version.
+.\
+.\ This program is distributed in the hope that it will be useful, but
+.\ WITHOUT ANY WARRANTY; without even the implied warranty of
+.\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+.\ General Public License for more details.
+.\
+.\ You should have received a copy of the GNU General Public License
+.\ along with this program. If not, see http://www.gnu.org/licenses/.
+.\
+.\ Author: Ade Lee a...@redhat.com
+.\
+.TH ipa-kra-install 1 Aug 24 2014 FreeIPA FreeIPA Manual Pages
+.SH NAME
+ipa\-kra\-install \- Install a KRA on a server
+.SH SYNOPSIS
+ipa\-kra\-install [\fIOPTION\fR]... [replica_file]
+.SH DESCRIPTION
+Adds a KRA as an IPA\-managed service. This requires that the IPA server is already installed and configured, including a CA.
+
+The KRA (Key Recovery Authority) is a component used to securely store secrets such as passwords, symmetric keys and private asymmetric keys. It is used as the back-end repository for the IPA Password Vault.
+
+ipa\-kra\-install can be run without replica_file to add KRA to the existing CA.
+ipa\-kra\-install will contact the CA to determine if a KRA has already been installed on another replica, and if so, will exit indicating that a replica_file is required.
+
+The replica_file is created using the ipa\-replica\-prepare utility. A new replica_file should be generated on the master IPA server after the KRA has been installed and configured, so that the replica_file will contain the master KRA configuration and system certificates.
+
+The uninstall option can be used to remove the KRA from the local IPA server. KRA instances on other replicas are not affected. The KRA will also be removed if the entire server is removed using ipa\-server\-install \-\-uninstall.
+.SH OPTIONS
+\fB\-d\fR, \fB\-\-debug\fR
+Enable debug logging when more verbose output is needed
+.TP
+\fB\-p\fR \fIDM_PASSWORD\fR, \fB\-\-password\fR=\fIDM_PASSWORD\fR
+Directory Manager (existing master) password
+.TP
+\fB\-U\fR, \fB\-\-unattended\fR
+An unattended installation that will never prompt for user input
+.TP
+\fB\-U\fR, \fB\-\-uninstall\fR
+Uninstall the KRA from the local IPA server.
+.SH EXIT
[Freeipa-devel] [PATCH] add man page for ipa-kra-install
Added man pages for ipa-kra-install. And its not even Tuesday yet :)
Please review,
Ade
From 571c77102577321bb2a524873904a83581f85a32 Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Sun, 24 Aug 2014 12:19:55 -0400
Subject: [PATCH] Added man page for ipa-kra-install
---
freeipa.spec.in | 1 +
install/tools/man/Makefile.am | 1 +
install/tools/man/ipa-kra-install.1 | 48 +
3 files changed, 50 insertions(+)
create mode 100644 install/tools/man/ipa-kra-install.1
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 3079625aecb9d6067cb3315d64de727b5204f8ab..6df4f06f2925700a35a4fc608c379ac400caa888 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -712,6 +712,7 @@ fi
%{_mandir}/man1/ipa-server-install.1.gz
%{_mandir}/man1/ipa-dns-install.1.gz
%{_mandir}/man1/ipa-ca-install.1.gz
+%{_mandir}/man1/ipa-kra-install.1.gz
%{_mandir}/man1/ipa-compat-manage.1.gz
%{_mandir}/man1/ipa-nis-manage.1.gz
%{_mandir}/man1/ipa-managed-entries.1.gz
diff --git a/install/tools/man/Makefile.am b/install/tools/man/Makefile.am
index f9f75f183c406a2159c025b17e5bf463a46e12d2..38c049c79fbd2ce22888b47ee576c4574e98c45b 100644
--- a/install/tools/man/Makefile.am
+++ b/install/tools/man/Makefile.am
@@ -15,6 +15,7 @@ man1_MANS = \
ipa-dns-install.1 \
ipa-adtrust-install.1 \
ipa-ca-install.1 \
+ ipa-kra-install.1 \
ipa-ldap-updater.1 \
ipa-compat-manage.1 \
ipa-nis-manage.1 \
diff --git a/install/tools/man/ipa-kra-install.1 b/install/tools/man/ipa-kra-install.1
new file mode 100644
index ..5f91c84ade7f26410fe715c0a64d81c0797a50cd
--- /dev/null
+++ b/install/tools/man/ipa-kra-install.1
@@ -0,0 +1,48 @@
+.\ A man page for ipa-kra-install
+.\ Copyright (C) 2014 Red Hat, Inc.
+.\
+.\ This program is free software; you can redistribute it and/or modify
+.\ it under the terms of the GNU General Public License as published by
+.\ the Free Software Foundation, either version 3 of the License, or
+.\ (at your option) any later version.
+.\
+.\ This program is distributed in the hope that it will be useful, but
+.\ WITHOUT ANY WARRANTY; without even the implied warranty of
+.\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+.\ General Public License for more details.
+.\
+.\ You should have received a copy of the GNU General Public License
+.\ along with this program. If not, see http://www.gnu.org/licenses/.
+.\
+.\ Author: Ade Lee a...@redhat.com
+.\
+.TH ipa-kra-install 1 Aug 24 2014 FreeIPA FreeIPA Manual Pages
+.SH NAME
+ipa\-kra\-install \- Install a KRA on a server
+.SH SYNOPSIS
+ipa\-kra\-install [\fIOPTION\fR]... [replica_file]
+.SH DESCRIPTION
+Adds a KRA as an IPA\-managed service. This requires that the IPA server is already installed and configured, including a CA.
+
+ipa\-kra\-install can be run without replica_file to add KRA to the existing CA.
+ipa\-kra\-install will contact the CA to determine if a KRA has already been installed on another replica, and if so, will exit indicating that a replica_file is required.
+
+The replica_file is created using the ipa\-replica\-prepare utility. A new replica_file should be generated on the master IPA server after the KRA has been installed and configured, so that the replica_file will contain the master KRA configuration and system certificates.
+
+The uninstall option can be used to remove the KRA from the local IPA server. KRA instances on other replicas are not affected. The KRA will also be removed if the entire server is removed using ipa\-server\-install \-\-uninstall.
+.SH OPTIONS
+\fB\-d\fR, \fB\-\-debug\fR
+Enable debug logging when more verbose output is needed
+.TP
+\fB\-p\fR \fIDM_PASSWORD\fR, \fB\-\-password\fR=\fIDM_PASSWORD\fR
+Directory Manager (existing master) password
+.TP
+\fB\-U\fR, \fB\-\-unattended\fR
+An unattended installation that will never prompt for user input
+.TP
+\fB\-U\fR, \fB\-\-uninstall\fR
+Uninstall the KRA from the local IPA server.
+.SH EXIT STATUS
+0 if the command was successful
+
+1 if an error occurred
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
As agreed on #irc, disabling uninstallation for now.
Please apply this new patch on top of the big one.
Ade
On Thu, 2014-08-21 at 01:15 -0400, Ade Lee wrote:
On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote:
Ade Lee wrote:
On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote:
On 08/14/2014 10:53 AM, Martin Kosek wrote:
On 08/13/2014 09:54 PM, Ade Lee wrote:
In Dogtag, we have decided to revert the name of the DRM to the old
name KRA.
DRM was really only used in docs/marketing, whereas KRA is all over
the code.
Soon, the code and the marketing/docs will match.
The following patch changes all references to the DRM to KRA.
so for example, you need to run ipa-kra-install etc.
Please apply this on top of the previous patch. I'll go ahead and
squash them
before commit.
Thanks,
Ade
Ah, thanks for unifying that one. I changed DRM component in FreeIPA
Trac to
KRA and assigned respective tickets to that. Let us use the KRA term
for the
Vault then.
Martin
ipa_drm_install.py: No newline at end of file
ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is
ipa-drm-install (with hyphens)
fixed
The error I got previously was when running ipa-kra-install on a replica
that didn't have CA yet. It would be nice to provide a better message
for this case.
agreed. the problem here was that the check to see whether a ca was
already installed locally was not working as expected.
I have since added a new check - which should fail if a CA is not
installed locally.
On a replica with KRA, I get:
$ sudo ipa-kra-install --uninstall
Usage: ipa-kra-install [options] [replica_file]
ipa-kra-install: error: Cannot uninstall. There is no KRA
installed on this system.
Not sure what happened there. With the latest code, that does not
appear to happen for me. Let me know if it recurs.
I tested the kra plugin with this Python script:
from ipalib import api
api.bootstrap(context='server', kra_host='localhost')
api.finalize()
api.Backend.kra.store_secret('test', 'tkey')
which gives me:
Traceback (most recent call last):
File stdin, line 1, in module
File ipaserver/plugins/dogtag.py, line 2012, in store_secret
self._setup()
File ipaserver/plugins/dogtag.py, line 1965, in _setup
connection = PKIConnection('https', self.kra_host,
self.kra_port, 'kra')
File /usr/lib/python2.7/site-packages/pki/client.py, line 36,
in __init__
self.hostname + ':' + self.port + '/' + \
TypeError: coercing to Unicode: need string or buffer, int found
Apparently, PKIConnection requires the port to be a string, but we pass
an int. I'd consider this an issue in pki.
Agreed. I will open a ticket to fix it in pki. For now though, I have
cast to str().
The kra_host='localhost' option to api.bootstrap is necessary because
kra_host is not added to default.conf on install. How is this planned to
work when the plugin is done?
I followed what was done for ca_host, but did not set the required
default in constants.py. Thats fixed, so this should work now.
After discussion with Endi, I also removed some functions in dogtag.py
(the plugin) which basically just wrapped calls to the keyclient. There
is no need to do this wrapping and it is much more flexible for IPA code
to call the keyclient directly. Accordingly, I have added a method to
get the keyclient. Your test code would look like this now:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
I added a couple of directives in the proxy file to allow it to progress
further and it now fails in trying to do the archive_key due to
authentication issues.
Did some more investigation on this. It turns out that the problem is
in the PEM file that is generated (/etc/httpd/aliad/agent.pem)
There are in fact two problems. One is that the agent.pem that is
available there is for the IPA RA agent, who is not an agent on the KRA.
Also, it appears that the PEM file itself may have some weirdness in its
format.
The PEM file is generated by the code _generate_pem_file() in dogtag.py.
That code will need to be re-examined and fixed. I would like to leave
that task to Endi - as he needs to decide how/which agent will be used
to communicate with the KRA.
If you use a valid agent PEM, then the above test code works.
Here is what I did:
$ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes
And then I ran the following without issues:
from ipalib import api
from
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On Thu, 2014-08-21 at 21:52 +0200, Martin Kosek wrote: On 08/21/2014 05:27 PM, Petr Viktorin wrote: On 08/21/2014 03:48 PM, Ade Lee wrote: As agreed on #irc, disabling uninstallation for now. Please apply this new patch on top of the big one. I'm fine with pushing a patch with incomplete functionality, after all I did this all the time with permissions. The incomplete parts (apart from the plugin which is entirely out of scope) are: - The agent PEM issue (will be sorted out as the plugin is implemented) - Missing man page (will be written before the plugin is implemented) - Uninstall (will be fixed on Dogtag side, re-tested and enabled) I'll open tickets for these before pushing. ACK from me if Rob agrees. On IRC, Rob said he'd rather delay pushing until the man page is written, but delegated the decision to Martin. So, Martin, can we push now and trust Ade's promise that he'll write the docs? Yes, if you open ticket(s) for all missing parts and put them in the same milestone. I would rather have the patches in than waiting for man page and then have a conflict and postpone the patch set. I trust Ade to provide the man page later, I am sure he does not want to meet with my whip otherwise :-) Perfect, thanks! I don't have commit rights, so please commit the patches for me. Ade Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote:
Ade Lee wrote:
On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote:
On 08/14/2014 10:53 AM, Martin Kosek wrote:
On 08/13/2014 09:54 PM, Ade Lee wrote:
In Dogtag, we have decided to revert the name of the DRM to the old name
KRA.
DRM was really only used in docs/marketing, whereas KRA is all over the
code.
Soon, the code and the marketing/docs will match.
The following patch changes all references to the DRM to KRA.
so for example, you need to run ipa-kra-install etc.
Please apply this on top of the previous patch. I'll go ahead and
squash them
before commit.
Thanks,
Ade
Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac
to
KRA and assigned respective tickets to that. Let us use the KRA term for
the
Vault then.
Martin
ipa_drm_install.py: No newline at end of file
ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is
ipa-drm-install (with hyphens)
fixed
The error I got previously was when running ipa-kra-install on a replica
that didn't have CA yet. It would be nice to provide a better message
for this case.
agreed. the problem here was that the check to see whether a ca was
already installed locally was not working as expected.
I have since added a new check - which should fail if a CA is not
installed locally.
On a replica with KRA, I get:
$ sudo ipa-kra-install --uninstall
Usage: ipa-kra-install [options] [replica_file]
ipa-kra-install: error: Cannot uninstall. There is no KRA
installed on this system.
Not sure what happened there. With the latest code, that does not
appear to happen for me. Let me know if it recurs.
I tested the kra plugin with this Python script:
from ipalib import api
api.bootstrap(context='server', kra_host='localhost')
api.finalize()
api.Backend.kra.store_secret('test', 'tkey')
which gives me:
Traceback (most recent call last):
File stdin, line 1, in module
File ipaserver/plugins/dogtag.py, line 2012, in store_secret
self._setup()
File ipaserver/plugins/dogtag.py, line 1965, in _setup
connection = PKIConnection('https', self.kra_host,
self.kra_port, 'kra')
File /usr/lib/python2.7/site-packages/pki/client.py, line 36,
in __init__
self.hostname + ':' + self.port + '/' + \
TypeError: coercing to Unicode: need string or buffer, int found
Apparently, PKIConnection requires the port to be a string, but we pass
an int. I'd consider this an issue in pki.
Agreed. I will open a ticket to fix it in pki. For now though, I have
cast to str().
The kra_host='localhost' option to api.bootstrap is necessary because
kra_host is not added to default.conf on install. How is this planned to
work when the plugin is done?
I followed what was done for ca_host, but did not set the required
default in constants.py. Thats fixed, so this should work now.
After discussion with Endi, I also removed some functions in dogtag.py
(the plugin) which basically just wrapped calls to the keyclient. There
is no need to do this wrapping and it is much more flexible for IPA code
to call the keyclient directly. Accordingly, I have added a method to
get the keyclient. Your test code would look like this now:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
I added a couple of directives in the proxy file to allow it to progress
further and it now fails in trying to do the archive_key due to
authentication issues.
Did some more investigation on this. It turns out that the problem is
in the PEM file that is generated (/etc/httpd/aliad/agent.pem)
There are in fact two problems. One is that the agent.pem that is
available there is for the IPA RA agent, who is not an agent on the KRA.
Also, it appears that the PEM file itself may have some weirdness in its
format.
The PEM file is generated by the code _generate_pem_file() in dogtag.py.
That code will need to be re-examined and fixed. I would like to leave
that task to Endi - as he needs to decide how/which agent will be used
to communicate with the KRA.
If you use a valid agent PEM, then the above test code works.
Here is what I did:
$ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes
And then I ran the following without issues:
from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()
infos = keyclient.list_keys()
for info in infos.key_infos:
print {0} {1}.format(info.client_key_id, info.key_url)
keyclient.archive_key('test3
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
In Dogtag, we have decided to revert the name of the DRM to the old name KRA.
DRM was really only used in docs/marketing, whereas KRA is all over the code.
Soon, the code and the marketing/docs will match.
The following patch changes all references to the DRM to KRA.
so for example, you need to run ipa-kra-install etc.
Please apply this on top of the previous patch. I'll go ahead and squash them
before commit.
Thanks,
Ade
- Original Message -
From: Ade Lee a...@redhat.com
To: Petr Viktorin pvikt...@redhat.com
Cc: freeipa-devel@redhat.com
Sent: Wednesday, August 13, 2014 2:05:51 PM
Subject: Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
New patch attached which all the issues noted below. Rebased to master.
Please review,
Thanks,
Ade
On Mon, 2014-08-11 at 16:54 +0200, Petr Viktorin wrote:
On 08/09/2014 01:36 AM, Rob Crittenden wrote:
Ade Lee wrote:
Attached is a new patch. I believe I have addressed all the issues
raided by pviktori, edewata and rcrit.
Ar!
Please let me know if I missed something!
Incidentally, to get all this to work, you should use the latest Dogtag
10.2 build, which also contains a fix for pkidestroy that is not yet
merged in. A COPR build is currently underway at:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/24804/
Some whitespace issues:
Applying: Add a DRM to IPA
/home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing
whitespace.
This relies on the DRM client to generate a wrapping key
/home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line
at EOF.
+
warning: 2 lines add whitespace errors.
lying: Add a DRM to IPA
/home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3774: trailing
whitespace.
This relies on the DRM client to generate a wrapping key
/home/rcrit/redhat/freeipa/.git/rebase-apply/patch:3292: new blank line
at EOF.
+
warning: 2 lines add whitespace errors.
fixed
I do hope you're planning on adding a minimum build dep at some point?
yes - as soon as we have an official-ish dogtag build.
Still seeing AVCs during install:
time-Fri Aug 8 19:13:35 2014
type=SYSCALL msg=audit(1407539615.743:1503): arch=c03e syscall=1
success=no exit=-13 a0=3 a1=210cb30 a2=2d a3=7fff1caa83f0 items=0
ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994
fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295
comm=cp exe=/usr/bin/cp subj=system_u:system_r:pki_tomcat_t:s0
key=(null)
type=AVC msg=audit(1407539615.743:1503): avc: denied { setfscreate }
for pid=12307 comm=cp scontext=system_u:system_r:pki_tomcat_t:s0
tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process
time-Fri Aug 8 19:13:35 2014
type=SYSCALL msg=audit(1407539615.743:1504): arch=c03e syscall=190
success=no exit=-13 a0=4 a1=7fff1caa8590 a2=210c8f0 a3=2d items=0
ppid=12121 pid=12307 auid=4294967295 uid=994 gid=993 euid=994 suid=994
fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295
comm=cp exe=/usr/bin/cp subj=system_u:system_r:pki_tomcat_t:s0
key=(null)
type=AVC msg=audit(1407539615.743:1504): avc: denied { relabelfrom }
for pid=12307 comm=cp name=CS.cfg.bak.20140808191335 dev=dm-0
ino=430828 scontext=system_u:system_r:pki_tomcat_t:s0
tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file
time-Fri Aug 8 19:13:35 2014
type=SYSCALL msg=audit(1407539615.744:1505): arch=c03e syscall=88
success=no exit=-13 a0=7fffd3c0daa7 a1=7fffd3c0daea a2=0 a3=7fffd3c0b9b0
items=0 ppid=12121 pid=12308 auid=4294967295 uid=994 gid=993 euid=994
suid=994 fsuid=994 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295
comm=ln exe=/usr/bin/ln subj=system_u:system_r:pki_tomcat_t:s0
key=(null)
type=AVC msg=audit(1407539615.744:1505): avc: denied { create } for
pid=12308 comm=ln name=CS.cfg.bak
scontext=system_u:system_r:pki_tomcat_t:s0
tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=lnk_file
Rob, please open BZ against selinux-policy for these. Interestingly,
audit2allow doesn't provide me with any output for these AVC's.
The new estimated time was dead on :-)
There was a fairly long wait after Done configuring DRM server
(pki-tomcatd). and the install was done. I thought we always displayed
text when restarting (e.g. handled by the service wrapper) but I guess
not. It would be nice to know what is going on.
done
Re-running ipa-drm-install results in a scary error:
]# ipa-drm-install
Usage: ipa-drm-install [options] [replica_file]
ipa-drm-install: error: DRM is already installed.
Your system may be partly configured.
Run /usr/sbin/ipa_drm_install.py --uninstall to clean up.
Right, you don't want to override handle_error here. Instead, wrap the
body of run() in
try:
except:
self.log.error(self.FAIL_MESSAGE)
raise
(Yes, bare `except` and bare `raise`)
I
[Freeipa-devel] Design for new top level DN functionality in Dogtag
Design at: http://pki.fedoraproject.org/wiki/Top-Level_Tree This is a feature to change the tree structure of the Dogtag internal database so that a new top level baseDN is available. This will simplify the replication topology by allowing one to replicate all subsystems in a tomcat instance with a single replication agreement, instead of needing a separate replication agreement for each subsystem. This is a feature that I plan to start implementing very shortly for Dogtag 10.2 -- ie. within the next couple of weeks. There are implications both for IPA (and how Dogtag is deployed within IPA) as well as implications for Dogtag. Please take a look and provide comments. Thanks, Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin
I have not addressed Rob's comments here yet, but will do so in a later patch. We are most likely a couple weeks or so away from landing these patches and we can work on rejiggering/squashing them then. To help folks review the patches without getting merge issues, and so that I don't have to worry about rebases until we get closer to the time we want to commit these patches, I have exposed a repo with the patches committed so reviewers can pull the patches, or start to work with them. This is what Endi did to pull my patches: $ git remote add vakwetu git://fedorapeople.org/home/fedora/vakwetu/public_git/freeipa.git $ git checkout -b alee_0414_drm_add vakwetu/alee_0414_drm_add Note that there is a change which I am currently designing to provide a top level baseDN which will affect these patches. Ade On Thu, 2014-05-29 at 11:15 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 05/28/2014 08:48 AM, Fraser Tweedale wrote: On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote: There have been a couple of changes in the Dogtag interface, that require some changes in the IPA patches. Also, I had to add back a function in order to rebase to the latest IPA code. Most are the patches are as before, attached to this email by default. The latest Dogtag 10.2 build with the relevant changes needed to work with these patches is at: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ Ade ACK. ipa-server-install worked fine for me, and the formatting changes seem good. Patch 0003 did not apply cleanly on master (due to minor conflict in 71c6d2f:installutils.py); an updated patch 0003 is attached. Hello, If you do a rebase, could you attach all the patches again? I don't have the Git objects that result from the original patch, so `git am` fails on the later patches: $ git am -3 *.patch Applying: Add a DRM to IPA Applying: Added ipa-drm-install Applying: Fix various pep 8 issues and comments from review Applying: Added nolog to pkispawn and some additional fixes from review. Applying: Added dogtag plugin for DRM Applying: set drm to not install by default with ipa-server-install Applying: Allow ipa-replica-install to be used for installing replicas error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b for 'install/tools/ipa-replica-install' fatal: git-write-tree: error building trees Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0007 Allow ipa-replica-install to be used for installing replicas The copy of the patch that failed is found in: /home/pviktori/freeipa/.git/rebase-apply/patch When you have resolved this problem, run git am --continue. If you prefer to skip this patch, run git am --skip instead. To restore the original branch and stop patching, run git am --abort. I needed to rebase patche 9 as well as it contained a duplicate function, check_entropy. No need to rebase it again yet as we have to wait to push these until after a future branch anyway. Speaking of patch 9, it appears to be all formatting and spelling fixes, not all related to the DRM. Patch 4 does similar work. If we're going to commit these all separately anyway, is it worthwhile to combine these two? Something (or someone) is mighty picky about thru vs through too :-) The DRM patches should all have a ticket referenced. At a minimum the first one (0002 in this case). I think 0007 can be rebased into an existing patch unless we want to record in history that the default stance changed. Found a place that needs a change. The script install/restart_scripts/renew_ca_cert handles fixing the trust on the audit cert after renewal. This needs to update the DRM audit cert trust as well. Be aware that Honza is making significant changes to this area. Otherwise looks ok to me. I'm not super-firm on squashing some of the patches, I just don't know what historical benefit might be gained from keeping them separate. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] new developer; development environment
Welcome Fraser, To build dogtag, you should start here: http://pki.fedoraproject.org/wiki/Building_Dogtag_10 and I happen to know you'll be working on IPA/PKI stuff, you'll be interested in reviewing the links under: http://pki.fedoraproject.org/wiki/Dogtag#Resources_for_Client_Developers The PKI build does not require root. Just make sure you have the sudo access required to install the prerequisites. Ade On Wed, 2014-04-30 at 16:21 +1000, Fraser Tweedale wrote: Hi all, Fraser Tweedale, brand new Red Hatter, working in the Brisbane office on FreeIPA/Dogtag, and needing the wisdom of seasoned IPA developers on how best to set things up. In particular, is it common to be developing in VMs, and if so, do the various components (DS, Dogtag, IPA etc) under (or involved in) development reside on the same host? Are there any developer images that are ready to roll? Or if it is more common to simply develop on one's workstation directly, do you have any tips to doing this sanely? freeipa seemed find to build but the pki build seems to want root, which scares me a little... but perhaps I am just Doing It Wrong. Thanks in advance for any advice, and I look forward to getting to you know you all. Cheers, Fraser ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin
I have attached a patch that contains code for the new dogtag DRM plugin vault functionality. This patch should be applied on top of the ones used to install a DRM. Forthcoming is a patch to actually start using this plugin. Ade From cff819f1446492e3ab8cc151d2a8221475155ac9 Mon Sep 17 00:00:00 2001 From: Ade Lee a...@redhat.com Date: Wed, 30 Apr 2014 11:35:00 -0400 Subject: [PATCH 6/6] Added dogtag plugin for DRM This is an initial commit providing the basic vault functionality. This plugin will likely be modified as we create the code to call some of these functions. --- ipaserver/plugins/dogtag.py | 336 ++-- 1 file changed, 262 insertions(+), 74 deletions(-) diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index 123c2d54a73e552a5db0cb46da8b232271875f3c..ae5bc2da112c83d2a7ffc584955fd2a7a02a9b3f 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1,10 +1,11 @@ # Authors: +# Ade Lee a...@redhat.com # Andrew Wnuk aw...@redhat.com # Jason Gerard DeRose jder...@redhat.com # Rob Crittenden rcritten@@redhat.com # John Dennis jden...@redhat.com # -# Copyright (C) 2009 Red Hat +# Copyright (C) 2014 Red Hat # see file 'COPYING' for use and warranty information # # This program is free software; you can redistribute it and/or modify @@ -34,7 +35,7 @@ variety of names, the open source version is called dogtag. CMS consists of a number of servlets which in rough terms can be thought of as RPC commands. A servlet is invoked by making an HTTP request to a specific URL -and passing URL arguments. Normally CMS responds with an HTTP reponse consisting +and passing URL arguments. Normally CMS responds with an HTTP response consisting of HTML to be rendered by a web browser. This HTTP HTML response has both Javascript SCRIPT components and HTML rendering code. One of the Javascript SCRIPT blocks holds the data for the result. The rest of the response is derived @@ -42,13 +43,13 @@ from templates associated with the servlet which may be customized. The templates pull the result data from Javascript variables. One way to get the result data is to parse the HTML looking for the Javascript -varible initializations. Simple string searchs are not a robust method. First of +variable initializations. Simple string searches are not a robust method. First of all one must be sure the string is only found in a Javascript SCRIPT block and not somewhere else in the HTML document. Some of the Javascript variable initializations are rather complex (e.g. lists of structures). It would be hard to correctly parse such complex and diverse Javascript. Existing Javascript parsers are not generally available. Finally, it's important to know the -character encoding for strings. There is a somewhat complex set of precident +character encoding for strings. There is a somewhat complex set of precedent rules for determining the current character encoding from the HTTP header, meta-equiv tags, mime Content-Type and charset attributes on HTML elements. All of this means trying to read the result data from a CMS HTML response is @@ -119,7 +120,7 @@ values. Python also nicely handles type promotion transparently between int and long objects. For example if you multiply two int objects you may get back a long object if necessary. In general Python int and long objects may be freely mixed without the programmer needing to be aware of which type of -intergral object is being operated on. +integral object is being operated on. The leads to the following rule, always parse a string representing an integral value using the int() constructor even if it might have large @@ -229,7 +230,7 @@ as a dict via the 'namespaces' keyword parameter of etree.XPath(). The predicate for the second location step uses the 're:' namespace to find the function name 'match'. The re:match() takes a string to search as its first argument and a regular expression pattern as its second argument. In this example the string -to seach is the node name of the location step because we called the built-in +to search is the node name of the location step because we called the built-in node() function of XPath. The regular expression pattern we've passed says it's a match if the string begins with 'chapter' is followed by any number of digits and nothing else follows. @@ -260,6 +261,7 @@ CMS_STATUS_REJECTED = 5 CMS_STATUS_ERROR= 6 CMS_STATUS_EXCEPTION= 7 + def cms_request_status_to_string(request_status): ''' :param request_status: The integral request status value @@ -290,7 +292,7 @@ def parse_and_set_boolean_xml(node, response, response_name): ''' :param node: xml node object containing value to parse for boolean result :param response: response dict to set boolean result in -:param response_name: name of the respone value to set +:param response_name: name of the response value
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
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.
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
From fa31152ca6ff6bf5d6401b7bcf726a65e3904835 Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Tue, 15 Apr 2014 14:09:32 -0400
Subject: [PATCH] Added ipa-drm-install
ipa-drm-install can be used (with no arguments) to
add a DRM to an existing ipa instance that already contains
a Dogtag CA.
In a subsequent patch, I will add logic to this script to
detect if a drm naming context exists, and if so, to look for
a replica file for installing on a replica.
---
freeipa.spec.in | 2 +
install/po/Makefile.in| 1 +
install/tools/Makefile.am | 1 +
install/tools/ipa-dns-install | 1 +
install/tools/ipa-drm-install | 196 ++
install/tools/ipa-upgradeconfig | 67 +
ipaserver/install/drminstance.py | 4 +
ipaserver/install/dsinstance.py | 77 +++
ipaserver/install/installutils.py | 25 +++--
9 files changed, 297 insertions(+), 77 deletions(-)
create mode 100644 install/tools/ipa-drm-install
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 8ae5e2e083e960c034c738b01d0655575253b6f7..bff9c1acc957dd2d963e15d4c4928f61e37f1d7c 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -143,6 +143,7 @@ Requires: selinux-policy = 3.12.1-135
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.47.7
Requires: pki-ca = 10.1.1
+Requires: pki-kra = 10.1.1
Requires: dogtag-pki-server-theme
%if 0%{?rhel}
Requires: subscription-manager
@@ -622,6 +623,7 @@ fi
%{_sbindir}/ipa-restore
%{_sbindir}/ipa-ca-install
%{_sbindir}/ipa-dns-install
+%{_sbindir}/ipa-drm-install
%{_sbindir}/ipa-server-install
%{_sbindir}/ipa-replica-conncheck
%{_sbindir}/ipa-replica-install
diff --git a/install/po/Makefile.in b/install/po/Makefile.in
index 6dca615c13acf8d40030da0318a1103f4ece1181..c8d7b6353e2b2b00f6e9e6f8cfe3bcc8f84ae73f 100644
--- a/install/po/Makefile.in
+++ b/install/po/Makefile.in
@@ -47,6 +47,7 @@ PY_EXPLICIT_FILES = \
install/tools/ipa-csreplica-manage \
install/tools/ipactl \
install/tools/ipa-dns-install \
+ install
Re: [Freeipa-devel] Random Certificate Serial Numbers
On Mon, 2014-04-07 at 09:48 +0200, Martin Kosek wrote: Hi Rob, Ade and others, In the past, Rob was investigating enabling random certificate serial numbers for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. Can we simply switch it on for PKI with pkispawn attribute: [CA] pki_random_serial_numbers_enable=True Putting in this parameter in pkispawn means changing the method of assigning serial numbers for the CA that is being installed (ie. a new master) Thus this will affect new masters only. When the CA is cloned, it will inherit its method of assigning serial numbers from the master. I need to check the code to see what happens if you specify the above directive in pkispawn for a clone. Are you considering changing the serial number assignment for existing masters? or is there any drawback or risk we should investigate. I am just thinking, does PKI handle collisions anyhow? When for example two PKI masters generate 2 certificates of the same serial (unlikely though it could happen)? Collisions are not supposed to happen. Range number assignment is automatically managed so that different masters are assigned different ranges so that collisions cannot happen. Collisions can occur if ranges overlap -- ie. if you are manually updating ranges and end up using overlapping ranges. Currently, we assign different slice of serial range to different PKI masters, do we want to do that also for random serial? Yes. Range management is done automatically. Different masters are assigned different ranges to prevent collisions. Random serial numbers will be generated within the assigned range. Thanks for info [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers [2] https://fedorahosted.org/freeipa/ticket/2016 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
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? This error is unlikely to have any real effect because when connecting to the database using client auth, we determine how to connect to the database through the parameter that defines the certificate nickname. So we're probably fine with just changing it in master. 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? The code I wrote presupposes this - but this is something that needs to be decided by IPA. Now given that the DRM is going to use the same tomcat instance and database as the CA - and given that we are probably going to want to have a DRM when we start issuing user certs, I see no reason not to add a DRM when we add a CA. To miminize complexity, I would suggest that we keep the requirement that DRM requires Dogtag CA. 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. For noted above, because we will likely want DRM for user certs, I would suggest that DRM be installed by default when we install a Dogtag CA. As far as package dependencies, there are in fact very few additional dependencies for the DRM as most of the Java code is in common libraries already required by the CA. In fact, there is only one new package pki-kra, which contains a few KRA specific java classes. 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. This initial patch was to get things working and start some of these discussions. As we consider adding additional subsystems like the TKS and TPS, having some common ground will make things simpler to maintain. I will look into abstracting to reduce code duplication. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Add DRM to IPA
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 From 298aa20b554b5e17a0f7a1d4cf13e246fba9c8dc Mon Sep 17 00:00:00 2001 From: Ade Lee a...@redhat.com Date: Tue, 18 Mar 2014 11:23:30 -0400 Subject: [PATCH] Add a DRM to IPA 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. --- install/conf/ipa-pki-proxy.conf | 4 +- install/tools/ipa-replica-install| 29 +- install/tools/ipa-server-install | 36 +- ipapython/dogtag.py | 1 + ipaserver/install/cainstance.py | 4 +- ipaserver/install/drminstance.py | 642 +++ ipaserver/install/installutils.py| 17 + ipaserver/install/ipa_replica_prepare.py | 1 + 8 files changed, 722 insertions(+), 12 deletions(-) create mode 100644 ipaserver/install/drminstance.py diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 224cdd45b5b5f72671a179570fd15772fe8cfaab..9a6345898bfa017da03bf108a82c3639edbb0470 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -11,7 +11,7 @@ ProxyRequests Off /LocationMatch # matches for admin port and installer -LocationMatch ^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken|^/ca/admin/ca/updateNumberRange|^/ca/rest/securityDomain/domainInfo|^/ca/rest/account/login|^/ca/admin/ca/tokenAuthenticate|^/ca/admin/ca/updateNumberRange|^/ca/admin/ca/updateDomainXML|^/ca/rest/account/logout|^/ca/rest/securityDomain/installToken +LocationMatch ^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken|^/ca/admin/ca/updateNumberRange|^/ca/rest/securityDomain/domainInfo|^/ca/rest/account/login|^/ca/admin/ca/tokenAuthenticate|^/ca/admin/ca/updateNumberRange|^/ca/admin/ca/updateDomainXML|^/ca/rest/account/logout|^/ca/rest/securityDomain/installToken|^/ca/admin/ca/updateConnector|^/ca/admin/ca/getSubsystemCert|^/kra/admin/kra/updateNumberRange|^/kra/admin/kra/getConfigEntries NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:$DOGTAG_PORT @@ -19,7 +19,7 @@ ProxyRequests Off /LocationMatch # matches for agent port and eeca port -LocationMatch ^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient +LocationMatch ^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:$DOGTAG_PORT diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index f5e7197b5c2f03b0b070a33761debcc07a9c..70a9cb21bd48a1fbcd56c30e1f4089172f639f90 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -38,9 +38,10 @@ from ipaserver.install import
[Freeipa-devel] Announcing the release of Dogtag 10.1
The Dogtag team is proud to announce the release of Dogtag v10.1.0.
This release is being released in conjunction with the GA release of
Fedora 20.
Due to changes in the way tomcat is started in Fedora 20, and the
corresponding changes in the Dogtag init scripts, Dogtag 10.1 will only
be delivered from Fedora 20 upwards. Dogtag 10.0 will continue to be
delivered and supported for Fedora 18 and 19.
== Build Versions ==
pki-core-10.1.0-1.fc20
pki-ra-10.1.0-1.fc20
pki-tps-10.1.0-1.fc20
dogtag-pki-10.1.0-1.fc20
dogtag-pki-theme-10.1.0-1.fc20
pki-console-10.1.0-1.fc20
== Upgrade Notes ==
Upgrade from Dogtag 10.0 to Dogtag 10.1 should be seamless, with all
relevant migration steps performed by upgrade scripts when the packages
are installed. Simply follow the standard procedure for upgrading from
Fedora 19 to Fedora 20. http://fedoraproject.org/wiki/Upgrading
== Highlights since Dogtag v. 10.0 ==
Infrastructure/ Version Changes:
* pylint was added to the build scripts, and any pylint errors
and warnings in the python code were fixed. The build now fails
if any new errors or warnings are generated.
* RESTEasy was updated from version 2.3.2 to 3.0.1. As part of this
transition, some server code (the interceptors) was modified to
implement JAX-RS 2.0.
* In Fedora 20, tomcat has changed to more properly use systemd unit
files to start up, rather than system V init scripts.
(https://bugzilla.redhat.com/show_bug.cgi?id=842346)
As a result, new Dogtag systemd unit files (based on the tomcat unit
files) were required. This change is the primary reason Dogtag 10.1
cannot be deployed in Fedora versions 20.
New Testing Framework:
A new test framework was added to the upstream git source tree. This
framework can be used to do standalone tests or as part of a continuous
integration testing framework. This framework includes:
* QE tests are added to upstream git as part of this release. These
tests use the beaker libraries to generate results and are run in a
beaker test bed.
* A mechanism for writing JUnit tests, with some sample tests. These
tests can be run through eclipse on a local test environment or run
along with the QE tests on a beaker machine. Customized Suite and
RunNotifier classes are provided to generate the results using beaker
libraries in place of the actual JUnit result.
* The README file in tests/dogtag provides information on how to run
the tests.
REST interface enhancements:
* The interface has been updated to use standard HTTP return codes
under various operations. Paging support has been added to most
search operations.
* New REST interfaces have been added for managing certificate profiles
on the CA. This includes:
* Methods to list, add, remove, edit, enable/disable profiles. These
methods are protected by ACLs that limit authorization to agents or
administrators as appropriate.
* Extensions to the pki CLI tool to perform all the above operations.
* A new method to provide enrollment templates to end-entity users
for specific profiles. An enrollment template is a certificate
request representation that contains all the required inputs for a
given profile. End entity users can list available profiles by
calling GET /certrequests/profiles, and fetch an enrollment
template by navigating to GET /certrequests/profiles/{id}.
DRM Enhancements:
* Audit logging has been added to the REST interfaces for key archival
and recovery.
* REST interface for asymmetric key retrieval provides ability to
submit key recovery requests, approve them, and retrieve keys
approved for recovery.
* Transport Key rotation provides ability to gradually migrate DRM and
connected CAs from a current to a new transport key. It also
provides support for simultaneous use of both transport keys.
New Stand-alone DRM:
* It is now possible to deploy a stand-alone DRM through pkispawn.
* Dogtag subsystems such as a DRMs have always required the presence of
a Dogtag Certificate Authority (CA) to be part of a PKI deployment. A
stand-alone DRM uses an external CA to obtain its system
certificates, such that the DRM can be set up without a Dogtag CA in
its PKI deployment. The DRM is not expected to communicate with any
other PKI subsystems (with the exception of its clones, which will be
implemented in a future release).
Potential users of this feature include CA-less IPA installation
and storage of secrets, and possible integration with CloudKeep.
New Java-Based TPS:
* We have begun an effort to re-implement the TPS subsystem (which is
currently written as C/C++ Apache modules) in Java. The new
tomcat-tps will run in a Tomcat server like the other Java
subsystems, either within the same or in a separate Tomcat instance.
There are many steps in this effort, detailed below. As of this
release, steps 1,2 and the design phase of step 3 are complete. The
[Freeipa-devel] Announcing the release of Dogtag 10.0.6
The Dogtag team is proud to announce the sixth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. Karma can be provided at https://admin.fedoraproject.org/updates for each package. == Build Versions == pki-core-10.0.6-1 pki-ra-10.0.6-1 pki-tps-10.0.6-1 dogtag-pki-10.0.6-1 dogtag-pki-theme-10.0.6-1 pki-console-10.0.6-1 == Highlights since Dogtag 10.0.5 == * Some commands in the pki CLI have been renamed for better consistency. The old commands will continue to work, but they have no been deprecated, and will be displayed accordingly in the usage and man pages. The commands that have been renamed are: * old command- new command * client-find-cert - client-cert-find * client-import-cert - client-cert-import * client-remove-cert - client-cert-del * group-add-member - group-member-add * group-find-member - group-member-find * group-show-member - group-member-show * group-remove-member- group-member-remove * user-add-cert - user-cert-add * user-find-cert - user-cert-find * user-show-cert - user-cert-show * user-remove-cert - user-cert-del * user-add-membership- user-membership-add * user-find-membership - user-membership-find * user-show-membership - user-membership-show * user-remove-membership - user-membership-del * The upgrade scripts have been modified to backup the files used to track the upgrade process. For instance specific upgrade scripts, this is CS.cfg. * A missing jar link to apache-commons-io prevented IPA replica installs from completing successfully on RHEL 7. The required link has been added. (BZ 1024679) * Due to a bug in the configuration code, when installing a non-cloned CA, the certificate for the admin user configured during the install was signed with SHA1 by default. With the fix, the admin cert is signed with SHA256 by default. It is possible to override this setting by changing values in the caAdminCert.cfg profile prior to configuration. (BZ 1024445) * ipa-cert-remove-hold non_existent_cert_id used to return a server error. The error handling code for this servlet has been modified to return the correct error message (BZ 999722) * java-abrt crashes were being generated during IPA server installs due to exceptions being thrown during tomcat shutdown. This was due to the shutdown code being called multiple times internally. This code has been fixed. (BZ 1018268) == Detailed Changes since Dogtag 10.0.5 == alee (3): #743fix tmpfiles.d references in spec files to reference /run/lock instead of /var/lock #776IPA CA replica installation crashes on pkispawn (bz 1024679) #781Admin cert signed with SHA1, should be SHA256 (bz 1024445) edewata(5): #779Renaming Dogtag 10.0 pki commands #763Backup tracker files during upgrade #775Fix errors during tomcat shutdown (BZ 1018628) #739ipa-cert-remove-hold non_existent_cert_id returns server error (BZ 999722) #780Unable to get user principal in servlet ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing the release of Dogtag 10.0.5
The Dogtag team is proud to announce the fifth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. Karma can be provided at https://admin.fedoraproject.org/updates for each package. == Build Versions == pki-core-10.0.5-1 pki-ra-10.0.5-1 pki-tps-10.0.5-1 dogtag-pki-10.0.5-1 dogtag-pki-theme-10.0.5-1 pki-console-10.0.5-1 == Highlights since Dogtag 10.0.4 == * Due to changes in systemd, restarting Dogtag 10 instances using systemctl restart pki-tomcatd.target failed. Changes have been made to the systemd startup configuration to ensure that this works correctly. In addition, configuration has been added to require systemd to accept an exit status of 143 (a correct exit status for the JVM) as valid, so this exit value will no longer be reported in the system logs. * Due to changes in the python-requests, a new exception (ProxyError) was returned when attempting to connect to a server that is not yet available. This affected pkispawn installation code when we wait for a server to restart. The code has been modified to handle this (and other) exceptions. * In a case following a bad restart, the CS.cfg for an instance appeared to be cleared or truncated. The code has been changed to not write server status to the CS.cfg on startup, but rather to use an in-memory variable. * Fixed LDAP search filter code to no longer return certificates expired for both reason 1 and reason 10 when searching only for reason 1. == Detailed Changes since Dogtag 10.0.4 == alee (5): #712pki cert-find --revocationReason 1 finds certs expired for reason 1 and reason 10 #714CS.cfg cleared #716pki-tomcatd@pki-tomcat.service does not start when pki-tomcatd.target is started #717Proxy error while getting status when spawning CA #719Incorrect value in CS,cfg for manager.ldif location ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA and Dogtag support for User Certificates in OpenStack Keystone
On Mon, 2013-08-26 at 12:38 -0400, Adam Young wrote: Keystone needs signing certificates for Signing PKI tokens. In addition, CERN has a developed an approach that allows user to authenticate to Keystone via X509 for batch jobs. This requires Client Certs. Both of these use cases are easily supported by Dogtag, but not exposed via FreeIPA yet. The easiest path forward is to open up direct access to the Dogtag REST APIs. In this case, the work flow would be: User sends CSR to Dogtag Agent approves User fetches signed certificate User uploads to IPA I can see a couple ways of implementing this. Scenario A: (similar to current implementation) 1. User logs into IPA UI/CLI using Kerberos and IPA server obtains all the relevant information needed to create the CSR. 2. IPA agent sends the request to dogtag specifying the relevant profile. This should be done using the new REST API. There are fields in the request to specify the requester name etc. Any Kerberos/CSR info validation should be done by IPA. 3. Dogtag gets the request and puts it in a queue for agent approval. By default, anyone can submit a cert request - but I see no reason not to use the ipa-agent. 4. Certificate Agent -- and by this I mean users which have added to the dogtag database and to the relevant agent groups using the REST API - looks at their queue and selects and approves the request. 5. Dogtag issues the cert. An LDAP publisher is pre-configured on the dogtag instance to publish the issued certificate to the user's entry in the IPA subtree. The user's entry DN is created by mapping from attributes in the subject name. The format of the mapper can be configured. Now all of the above requires changes mostly on the IPA side. IPA will need to add UI/interfaces to display request queues, requests etc. as well as the ability to add agents to dogtag. We could make this easier by allowing agents to pass directly to the dogtag UI and expose the dogtag UI as part of the IPA UI. We are planning a similar kind of thing for the token management in the near term. For this to happen, we likely need the following: 1. Kerberos realm to be added to dogtag to allow Kerb authentication. This is planned for token management. 2. IPA dogtag theme so that the change in UI experience is not too jarring. For agents, this is not a bad approach. End users could also be exposed to the dogtag UI, but given that you want to do some validation/ specification of the subject DN, its probably easier to do this on the IPA side. For CLI of course, it is possible to use the REST interfaces directly or call the new pki CLI - which uses the new RESt interfaces. The questions I have relate to Dogtag/IPA integration: All actions to Dogtag shuld be via mod_nss secured with Kerberos. Does this tie in with Dogtag, or would Dogtag require Client Side Certificate validation? Right now, dogtag requires client cert validation. We will be adding a Kerb realm in future though. Remember though that only agents and admins are agent have user entries in Dogtag. Even with Kerberos authentication, there is still no cross reference between the Kerberos Principal and the CSR Subject. Is this a problem? As mentioned above, its probably better to do any vaslidation on the IPA side. I thought there was a custom Tomcat Realm for integrating with Kerberos. If so, does this expose the correct data to check the Subject in the CSR? As noted above, the EE pages to request a cert do not require authentication by default. We could make them require kerberos authentication and then we would be able to get the Principal information. Offhand, though, I'm not sure where we would add the logic to use this information to check the subjectDN of CSR. Might be easier to do any validations/ forming the CSR on the IPA side, and continue to restrict interactions between IPA and Dogtag to agents/admins. Are there security implications in the user uploading their own certifcates to FreeIPA's LDAP? Not to Dogtag as long as Dogtag maintains its own set of users/groups for agents and admins. Can we re-enable the Dogtag XSRF checking without breaking IPA? This is possible if certs are requested using the new REST API. So we would have to update the IPA code to do this. Does it make sense to have an extension to ipa-server-install that specifies a Keystone user that becomes a Dogtag agent, or a comparable commandline tool of the ipa-* family? Thats an IPA/ Keystone policy type question. For dogtag, all agents are equal. If we expose an URL for CSRs, that exposes the potential to request CSRs of any set of attributes. The Agent would need to be careful not to sign in appropriate requests. Is there any support for limiting the types of Requests that would be acceptable? The dogtag EE UI pages will expose only those fields that are permitted by the certificate profile. If you were to use the Dogtag EE user
[Freeipa-devel] Announcing the release of Dogtag 10.0.4
The Dogtag team is proud to announce the fourth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. == Build Versions == pki-core-10.0.4-1 pki-ra-10.0.4-1 pki-tps-10.0.4-1 dogtag-pki-10.0.4-1 dogtag-pki-theme-10.0.4-1 pki-console-10.0.4-1 == Highlights since Dogtag 10.0.3 == * Enhanced pkispawn to provide automatic backup and restore mechanism for files modified during the upgrade process. * Improved the summary information at the end of pkispawn to include, among other things, the location of the agent PKCS #12 file. * Fixes to pkispawn and the installation servlets to fix cloning. * Fix to pkispawn to correctly overwrite the pki_issuing_ca when configuring with an external CA. This resolves an issue reported by IPA in BZ #986901. * Numerous fixes to resolve build issues on F19 and RHEL. == Detailed Changes since Dogtag 10.0.3 == akoneru (1): #645Display the admin p12 file location in the installation summary alee (6): #680Missing apache-commons-cli dependency #665cloning is broken for second instance in shared subsystems BZ #973224 - resteasy-base must be split into subpackages -- Add build dependency on systemd to fix build failures on f19. -- Modify pkispawn to handle case where no subsystem certs are generated -- Modify java-tools startup scripts to use correct JNI path awnuk (1): BZ #961522 - Allow key to be exported. cfu (1): BZ #971561 - server-side key generation causes NullPointerException if a parameter is not supplied by the caller (TPS) edewata (6) #582Man page for pki-upgrade #583Automatic backup and rollback on upgrade BZ #986901 - Fix confguration issues with external CA. BZ #985111 - token authentication problem on rhel -- Removing JNI_JAR_DIR from /etc/pki/pki.conf. -- Fixed library paths for RHEL. mharmsen (2): BZ #986506 - exclude pki-kra, pki-ocsp and pki-tks from rhel BZ #975939 - RHCS 8.1: END CERTIFICATE tag is not on it's own line ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed
On Mon, 2013-06-10 at 16:35 +0200, Ana Krivokapic wrote:
On 06/07/2013 10:23 AM, Tomas Babej wrote:
On 05/15/2013 01:36 PM, Ana Krivokapic wrote:
On 05/15/2013 12:29 PM, Petr Viktorin wrote:
On 05/15/2013 12:04 PM, Tomas Babej wrote:
On 05/15/2013 11:40 AM, Ana Krivokapic wrote:
Hello,
See the commit message for details.
https://fedorahosted.org/freeipa/ticket/3594
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
+def regenerate_ca_file(self, ca_file):
+dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp()
+keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp()
+
+os.write(dm_pwd_fd, self.dirman_password)
+os.close(dm_pwd_fd)
+
+keydb_pwd = ''
+with open('/etc/pki/pki-tomcat/password.conf') as f:
+for line in f.readlines():
+key, value = line.strip().split('=')
+if key == 'internal':
+keydb_pwd = value
+break
+
+os.write(keydb_pwd_fd, keydb_pwd)
+os.close(keydb_pwd_fd)
+
+ipautil.run([
+'/usr/bin/PKCS12Export',
+'-d', '/etc/pki/pki-tomcat/alias/',
+'-p', keydb_pwd_fname,
+'-w', dm_pwd_fname,
+'-o', ca_file
+])
+
If the PKCS12Export call fails (returns non-zero code), we raise
exception here, and the temporary files are never removed.
+os.remove(dm_pwd_fname)
+os.remove(keydb_pwd_fname)
This might not be a big issue since mkstemp() call creates temporary
file readable and writable only be given user ID,
however, we should not leave files with passwords in plaintext on the
disk if it is not necessary.
This can be easily prevented by wrapping the call up with
try-chatch-finally block, or using raiseonerr=False options of run
method.
Or by using ipautil.write_tmp_file() – the file it creates is always
removed after it's closed/garbage collected, and it has a name
attribute.
Updated patch uses `ipautil.write_tmp_file()`.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
I'm testing on a fairly updated F19 VM:
I'm getting the following error when preparing the replica info
file:
[root@vm-002 ~]# ipa-replica-prepare vm-003.ipa.com --ip-address
192.168.122.213
Directory Manager (existing master) password:
Preparing replica for vm-003.ipa.com from vm-002.ipa.com
Command '/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/
-p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12' returned
non
When trying that manually:
[root@vm-002 ~]# /usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/
-p /tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12
Exception in thread main java.lang.NoClassDefFoundError:
org/mozilla/jss/util/PasswordCallback
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
at java.lang.Class.getMethod0(Class.java:2694)
at java.lang.Class.getMethod(Class.java:1622)
at
sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
at
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)
Caused by: java.lang.ClassNotFoundException:
org.mozilla.jss.util.PasswordCallback
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 6 more
We might need to investigate what causes this, and if the issue is
not on our side, file appropriate bugs.
Tomas
This is an bug in the PKCS12Export utility. I opened a Bugzilla for
it: https://bugzilla.redhat.com/show_bug.cgi?id=972753.
Below is a workaround, as suggested by Ade:
alee as for a workaround, you could simply edit the file that starts
PKCS12Export
alee edit /usr/bin/PKCS12Export
alee after line 134, simply add the line :
CP=/usr/lib/java/jss4.jar
alee but thats just a temp fix for f19 only
alee not the real fix,
alee you'll need the real fix checked in to pass the patch
Just FYI, we plan to do a new release of pki-core today
(pki-core-10.0.3-2) to address this issue.
--
Regards,
[Freeipa-devel] Announcing the release of Dogtag 10.0.3
The Dogtag team is proud to announce the third errata build for Dogtag v10.0.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. == Build Versions == pki-core-10.0.3-1 pki-ra-10.0.3-1 pki-tps-10.0.3-1 dogtag-pki-10.0.3-1 dogtag-pki-theme-10.0.3-1 pki-console-10.0.3-1 == Highlights since Dogtag v. 10.0.2 == * Fixes for security flaws in the TPS as described in CVE-2013-1885 and CVE-2013-1886 * Added checking for sane lengths of the fields in subject DNs in the TPS, to prevent a TPS crash. * Previously the server certificate name was partially hard-coded. Now in Tomcat-based subsystems, it can be fully configured using pki_ssl_server_nickname parameter. * Corrections and additions to man pages and other documentation. == Detailed Changes since Dogtag v. 10.0.2 == akoneru (1): #599 Improve pkispawn Installation Summary block alee (1): #486 Document migration steps for dogtag 9 - dogtag 10 instances awnuk (4): #607 Port plug-in randomizing validity #571 Port patch allowing to include in CRLs NextUpdate calculated base on ThisUpdate BZ 951501 - correcting JavaScript inability to handle big numbers BZ 966189 - fix various TPS flaws cfu (1): BZ 952500 - small patch to remove eclipse warning in fix to BZ 952500 edewata (1) #631 Hard-coded server certificate nickname. jmagne (1): BZ 963073 - rhcs81 tps crash for CN over than 64 bytes mharmsen (3): #606 add restart/start at boot info to pkispawn man page #610 Document limitation in using GUI install #629 Package ownership of '/usr/share/pki/etc/' directory ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing the release of Dogtag 10.0.2
The Dogtag team is proud to announce the second errata build for Dogtag v10.0.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repo. Please try it out and provide karma to move them to the F18 and F19 stable repos. Daily developer builds for Fedora 17, 18 and 19 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.2-2 pki-ra-10.0.2-2 pki-tps-10.0.2-2 dogtag-pki-10.0.2-1 dogtag-pki-theme-10.0.2-1 pki-console-10.0.2-2 == Highlights since Dogtag v. 10.0.1 == * A new Python client framework has been written to connect to the restful interface on the java subsystems. This interface was used for some installation functionality and will continue to be expanded. * pkispawn and pkidestroy were modified to use the new Python client framework and the dependency on jython was eliminated. * The installation interfaces were changed so that most of the installation interactions take place over the admin interface. * New command line parameters have been added to pkidestroy to provide the username and password of the security domain administrator to update the security domain. Formerly, no credentials were required because we used the subsystem certificate of the subsystem for authentication. The new method provides better auditing as to exactly who is de-registering and removing a subsystem. As such, use of the new options is recommended, and will be made mandatory in a future release. * Although it is possible to run Dogtag 9 style instances on Dogtag 10, these instances do not have the required configuration to expose the RESTful interface. A new servlet has been added to return 501 (Not implemented) on these instances when the REST URLs are accessed. This is only applicable on Fedora 18 (See Fedora 19 note below). * A new interactive mode has been added to pkispawn and pkidestroy. In this mode, users are prompted for details in order to set up the most basic servers. Any customizations would still need to be done through configuration files. Interactive mode is an excellent way for users to set up a server and become familiar with Dogtag. * Support has been added for the random generation of serial numbers for certificates issued. More details about this feature and how to enable it can be found here: http://pki.fedoraproject.org/wiki/Random_Certificate_Serial_Numbers * Nonces are used in Dogtag to prevent cross-site request forgery and replay attack, but they were stored in a global list. To prevent possible collisions with other user's nonces, they are now stored in each user's session. * Previously, session IDs were generated using /dev/random, which may block under certain circumstances, making server startup slow. To avoid this, the server configuration has been changed to use PKCS11PRNG provided by JSS. * A new upgrade framework has been added to allow instances to be automatically upgraded when new packages are installed. This framework will be used to eventually remove the need for migrations between releases. The upgrade scripts are invoked by postinstall scriptlets in the pki-base and pki-server packages. On completing an upgrade, users should check the upgrade logs in /var/log/pki/pki-upgrade-*.log and /var/log/pki/pki-server-upgrade-*.log for any errors. The upgrade scripts (pki-upgrade and pki-server-upgrade) can also be run manually. Additional troubleshooting information can be found at: http://pki.fedoraproject.org/wiki/Upgrade * New CLI has been added to simplify client certificate management including importing and trusting CA certificates. * Previously, the pki CLI tool used the same parameter (-w) to specify both user and client certificate database passwords. The CLI has been modified to use a new parameter (-c) for the database password, and -w for the user password. * Multiple additional fixes to pkispawn, pkidestroy, pki and their man pages. == Notes on Fedora 19 == Fedora 19 does not provide tomcat 6. Dogtag 9 style instances will therefore no longer work on Fedora 19. These instances need to be migrated to Dogtag 10. To prevent inadvertently disabling Dogtag instances, code has been added to prevent upgrades to Fedora 19 if Dogtag 9 instances exist. Details on how to upgrade Dogtag 9 instances and workarounds can be found at: http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10 == Detailed Changes since Dogtag v. 10.0.1 == akoneru (23): #191 Map REST exceptions to HTTP status codes #217 CLI should display message on operations that complete with error #290 Add hints to option descriptions for cert-find cli command #383 Extend coverity tests to scan other subsystems (TPS, etc.) #452 Dogtag 10: Fix minor RA and TPS Configuration Wizard Panel issues #465 Verify 'pki_backup_keys=True' if 'pki_backup_password'is set #470 Prevent concurrent execution of pkispawn/pkidestroy #471 Update man pages for interactive pkispawn/pkidestroy #493 interpolation in
[Freeipa-devel] [Fwd: [Pki-devel] Announcing the release of Dogtag 10]
---BeginMessage--- The Dogtag team is proud to announce the release of Dogtag v10.0.0. This release is being bundled with the GA release of Fedora 18, and marks the culmination of over a year of development by the Dogtag team. == Build Versions == pki-core-10.0.0-2.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.0-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Upgrade Notes == It is possible to upgrade from a Dogtag 9 instance by first upgrading your server to Fedora 18 and then updating the Dogtag software. Existing Dogtag instances will continue to work correctly using existing instances, with the Java-based instances running on Tomcat 6. However, because the new functionality and interfaces depend on instance configuration, these will not be available to existing Dogtag 9-style instances. To take advantage of these new features, new Dogtag 10 instances should be created. Documentation will soon be provided on how to migrate a Dogtag 9 - style instance to a new Dogtag 10 instance. == Highlights since Dogtag v. 9 == Infrastructure and Development Changes: * The Dogtag code base was moved to git from svn. * Java development is now done under Eclipse. * Dogtag 10 uses its own public-facing TRAC project management system. * Improvements were made to CMake modules for Java development. * Java development uses OpenJDK 7. * Python development uses Python 2.7 and Jython 2.2. * Dogtag 10 Java-based instances run on Tomcat 7. * Dogtag 10 RA and TPS instances run on Apache 2.4. Refactoring and Cleanup: * Code has been reformatted to uniform formatting and coding standards. * Based on feedback provided by Eclipse and Coverity, the following types of cleanup occurred: ** Removal of dead code and unnecessary code blocks. ** Removal of generic containers and implementation of type safety. ** Removal/ replacement of deprecated code, with the addition of JUnit tests to confirm correctness. ** Address various memory leaks and corruption issues, coding style issues etc. * The Dogtag code pre-dates many of the modern Java utilities to do encoding, HTTP and XML parsing etc. As a result, custom code was written to do these functions. This code has been replaced with standard code, and a whole package (osutil) was eliminated. REST Interface: To allow easier and more intuitive interaction with the Dogtag servers, a new REST interface has been added. This interface is based on RESTEasy framework, a fully certified implementation of the JAX-RS specification. Clients interact with this framework using intuitive REST URLs, and using standard XML or JSON inputs. Included is a Java client proxy framework which can be used by client applications to build HTTP requests on the Dogtag servers, simply by invoking methods on the client objects. This client framework is used in the new command line interface pki as described below. The plan is to continue over time to extend the REST interface to cover all of the essential Dogtag functionality. In this release, the following functionality has been implemented: * With a CA: ** Create, review and approve certificate requests. ** List, view, revoke, hold and release certificates. ** Get installation token from security domain ** Add/remove KRA connector configuration ** Retrieve and list certificate profiles * With KRA: ** Retrieve transport certificate ** List/ archive and recover symmetric keys * With all Java systems: ** Add/Remove/Modify/View users, groups and group members ** Start system installation service Third-party Components: * Dogtag 10 includes JQuery and the Jquery.i18n.properties plug-in. CLI: * A new intuitive command line interface has been created, based on the RESTEasy client framework. This allows administrators and agents to perform all of the operations exposed by the REST interface from the command line, or from scripts. Storage of symmetric keys in the DRM: * The DRM provides secure encrypted storage for asymmetric keys. The KRA has been extended to provide a mechanism to securely archive and recover symmetric keys. This would be useful for storing disk encryption keys for instance. SELinux changes: * In Dogtag 9, we maintained a custom SELinux policy to provide mandatory access controls for interactions with the Dogtag server. In Dogtag 10, this policy has been cleaned up, simplified and integrated into the system base policy. As a result, the pki-selinux package has been retired. ECC: * In earlier releases, Dogtag only supported ECC certificate issuance when the CA was connected to an ECC-capable external crypto token. In Dogtag 10, all CS servers (CA, OCSP, DRM, TKS, TPS) can now be issued ECC certificates and run in such environment that: ** CS servers can communicate securely with ECC SSL certificates. ** Administrators and agents can access their administration ports via SSL using ECC certificates ** ECC encryption certificates can now have their private keys archived (and
[Freeipa-devel] [Fwd: [Pki-devel] Announcing Dogtag 10.0.1 for pki-core and dogtag-pki]
---BeginMessage--- The Dogtag team is proud to announce the first errata build for Dogtag v10.0.0. The only packages that are being modified are dogtag-pki and pki-core, both of which are being released as version 10.0.1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.1-1.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.1-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Highlights since Dogtag v. 10.0.0 == * Nonces have been added to the RESTful interface for certificate revocation to preventing cross site scripting attacks on that interface. * A new servlet has been added to the RESTful interface to add and remove KRA connector configuration from a CA. This is used to clean up a CA when a KRA is destroyed. * The default validity of the CA signing cert has been lengthened from 8 to 20 years. * pkispawn has been modified to allow the user to specify the location of the generated admin cert PKCS#12 file. * OCSP now supports ECC CRLs. * A more robust use of interpolation has been added to pkispawn. * pkidaemon has been repaired to display the runtime status of PKI Java-based instances * A third-party license file has been added for Dogtag 10's use of JQuery and the JQuery.i18n.properties plug-in == Detailed Changes since Dogtag v. 10.0.0 == alee (12): - TRAC Ticket 367 - pkidestroy does not remove connector - Fix spec file to allow f17 to work with latest tomcatjss - TRAC Ticket 466 - Increase root CA validity to 20 years - TRAC Ticket 437 - Make admin cert p12 file location configurable - TRAC Ticket 393 - pkispawn fails when selinux is disabled - Punctuation and formatting changes in man pages - TRAC Ticket 436 - Interpolation for pki_subsystem - TRAC Ticket 433 - Interpolation for paths - TRAC Ticket 435 - Identical instance id and instance name - TRAC Ticket 406 - Replace file dependencies with package dependencies - Revert to using default config file for pkidestroy - Hardcode setting of resteasy-lib for instance cfu (1): - Bugzilla Bug 839426 - [RFE] ECC CRL support for OCSP edewata (3): - TRAC Ticket 214 - Missing error description for duplicate user - TRAC Ticket 213 - Add nonces for cert revocation - TRAC Ticket 191 - Mapping HTTP Exceptions to HTTP error codes mharmsen (4): - TRAC Ticket #430 - License for 3rd party code - TRAC Ticket 469 - Fix tomcatjss issue in spec files - TRAC Ticket 468 - pkispawn throws exception - TRAC Ticket 271 - Dogtag 10: Fix 'status' command in 'pkidaemon' ___ Pki-devel mailing list pki-de...@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel ---End Message--- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0043 Allow-PKI-CA-Replica-Installs-when-CRL-exceeds-default
On Wed, 2012-12-19 at 21:35 -0500, Simo Sorce wrote: On Wed, 2012-12-19 at 22:41 +, JR Aquino wrote: On Dec 19, 2012, at 2:32 PM, Simo Sorce wrote: On Wed, 2012-12-19 at 20:52 +, JR Aquino wrote: Due to a limitation with 389 DS, the nsslapd-maxbersize cannot be set dynamically. This causes an issue during IPA PKI-CA Replica installs, when the master has a CRL that exceeds the default limit. The cainstance.py code attempts to set this value prior to performing the initial PKI-CA replication, however, since the value cannot be set dynamically, the installation fails. This patch works around the issue by adding the ldif to the original initialization values bootstrapped by the call to setup-ds.pl Why are we not simply restarting the instance after setting the value ? What's in database.ldif ? What produces it ? /usr/share/pki/ca/conf/database.ldif is part of the dogtag installation and it contains the following entry: dn: cn=config changetype: modify replace: nsslapd-maxbersize nsslapd-maxbersize: 209715200 It's purpose is to increase the limit for maxbersize from 2097152 to 209715200. The ldif is inserted via the jars that are wrapped by pkisilent... So this leaves 3 options: #1 Add code to perform the ldap insert followed by a dirsrv restart into the cainstance.py code #2 Add recode the jar files from DogTag to require a dirsrv restart after the insert, but prior to the replication #3 Just initialize the dirsrv database with the correct value to begin with. 1 line fix #4 Ask 389 to allow maxbersize to be a dynamically initialized variable #3 Seemed the path of least resistance. I did take the time to code #1 and verify that it worked as well. I have a ticket open for #4 Alee hinted that the jar modifications for #2 might not be trivial... Method #3 is ok, but for master, where we have unified ds instances, you should look at doing ti as we do change other similar attributes in install/updates/10-config.update so that older installations are updated as well. If you do it only at install and the CRL grows later you'd get older server start choking because they have not been updated. Are you referring to masters which have been converted from non-unified DS to a single DS using an as-yet-to-be-written script? The ldif change mentioned above is already performed as part of the dogtag install. For a freshly installed master, there is no large CRL to break the installation. In the replica scenario, this change is needed before we attempt replication because the large CRL breaks replication. In fact, if that value had not been set on the master, there would be no large CRL to cause replication problems. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [Fwd: Announcing Dogtag 10.0 Release Candidate 1]
---BeginMessage--- The Dogtag team is proud to announce version Dogtag v10.0.0 Release Candidate 1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-2.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.0-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Highlights since Dogtag v. 10.0.0 beta 2 (Oct 30 2012) == * Simplified and enhanced pkispawn. ** Added detailed man pages to document use of pkispawn, pkidestroy and the command line utility pki. ** Removed --dry-run option and unused respawn() code. ** Replaced links of scriptlets with lists ** Modified the way pkispawn parses configuration files. pkispawn now reads a template file for default settings, and a much smaller and simpler user-defined configuration file for customizations and overrides. Moreover, pkispawn uses interpolation to substitute in values. See the man pages for details. ** Added the ability to import an admin cert into the administrative user created for each subsystem. This allows multiple subsystems within the same instance to be more easily managed within the same browser. ** Implemented ability to install a subordinate CA using pkispawn. ** Implemented ability to install an externally signed CA using pkispawn. * Simplified the structure of the UI packages ** All images and css files have been moved to dogtag-pki-server-theme for all subsystems. ** Removed unused and duplicated files. ** Template files have been moved to the underlying subsystem files. In future, all theme related messages in those files will be parameterized and placed in dogtag-pki-server-theme. This will significantly simplify the process of customizing or internationalizing an instance and its theme. ** Retired all the subsystem specific UI packages, reducing the number of UI packages from 7 to 1. * Security fixes for CVE-2012-4543 Certificate System: Multiple cross-site scripting flaws by displaying CRL or processing. * Memory fixes for the TPS * Updated to latest version of cmake, removing obsolete modules. == Notes for F17 == * Only developer builds are available for F17. * F17 tomcat used to have a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you have at least tomcat-7.0.32-1.fc17. == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == akoneru (2): 0667896 Fix for improper crl retrieval from CA. f400f3b Invalid ACL resources Fix in KRA for certServer.kra.keys alee (25): 6e77f33 Updated pki-core spec file to 10.0.0-2 a505c8c fix typo in spec file f73a662 Update to rc1 build 1e46576 Added more detail to man page for pki(1) cbfdae8 Remove server code from CertSearchRequest cd279e3 Modified section on sample.cfg a3f7d58 Interpolation correction patch based on review comments 065d883 Use interpolation to build default parameters 35dc100 Change the structure of the client directory. 03a6350 Common User: pkispawn changes 6be1194 Common admin user: config servlet changes 871b442 Misc changes to get rhel 7 build to work 40e58f9 Link to resteasy-base on rhel systems when running pkispawn 96af71d Removed obsolete cmake modules, updated spec files 9862a04 Updating cmake variables 440a9e7 removed obsolete cmake modules 1de7c91 Change cmake projects from Java to NONE 2efc66e spec file changes 999a0f1 Added missing Provides eb74b11 update to b3 64eaca2 Fix issue with pki_external being referenced for non-CA 318716f removed dry_run from pkispawn 019a933 Remove unused respawn code. a80e994 Convert admin cert from a to b before importing to certdb db9537d Set paths for default instance awnuk(1): 883e0ec number verification edewata (52): 9996d71 Parameterizing RESTEasy paths. 81bb209 Archiving default deployment configuration. 66c519f I18n for ProfileList.template. a4c95c3 Removed RA and TPS theme packages. 3dfee91 Reorganized TPS CSS files. d8f56d8 Reorganized TPS templates and scripts. 538dee3 Reorganized RA templates and scripts. 083e130 Fixed permission problem in TKS. 6344d6e Replaced links of scriptlets with lists. 471a493 Simplified the configuration file using defaults. 5e93dc2 Reorganized sensitive parameters. cef7a77 Fixed issuedOn parameters for cert-find. ba1e743 Fixed default security domain user. 68751fb Refactored pkiparser.py into PKIConfigParser. 9bb7143 Removed CA, KRA, OCSP, TKS theme packages. 46fda5d Reorganized CA, KRA, OCSP, TKS templates. edf9c22 Reorganized common templates. c8336ea Renamed pki-common-theme to pki-server-theme. 105ffbd Reorganized ESC images. 545b796 Removed unused files in tps-ui. f3e20fc Removed unused
[Freeipa-devel] [Fwd: [Pki-devel] Announcing Dogtag 10 Beta 2 Release]
---BeginMessage--- The Dogtag team is proud to announce version Dogtag v10.0.0 beta 2. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.48.b2.fc18 pki-ra-10.0.0-0.10.b2.fc18 pki-tps-10.0.0-0.10.b2.fc18 dogtag-pki-10.0.0-0.13.b2.fc18 dogtag-pki-theme-10.0.0-0.4.b2.fc18 pki-console-10.0.0-0.10.b2.fc18 == Highlights since Dogtag v. 10.0.0 beta 1 (Oct 9 2012) == * Selinux policy moved into system selinux policy. For F18, pki-selinux will no longer be built and delivered by the dogtag team. The PKI policy will instead be managed by the selinux base packages team. * Added option to install schema on a clone, rather than simply replicating it. This is to resolve an IPA issue when replicating from a non-merged to a merged database. * Restricted AJP to allow access from localhost only by default. This is an IPA reported issue. * Changes to allow the TPS and RA to install and configure correctly. * Enabled Tomcat security manager and added mechanism to configure custom security policy. * Added CLI tools to obtain security domain information and install tokens. * Refactored REST client classes to support multiple operations over authenticated HTTP session. * Added automatic recovery to the LDAP modification listener. * Added login service to protect REST services including certificate operations, key operations, security domain, TKS and OCSP. * Added option to pkispawn to exit before configuration, in case the installer wants to go through the UI configuration panels. In this way, pkispawn can be operated like pkicreate/pkisilent. * Removed version numbers from jar files to comply with Fedora packaging recommendations. == Notes for F17 == * Only developer builds are available for F17. * F17 tomcat used to have a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you have at least tomcat-7.0.32-1.fc17. == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == akoneru (1): 1485a05 Fix for ticket 384 - Incorrect profiles path referenced alee (15): 80ac796 Fix symkey build dependency 65c17da Update to b2 release 7c105a6 Restrict AJP to localhost only by default 3908d96 Added obsoletes for pki-selinux 278ee60 changes to remove pki-selinux from f18 build 1c45197 Provide option to install, rather than replicate schema to clone 40bcc2c Reorder VLV indexing for clones to avoid errors 643c089 Fixes to get TPS to configure correctly d6634a7 Reverted to old interface and httpclient for installation token. 2a43f48 Added net-tools dependency 35eb608 changes to remind folks not to use pkicreate/pkiremove 8a2d342 Update tomcatjss dependency 283af42 Added pki_tomcat_script_t type and rules for upgraded instances c7c2b6c New selinux interface needed for certmonger directory access c494bd0 Added pki_tomcat_cert_t type and interface to access it edewata (16): c1aa8b2 Enabled authentication for key services. 748605a Fixed synchronization problem in CertificateRepository. 5eab7fe Enabled Tomcat security manager. 9c17ef4 Refactored GetDomainXML servlet. 5bb7933 Added REST interface to get domain info. 6359021 Enabled account service for TKS and OCSP. 8687740 Added conditions for security domain REST service. 7ec6c91 Fixed error handling in RetrieveModificationsTask. 2d3d561 Fixed KRA test. c1f9b39 Enabled realm authentication for certificate requests. 1723a2e Added REST account service. 98ad9c1 Added PKIPrincipal. 4300459 Added PKIConnection. 8973480 Refactored GetCookie servlet. 168d954 Enabled authentication for security domain REST interface. 212ab82 Return to d9 behavior for RetrieveModificationsTask mharmsen (2): a957a3d Allow a PKI instance to be installed/configured independently 8d77b52 Removal of version numbers from jar file names ___ Pki-devel mailing list pki-de...@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel ---End Message--- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [Fwd: [Pki-announce] Announcing Dogtag 10.0.0 beta 1 release]
---BeginMessage---
The Dogtag team is proud to announce version Dogtag v10.0.0 beta 1.
A build is available for Fedora 18 in the updates-testing repo. Please
try it out and provide karma to move it to the F18 stable repo.
Daily developer builds for Fedora 17 and 18 are available at
http://nkinder.fedorapeople.org/dogtag-devel/fedora/
== Build Versions ==
pki-core-10.0.0-0.43.b1.fc18
pki-ra-10.0.0-0.9.b1.fc18
pki-tps-10.0.0-0.9.b1.fc18
dogtag-pki-10.0.0-0.10.b1.fc18
dogtag-pki-theme-10.0.0-0.2.b1.fc18
pki-console-10.0.0-0.8.b1.fc18
== Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) ==
* Merged pki-silent into pki-server.
* Added Provides to packages replacing obsolete packages.
* Added needed link for updated d9 - d10 instances. Found in IPA
testing.
* Backed up CS.cfg before upgrading from d9 - d10
* New selinux policy for all components. The Java components now take
advantage of a tomcat domain defined in the base selinux policy, and
the RA/TPS policies have been cleaned up considerably. The policy that is
now delivered is very close to the final version that will be delivered
in the base policy. That will be a deliverable for beta 2.
* Selinux context for startup scripts for all components set so that
runcon is not required.
* Cleaned up lock and pid files generation and removal for java
processes.
* Rebuilt packages against the latest F18 base selinux policy packages
to resolve an issue in installing pki-selinux due to removal of a
boolean in F18 base selinux policies. This issue was reported by IPA.
== Notes for F17 ==
* F17 requires an selinux version that is still in updates-testing.
Enable this repo to upgrade accordingly.
* F17 tomcat has a bug in the way it handles pid files.
https://bugzilla.redhat.com/show_bug.cgi?id=863307. Prior to creating
an instance, you need to perform the following workaround:
In the file, /usr/sbin/tomcat-sysd, change the line:
export CATALINA_PID=/var/run/${NAME}.pid
to:
export CATALINA_PID=${CATALINA_PID:-/var/run/${NAME}.pid}
== Feedback ==
Please provide comments, bugs and other feedback via the pki-devel
mailing list: http://www.redhat.com/mailman/listinfo/pki-devel
== Detailed Changelog ==
Ade Lee (11):
5ef10ba Update selinux-policy version to fix error from latest policy
81596ba fix spec typo
919434b Added build requires for version of selinux-policy-devel
5014442 Update release to b1
9cd11bc Fix name of CS.cfg backup file
63237d3 Backup CS.cfg before d10 update
da73f97 Changes to start pki_ra and pki_tps in correct context
6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code
f542060 move common policy into tps, ra templates
dbc6dec Use the tomcat selinux domain for the Java processes
3d5dc3b Added needed link for updated d9 - d10 instances
Endi Dewata (3):
23c70bd Merged pki-silent into pki-server.
79a3d82 Renamed shared folder to server.
753d55e Added Provides to packages replacing obsolete packages.
___
Pki-announce mailing list
pki-annou...@redhat.com
https://www.redhat.com/mailman/listinfo/pki-announce
---End Message---
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1059 single CRL generator
On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote: On 10/05/2012 10:59 AM, Martin Kosek wrote: On 10/04/2012 06:17 PM, Rob Crittenden wrote: This changes the way IPA generates CRLs for new installs only. The first master installed is configured as the CRL generator. An entry is added to cn=masters that designates it. When a replica is installed it queries this entry so it knows where to forward CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will return not found). It is possible to get a CRL directly from the clone CA via http://hostname:9180/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL rob ... 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I always get 403 Forbidden error when trying to download CRL from the CRL master: # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin --2012-10-05 03:32:58-- https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2012-10-05 03:32:58 ERROR 403: Forbidden. I tracked the problem down to too strict permission on /var/lib/pki-ca directory which is being published by httpd which does not have access to it: # ll /var/lib/pki-ca drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca When I fixed the permission: # chmod o+x /var/lib/pki-ca/ I was able to get pass the Forbidden error and actually retrieved the CRL. Adding Ade on CC list to follow on this permission issue. FYI - I filed a ticket for this issue: https://fedorahosted.org/freeipa/ticket/3144 I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for /var/lib/pki-ca/publish/ Sorry, but why do you need permissions on /var/lib/pki-ca? Aren't permissions on /var/lib/pki-ca/publish sufficient? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA
Agreed with your assessment that the --check-ca is not needed, as we
will be checking this into 3.1 (and not 3.0).
Attached is a patch for the request object issue. Basically, the
replication was not working because ipa-replica-prepare was passing in
the wrong port when creating the replica package.
Let me know if you have issues - and remember to add the missing link to
the master. That fix to add that link will be checked in today and
should be in the dogtag developer nightly build as of tommorow.
Ade
On Fri, 2012-10-05 at 11:57 +0200, Petr Viktorin wrote:
On 10/04/2012 10:04 PM, Ade Lee wrote:
Attached is a patch to handle the ipa-replica-conncheck issue. It
should be applied on top of your patch.
Essentially, the fix is as follows:
A. If the DS_PORT = 7389, then we pass --check-ca in the
ipa-replica-conncheck to be executed on the master.
a1. If the master is ipa 2.x, this will prompt a check for port 7389.
a2. If the master is ipa 3, this will default to dogtag_ds_port of 7389.
B. Else if DS_PORT = 389, then we pass nothing to the
ipa-replica-conncheck to be executed on the master. This is because we
will be checking 389 in any case for the IPA DS check.
Ade
The code works, I got past the connection check, and now I'm getting the
same internal server error with a clone from IPA 2.2 as with a clone
from 3.0 upgraded from 2.2 (unknown object class request).
However, since with this patch IPA will depend on Dogtag 10,
install_constants.DS_PORT will always be 389, so case A will never
happen. I think the two if-blocks that add the --check-ca can be dropped
entirely.
Assuming that even a clone from an old instance will use the single DB,
conncheck's --dogtag-master-ds-port option is redundant: iff the server
supports it, it uses port 389 which doesn't need re-checking.
0001-Allow-ipa-replica-conncheck-to-work-with-2.2-instanc.patch
From a9cd4cb15e6c230e5690f3fa919fda9c5728ee10 Mon Sep 17 00:00:00 2001
From: Ade Leea...@redhat.com
Date: Thu, 4 Oct 2012 15:55:29 -0400
Subject: [PATCH] Allow ipa-replica-conncheck to work with 2.2 instances
---
install/tools/ipa-replica-conncheck | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/install/tools/ipa-replica-conncheck
b/install/tools/ipa-replica-conncheck
index
c9fb816be43d873a6ca79396e77270fd0d10aa12..498ef49e84e1dc8325b6fc2d850c8bffb9297e69
100755
--- a/install/tools/ipa-replica-conncheck
+++ b/install/tools/ipa-replica-conncheck
@@ -282,7 +282,11 @@ def main():
required_ports = BASE_PORTS
if options.check_ca:
-ca_port = CheckedPort(int(options.dogtag_master_ds_port),
SOCK_STREAM,
+port_val = 7389
+if options.dogtag_master_ds_port:
+port_val = int(options.dogtag_master_ds_port)
+
+ca_port = CheckedPort(port_val, SOCK_STREAM,
PKI-CA: Directory Service port)
required_ports.extend([ca_port])
@@ -359,11 +363,8 @@ def main():
raise RuntimeError(Could not get ticket for master
server: %s % stderr)
remote_check_opts = ['--replica %s' % options.hostname]
-if options.check_ca:
+if options.check_ca and dogtag.install_constants.DS_PORT ==
7389:
remote_check_opts.append('--check-ca')
-remote_check_opts.extend([--dogtag-master-ds-port,
-str(dogtag.install_constants.DS_PORT)])
-
print_info(Execute check on remote master)
@@ -387,10 +388,8 @@ def main():
print_info(Please run the following command on remote
master:)
remote_check_opts = ['--replica %s' % options.hostname]
-if options.check_ca:
+if options.check_ca and dogtag.install_constants.DS_PORT ==
7389:
remote_check_opts.append('--check-ca')
-remote_check_opts.extend([--dogtag-master-ds-port,
-str(dogtag.install_constants.DS_PORT)])
print_info(/usr/sbin/ipa-replica-conncheck +
.join(remote_check_opts))
time.sleep(3600)
-- 1.7.12
From 424288306c6682fc99ef518b1c11a49880988564 Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Fri, 5 Oct 2012 15:18:50 -0400
Subject: [PATCH] Fix ipa-replica-prepare to include correct port
---
install/tools/ipa-replica-prepare | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/install/tools/ipa-replica-prepare b/install/tools/ipa-replica-prepare
index 5a566d61df521d3801c41a07753a2af728a7b6e7..80fb8d1de9555ad1ac957560f2d022e7b41adb1d 100755
--- a/install/tools/ipa-replica-prepare
+++ b/install/tools/ipa-replica-prepare
@@ -372,7 +372,7 @@ def main():
print Saving dogtag Directory Server port
port_fname = dir + /dogtag_directory_port.txt
with open
Re: [Freeipa-devel] [PATCH] 1059 single CRL generator
On Fri, 2012-10-05 at 12:26 -0400, Simo Sorce wrote: On Fri, 2012-10-05 at 12:19 -0400, Ade Lee wrote: On Fri, 2012-10-05 at 16:45 +0200, Martin Kosek wrote: On 10/05/2012 10:59 AM, Martin Kosek wrote: On 10/04/2012 06:17 PM, Rob Crittenden wrote: This changes the way IPA generates CRLs for new installs only. The first master installed is configured as the CRL generator. An entry is added to cn=masters that designates it. When a replica is installed it queries this entry so it knows where to forward CRL requests. CRL files are not available on cloned CAs (so /ipa/crl will return not found). It is possible to get a CRL directly from the clone CA via http://hostname:9180/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL rob ... 3) Majorish issue I hit with the actual CRL publishing on our server (F17). I always get 403 Forbidden error when trying to download CRL from the CRL master: # wget --ca-certificate /etc/ipa/ca.crt https://`hostname`/ipa/crl/MasterCRL.bin --2012-10-05 03:32:58-- https://vm-120.idm.lab.bos.redhat.com/ipa/crl/MasterCRL.bin Resolving vm-120.idm.lab.bos.redhat.com... 10.16.78.120 Connecting to vm-120.idm.lab.bos.redhat.com|10.16.78.120|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2012-10-05 03:32:58 ERROR 403: Forbidden. I tracked the problem down to too strict permission on /var/lib/pki-ca directory which is being published by httpd which does not have access to it: # ll /var/lib/pki-ca drwxrwx---. 11 pkiuser pkiuser 4096 Oct 5 03:00 pki-ca When I fixed the permission: # chmod o+x /var/lib/pki-ca/ I was able to get pass the Forbidden error and actually retrieved the CRL. Adding Ade on CC list to follow on this permission issue. FYI - I filed a ticket for this issue: https://fedorahosted.org/freeipa/ticket/3144 I plan to simply fix permission on /var/lib/pki-ca/ in a similar way we do for /var/lib/pki-ca/publish/ Sorry, but why do you need permissions on /var/lib/pki-ca? Aren't permissions on /var/lib/pki-ca/publish sufficient? Ade, on unix filesystems you cannot traverse a directory path if you do not have permission all the way through. If 'others' can't access /var/lib/pki-ca they will never even reach the point where they can see that they have access to a subdirectory. The very minimum permission you need to be able to traverse directories is to have the 'traverse' (x) bit set. (note that you do not need the read (r) bit set just to traverse). I suspected as much, but wanted to confirm. The decision to publish the CRL to /var/lib/pki-ca/publish is an IPA deployment decision. This is a directory that is created by the IPA install scripts. Other folks who deploy Dogtag may choose to publish elsewhere - like under /var/www/... for instance. A location outside of the pki-ca tree seems like a safer option to me, rather than allowing other to step through /var/lib/pki-ca ... In any case, if you do decide to leave the publishing directory in that location, you will need to also set the +x permissions for other on /var/lib/pki-ca in the IPA install scripts. Ade Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [Fwd: [Pki-announce] Announcing Dogtag 10.0.0 alpha 2 release]
---BeginMessage--- The Dogtag team is proud to announce version Dogtag v10.0.0 alpha 2. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.37.a2.fc18 pki-ra-10.0.0-0.8.a2.fc18 pki-tps-10.0.0-0.8.a2.fc18 dogtag-pki-10.0.0-0.9.a2.fc18 dogtag-pki-theme-10.0.0-0.2.a2.fc18 pki-console-10.0.0-0.8.a2.fc18 == Highlights since Dogtag v. 10.0.0 alpha 1 (Sept 14 2012) == * Dogtag 10 can now clone from Dogtag 9 masters. We will fall back to the old installation servlet if needed. (**) * Startup state of a server can be determined from the getStatus() servlet (**) * Consistent database user provided during installation for client authentication (used in IPA merged database install) * Fixed package dependency issue with pki-symkey (**) * pki-setup merged into pki-server (**) * Audit Cert Renewal time extended to two years (**) * Versioning added to jar manifest files and VERSION file and reported in getStatus * ECC enhancements in DRM and TMS environment * Addition of time based searches in preparation for randomized serial numbers * Enhanced escaping of LDAP attributes * Improved transition control for token operations in the TPS. ** denotes IPA related/reported issue == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == Ade Lee (4): 761a047 Updated release to a2 854ecce fall back to old interface for installtoken if needed 11e05d3 Use getStatus servlet to provide startup status e1666df Changes to use standard dbuser Andrew Wnuk (1): f944641 time based searches Christina Fu (5): 7b3df7e https://fedorahosted.org/pki/ticket/252 - TMS - ECC Key Recovery 528fda5 TMS key recovery part of - Bug 737122 - DRM: during archiving and recovering, wrapping unwrapping keys should be done in the token f4ecf48 (fixed warning for) task #304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) e689561 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) 6257d32 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) Endi Dewata (11): f81718c Using RPM version number in CMake. aa1c7e7 Added package checking for pkispawn. 87d290d Added version number into server status. 9368ef4 Added VERSION file. 1726794 Renamed escapeDN() into escapeRDNValue(). 4ba74f7 Merged pki-setup into pki-server. 156ba56 Added DN and filter escaping in ConfigurationUtils. 947ab8a Removed duplicate DN escaping methods. 715d89d Added DN and filter escaping in UGSubsystem. 7b737b2 Fixed conflicting log4j.properties. 8ed86a7 Fixed problems with optional pki-symkey. Jack Magne (1): 9173b43 Provide default for operations transition list, # 858816. Matthew Harmsen (2): d450525 Correctly resolve symlinks in subdirectories f5b8ea5 Audit Cert Renewal ___ Pki-announce mailing list pki-annou...@redhat.com https://www.redhat.com/mailman/listinfo/pki-announce ---End Message--- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA
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 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. Ade 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 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) We just need to make sure, that 3.0 replica made out of 2.x master will work. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Integration of dogtag10
Its a bug. Basically, the d10 instance is trying to get an installation token from the security domain, using a new restful interface. This, on a dogtag 9 instance, results in a 404. We need to change the d10 code to fall back to the old interface in case the new one does not work. https://fedorahosted.org/pki/ticket/334 has been created on dogtag trac, Ade On Wed, 2012-09-19 at 13:58 +0200, Martin Kosek wrote: Hello Ade, I am continuing a testing of integration of dogtag10 + ipa 3.0 on Fedora 18. After defining the missing apache-commons-codec.jar link + permissive SELinux, clean IPA installation + cert operations works fine. I just hit an issue when installing an F18+dogtag10 replica for a F17+dogtag9 master. Is this scenario still unsupported or is it a bug? (I am moving the whole dogtag10 development discussion outside of the previous long thread since your and pviktori's patches have been accepted and pushed). ipa-replica-install output: # ipa-replica-install -p Secret123 -w Secret123 --setup-ca ~/replica-info-vm-021.idm.lab.bos.redhat.com.gpg Run connection check to master Check connection from replica to remote master 'vm-086.idm.lab.bos.redhat.com': ... Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server done configuring pkids. Configuring certificate server: Estimated time 3 minutes 30 seconds [1/15]: creating certificate server user [2/15]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' ipa+pki logs attached. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Integration of dogtag10
Its a bug. Basically, the d10 instance is trying to get an installation token from the security domain, using a new restful interface. This, on a dogtag 9 instance, results in a 404. We need to change the d10 code to fall back to the old interface in case the new one does not work. https://fedorahosted.org/pki/ticket/334 has been created on dogtag trac, Ade On Wed, 2012-09-19 at 13:58 +0200, Martin Kosek wrote: Hello Ade, I am continuing a testing of integration of dogtag10 + ipa 3.0 on Fedora 18. After defining the missing apache-commons-codec.jar link + permissive SELinux, clean IPA installation + cert operations works fine. I just hit an issue when installing an F18+dogtag10 replica for a F17+dogtag9 master. Is this scenario still unsupported or is it a bug? (I am moving the whole dogtag10 development discussion outside of the previous long thread since your and pviktori's patches have been accepted and pushed). ipa-replica-install output: # ipa-replica-install -p Secret123 -w Secret123 --setup-ca ~/replica-info-vm-021.idm.lab.bos.redhat.com.gpg Run connection check to master Check connection from replica to remote master 'vm-086.idm.lab.bos.redhat.com': ... Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server done configuring pkids. Configuring certificate server: Estimated time 3 minutes 30 seconds [1/15]: creating certificate server user [2/15]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' ipa+pki logs attached. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Integration of dogtag10
Its a bug. Basically, the d10 instance is trying to get an installation token from the security domain, using a new restful interface. This, on a dogtag 9 instance, results in a 404. We need to change the d10 code to fall back to the old interface in case the new one does not work. Ade On Wed, 2012-09-19 at 13:58 +0200, Martin Kosek wrote: Hello Ade, I am continuing a testing of integration of dogtag10 + ipa 3.0 on Fedora 18. After defining the missing apache-commons-codec.jar link + permissive SELinux, clean IPA installation + cert operations works fine. I just hit an issue when installing an F18+dogtag10 replica for a F17+dogtag9 master. Is this scenario still unsupported or is it a bug? (I am moving the whole dogtag10 development discussion outside of the previous long thread since your and pviktori's patches have been accepted and pushed). ipa-replica-install output: # ipa-replica-install -p Secret123 -w Secret123 --setup-ca ~/replica-info-vm-021.idm.lab.bos.redhat.com.gpg Run connection check to master Check connection from replica to remote master 'vm-086.idm.lab.bos.redhat.com': ... Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server done configuring pkids. Configuring certificate server: Estimated time 3 minutes 30 seconds [1/15]: creating certificate server user [2/15]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' ipa+pki logs attached. Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA
Changes to use a single database for dogtag and IPA
New 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.
Ade
From f827c0d744086a65c574de06ee3ff85083429f87 Mon Sep 17 00:00:00 2001
From: Ade Lee a...@redhat.com
Date: Wed, 19 Sep 2012 23:35:42 -0400
Subject: [PATCH] Changes to use a single database for dogtag and IPA
New 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.
---
install/share/certmap.conf.template |3 ++
install/tools/ipa-ca-install| 22 +++--
install/tools/ipa-csreplica-manage |2 +-
install/tools/ipa-replica-conncheck | 19 ++--
install/tools/ipa-replica-install | 27 ---
install/tools/ipa-replica-prepare |5 ++
install/tools/ipa-server-install| 88 +++---
install/tools/ipactl|6 ++-
ipapython/dogtag.py | 11 -
ipaserver/install/cainstance.py | 89 +--
ipaserver/install/dsinstance.py | 14 --
ipaserver/install/installutils.py |6 ++-
ipaserver/install/replication.py|7 ++-
13 files changed, 218 insertions(+), 81 deletions(-)
diff --git a/install/share/certmap.conf.template b/install/share/certmap.conf.template
index 676d3ef354c9dae4dce8c4682176e656088991b2..d83b28c05cf9364e4ebb25a98aa8db6a98524bb7 100644
--- a/install/share/certmap.conf.template
+++ b/install/share/certmap.conf.template
@@ -80,3 +80,6 @@ certmap default default
#default:InitFn Init function's name
default:DNComps
default:FilterComps uid
+certmap ipaca CN=Certificate Authority,O=domain_name
+ipaca:CmapLdapAttr seeAlso
+ipaca:verifycerton
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index 1c1b96a91fbbef455a68b158cc0191b91f2232f9..95a64a135e6634046ca55091968f371903511771 100755
--- a/install/tools/ipa-ca-install
+++ b/install/tools/ipa-ca-install
@@ -142,17 +142,31 @@ def main():
config.dir = dir
config.setup_ca = True
+portfile = config.dir + /dogtag_directory_port.txt
+if not ipautil.file_exists(portfile):
+dogtag_master_ds_port = 7389
+else:
+fd = open(portfile)
+dogtag_master_ds_port = fd.read()
+fd.close()
+
if not options.skip_conncheck:
-replica_conn_check(config.master_host_name, config.host_name, config.realm_name, True, options.admin_password)
+replica_conn_check(config.master_host_name, config.host_name, config.realm_name, True,
+ dogtag_master_ds_port, options.admin_password)
# Configure the CA if necessary
-(CA, cs) = cainstance.install_replica_ca(config, postinstall=True)
+(CA, cs) = cainstance.install_replica_ca(config,
+ dogtag_master_ds_port, postinstall=True)
# We need to ldap_enable the CA now that DS is up and running
CA.ldap_enable('CA', config.host_name, config.dirman_password,
ipautil.realm_to_suffix(config.realm_name))
-cs.add_simple_service('dogtagldap/%s@%s' % (config.host_name, config.realm_name))
-cs.add_cert_to_service()
+if not dogtag.install_constants.SHARED_DB:
+cs.add_simple_service('dogtagldap/%s@%s' % (config.host_name, config.realm_name))
+cs.add_cert_to_service()
+else:
+CA.enable_client_auth_to_db()
+CA.restart()
# We need to restart apache as we drop a new config file in there
ipaservices.knownservices.httpd.restart(capture_output=True)
diff --git a/install/tools/ipa-csreplica-manage b/install/tools/ipa-csreplica-manage
index 39cfa58511ae552cae64798c7559303fda27866a..272daacfedbb45db4307b04201954ad0a96b0614 100755
--- a/install/tools
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-17 at 14:32 +0200, Petr Viktorin wrote: On 09/14/2012 11:19 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/12/2012 06:40 PM, Petr Viktorin wrote: A new Dogtag build with changed pkispawn/pkidestroy locations should be out later today. The attached patch should work with that build. Fresh install is failing in F-18. ki-tools-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.i686 pki-base-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-server-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-silent-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-symkey-9.0.21-1.fc18.x86_64 dogtag-pki-ca-theme-10.0.0-0.1.a1.20120914T0604zgit69c0684.fc18.noarch pki-selinux-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-ca-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-setup-9.0.21-1.fc18.noarch rob Ade, your patch adds a step of moving /var/lib/pki/pki-tomcat/alias/ca_admin_cert.p12 to /root/ca-agent.p12 right after calling pkispawn. It seems the file is not created on f18. Did something change in Dogtag or are we calling it incorrectly? The failure of that step often indicates a failure of the previous configure() step. That is - moving that file fails because it was not created, because configuration fails. Rob's logs seem to indicate some kind of classpath issue with the jython code in pkispawn which calls configure() on the server. I set up an f18 machine and was able to configure an instance (outside of IPA) Will now try with the ipa code (and your patches) to see if I can reproduce. Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-17 at 14:32 +0200, Petr Viktorin wrote: On 09/14/2012 11:19 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 09/12/2012 06:40 PM, Petr Viktorin wrote: A new Dogtag build with changed pkispawn/pkidestroy locations should be out later today. The attached patch should work with that build. Fresh install is failing in F-18. ki-tools-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.i686 pki-base-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-server-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-silent-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-symkey-9.0.21-1.fc18.x86_64 dogtag-pki-ca-theme-10.0.0-0.1.a1.20120914T0604zgit69c0684.fc18.noarch pki-selinux-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-ca-10.0.0-0.33.a1.20120914T0536zgit69c0684.fc18.noarch pki-setup-9.0.21-1.fc18.noarch rob Ade, your patch adds a step of moving /var/lib/pki/pki-tomcat/alias/ca_admin_cert.p12 to /root/ca-agent.p12 right after calling pkispawn. It seems the file is not created on f18. Did something change in Dogtag or are we calling it incorrectly? Just for the record, as discussed on IRC, the problem is that the latest build of apache-commons-codec (1.6.4) is missing the /usr/share/java/apache-commons-codec.jar symlink. A bug has been filed https://bugzilla.redhat.com/show_bug.cgi?id=857947 and is being addressed. Until a new build of apache-commons-codec is available, you can use the workaround of creating the missing link: ln -s /usr/share/java/commons-codec.jar /usr/share/java/apache-commons-codec.jar Also, there is a bug where pkispawn requires pki-symkey to be installed in order to complete. We will fix pkispawn to not require this - because its only needed for the TKS, and deliver that in a subsequent build. For now though, just make sure pki-symkey is installed. We'll do a new build once you guys have had a chance to try the current build out a bit and report issues. Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-12 at 18:43 +0200, Petr Viktorin wrote: On 09/11/2012 09:38 PM, Rob Crittenden wrote: Rob Crittenden wrote: Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9-10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular service ipa restart? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. Thanks for the catch. Attaching updated patch that sanitizes the passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9-10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular service ipa restart? Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object that is being passed to the server from pkispawn. That - and the diffs to the standard config file as I mentioned above - will likely be sufficient to debug almost all cases. Make sure not to log any passwords. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa 3.0 in it. We can add that. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Tue, 2012-09-11 at 14:45 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:38 PM, Rob Crittenden wrote: Ade Lee wrote: On Tue, 2012-09-11 at 08:59 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 09/11/2012 04:04 AM, Ade Lee wrote: On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. These files should stay the same since on upgrade we're still using a Dogtag 9 style instance. The Dogtag 10 ports are only used in new installs. The ipa package lacks any updated dogtag dependencies, so I abused it. What should the updated dependencies be? Since it should work with both dogtag 9 and 10, I don't see how they should change. I don't know either, but we need to prevent people from installing incompatible package combinations. Would'nt the Conflicts: ipa 3.0 in pki-ca mentioned below satisfy this requirement? The main concern is that you must have ipa 3.0 if you have dogtag 10. Given that dogtag is consumed by IPA though, it makes more sense to put the relevant conflicts in IPA rather than in dogtag. So in this case, that would mean putting Conflicts: pki-ca = 10.0 in IPA 2.x. Recall that dogtag 10 will only be officially available in f18+. That isn't enough. If a F-17 user with IPA 2.2 installed upgrades to F-18 they would be able to install dogtag 10 and blow up their IPA server. We can add the Conflicts: freeipa-server 3.0 to the dogtag packages (likely in pki-base). But we should also add explicit dependencies to ipa. For ipa 2.2, Conflicts: pki-ca = 10.0, Requires: pki-ca = 9.x For ipa 3, Requires: pki-ca = 10.0 This is of course assumes that ipa 3 is only officially released on f18 (which is what will happen for dogtag 10). Just because we can support d9 on ipa 3 does not mean we should. As it is, in this case, we will have to support IPA 3 + d10, IPA 3 + d10 + d9-style instance, IPA 2.x + d9. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9-10. In permissive mode, this upgrade works for me. I was in enforcing mode but saw no AVCs. What is the ETA on fixing this? Within the next week or two, I need to finish the IPA merge database patch first, and then co-ordinate changes with the selinux guys. Sometimes I do get this error intermittently: ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Service Temporarily Unavailable) Usually, waiting a couple of minutes clears this up. Perhaps we are not doing startup detection correctly. Ade mentioned that waiting for ports may not be ideal. How do we know if Dogtag is initialized? Years ago we had discussed with Andrew and Matt creating a URI that can be queried to determine dogtag status. I don't think that ever went anywhere. Petr, this happens only on reboot, right? And not on regular service ipa restart? I've now seen it happen right after a 9 → 10 upgrade. Yeah, I remember this conversation - and even created a bug for it at some point. This went away because the mechanism you were using seemed to be working. The timing may be very different now with tomcat 7 and systemd. I'll open a dogtag trac ticket for this. Ok. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I was under the impression that pkidestroy was the correct command to remove an upgraded instance. I'll check with Ade. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. Our logs are pretty verbose, so that shouldn't be a problem. I'll put it in the next version of the patch. The question to ask is: would you need the contents of this file if all you got were logs and needed to evaluate why installation failed? In most cases this is yes. Up to you guys. There is a patch I am working on in which I will be logging the object
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Mon, 2012-09-10 at 16:58 -0400, Rob Crittenden wrote: Petr Viktorin wrote: Attaching rebased and squashed patches. I've done some testing with them but please test some more. Most of these aren't IPA issues, but dogtag issues. I'll try to split them out. IPA: For the configuration files in install/conf to be updated at rpm update time the VERSION needs to be incremented. The ipa package lacks any updated dogtag dependencies, so I abused it. I installed IPA with dogtag 9 and created a replica. I updated the IPA bits, that worked fine. I updated to dogtag 10 and now the CA doesn't work on the master, including starting the dogtag instance. Note that the rpm update process worked, no notice that the CA service didn't restart. Did you try to restart the CA with selinux in permissive mode? This is still required right now until I get the selinux policy all straightened out. There is also a separate dogtag ticket (which is currently being worked on) to restart existing dogtag instances when dogtag is upgraded from 9-10. Uninstalling failed because it tried to run pkidestroy and not pkiremove. I'll test this too. The contents of the file passed to pkispawn should be logged so we can see exactly what was passed in. Its a pretty big file. You might want to only log the modifications. Or save the file somewhere. DOGTAG: When upgrading using the dogtag-devel repo I had to specify pki-tools.x86_64 otherwise it tried to install both 32 and 64-bit versions (and failed). I ended up running: yum update pki-ca tomcatjss pki-tools.x86_64 --enablerepo=dogtag-devel --enablerepo=updates-testing We'll look into this. I think I know why this happens. What happens if someone manually upgrades pki-ca without first updating ipa? I think that pki-ca is going to need a Conflicts ipa 3.0 in it. We can add that. certificate renewal failed. I spent far too long trying to figure out why tomcat wasn't listening on port 9180 but failed. I think 9180 is actually the old server, right? So another missing dependency on a fixed certmonger? The best I could find was the certmonger error: ca-error: Error 7 connecting to http://edsel.example.com:9180/ca/ee/ca/profileSubmit: Couldn't connect to server. Is this cert renewal on a dogtag 10 instance? Or the upgraded dogtag 9? If its dogtag 10, perhaps you do not have the certmonger version that has the relevant fix? If its dogtag 9, then we need to figure out whats going on. That reminds me - I need to file a bug to allow certmonger to talk to the newly defined dogtag ports. Do you have selinux permissive? There is no man page for pkispawn/pkidestroy :-( According to the FHS these should not be in /bin but in /usr/sbin (not end-user commands). There is a trac ticket open for man pages for pkispawn and pkidestroy. We plan to complete this ticket by the time f18 is released. We'll look into the location of pkispawn/pkicreate. The output of pkicreate/pkisilent was really terrible and not usable at all so we didn't display it when failures occurred. It looks like that has been addressed, at least for the case where a CA is already configured and you try to install IPA. Perhaps we should capture stderr and display that instead of the command-line of pkispawn? Again, a man page would help with the integration. 2012-09-10T20:51:45Z DEBUG [2/18]: configuring certificate server instance 2012-09-10T20:51:45Z DEBUG args=/bin/pkispawn -s CA -f /tmp/tmp_Urraq 2012-09-10T20:51:45Z DEBUG stdout= 2012-09-10T20:51:45Z DEBUG stderr=pkispawn: ERROR... PKI subsystem 'CA' for instance 'pki-tomcat' already exists! 2012-09-10T20:51:45Z CRITICAL failed to configure ca instance Command '/bin/pkispawn -s CA -f /tmp/tmp_Urraq' returned non-zero exit status 1 That may be a good idea. Of course. thats an IPA thing, right? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote: On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: Incidentally, I ran this in permmissive selinux mode. The following rules are required to be added: #= certmonger_t == corenet_tcp_connect_http_cache_port(certmonger_t) files_read_var_lib_symlinks(certmonger_t) On my system, semanage port -l shows me: http_cache_port_t tcp 8080, 8118, 10001-10010 Are these ports already labeled this way for Dogtag, or is it a coincidental overlap with some other package? If it's an overlap, it might be better to switch to using ports which aren't already labeled for use in policy that applies to some other package. We have specifically chosen to use what would be the default ports for tomcat. These ports are already labeled as you have described above. We have adjusted our selinux policy to handle that. In fact, we are now extending a tomcat selinux domain provided by the system policies, and this tomcat domain allows access to those ports. If not, please open a bug against the selinux-policy component to get these accesses added to the set that's allowed by the default policy. I can open a bug. Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 17:44 -0400, Simo Sorce wrote: On Wed, 2012-09-05 at 17:08 -0400, Ade Lee wrote: On Wed, 2012-09-05 at 16:43 -0400, Nalin Dahyabhai wrote: On Wed, Aug 29, 2012 at 08:48:32AM -0400, Ade Lee wrote: Incidentally, I ran this in permmissive selinux mode. The following rules are required to be added: #= certmonger_t == corenet_tcp_connect_http_cache_port(certmonger_t) files_read_var_lib_symlinks(certmonger_t) On my system, semanage port -l shows me: http_cache_port_t tcp 8080, 8118, 10001-10010 Are these ports already labeled this way for Dogtag, or is it a coincidental overlap with some other package? If it's an overlap, it might be better to switch to using ports which aren't already labeled for use in policy that applies to some other package. We have specifically chosen to use what would be the default ports for tomcat. These ports are already labeled as you have described above. We have adjusted our selinux policy to handle that. In fact, we are now extending a tomcat selinux domain provided by the system policies, and this tomcat domain allows access to those ports. If not, please open a bug against the selinux-policy component to get these accesses added to the set that's allowed by the default policy. I can open a bug. Ade, how will the selinux policy be handled in an upgrade scenario ? If I understand correctly you are dropping custom selinux policies from dogtag 10 and relying on system policy going forward, so what will keep the right labels for the old ports in an upgrade scenario ? Or will the rpm upgrade also change ports ? Is this properly handled on the ipa part yet ? Simo. To be clear, there will still be a selinux policy for dogtag, but it will be delivered as part of the system policies. The system selinux policy will contain alias definitions for all the old types. So for example, pki_ca_var_lib_t etc. will be aliased to the new type pki_tomcat_var_lib_t. The old ports will continue to be defined in the system policy but they will also be aliased to the ports in the new policy. Its not all defined yet - which is why we still need selinux permissive -- but we're working to get the system policy done soon. Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-09-05 at 16:20 -0400, Rob Crittenden wrote: Martin Kosek wrote: On 08/31/2012 04:53 PM, Petr Viktorin wrote: On 08/28/2012 03:40 PM, Petr Viktorin wrote: On 08/17/2012 06:04 PM, Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
I have not opened a certmonger bug, but here is a patch to fix the relevant code in certmonger. Nalin, please review and commit. I tested by renewing one of the dogtag system certs (the ocsp signing cert) Ade On Mon, 2012-08-27 at 09:40 -0400, Rob Crittenden wrote: Petr Viktorin wrote: On 08/27/2012 02:39 PM, Dmitri Pal wrote: On 08/17/2012 12:06 PM, Rob Crittenden wrote: Ade Lee wrote: On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Fri, 2012-08-17 at 09:34 -0400, Ade Lee wrote: On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Thu, 2012-08-16 at 18:45 +0200, Martin Kosek wrote: On 08/16/2012 01:28 PM, Ade Lee wrote: Patch attached this time. I should know better than to do this in the middle of the night .. On Thu, 2012-08-16 at 09:12 +0200, Martin Kosek wrote: On 08/16/2012 07:53 AM, Ade Lee wrote: On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will continue to work. But any new instances would be created using dogtag 10. 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install /home/mkosek/replica-info-vm-114.idm.lab.bos.redhat.com.gpg ... Configuring certificate server: Estimated time 3 minutes 30 seconds [1
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will continue to work. But any new instances would be created using dogtag 10. 3) I had installed IPA with dogtag10 on master. Replica had dogtag10 as well and I got the following error: # ipa-ca-install
Re: [Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
On Wed, 2012-08-15 at 23:41 -0400, Ade Lee wrote: On Wed, 2012-08-15 at 16:34 +0200, Martin Kosek wrote: On 08/15/2012 03:54 PM, Ade Lee wrote: On Wed, 2012-08-15 at 13:24 +0200, Martin Kosek wrote: On 08/08/2012 10:05 PM, Ade Lee wrote: Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade Hi Ade, Thanks for the patch, I started with review and integration tests (currently running on Fedora 17 with Nathan's repo). Installation on single master was smooth, it worked just fine, even with enforced SELinux, without any error - kudos to you and the whole dogtag team. The resulting logs and the structure of your log directory seems improved. I believe that the brand new Python installers will make it easier to debug issues with dogtag installation when they come. When I tried our unit tests or some simple cert operation, it worked fine as well. Now the bad news, or rather few issues and suggestions I found: 1) As we already discussed on IRC, tomcat 7 was not pulled automatically on Fedora 17 when I updated pki-ca, you somewhere miss a Requires. We have a dogtag patch that is currently in review that will address this. Once this is in, tomcatjss =7.0.0 will be required for f17+, rather than f18+ 2) I had installed IPA with dogtag10 on master. However, CA installation on a replica (ipa-ca-install) with dogtag9 failed - is this expectable? Yes. The current IPA patch is designed to work with dogtag 10 only, which will be officially available on f18+. So if you update to dogtag 10, you must have this patch and visa versa. We probably need to add the relevant requires to IPA to enforce this. If you have an existing dogtag 9 instance, and you upgrade to the new dogtag 10 and patched IPA, then that instance will continue to work. But any new instances would
[Freeipa-devel] [PATCH] Patch to allow IPA to work with dogtag 10 on f18
Hi, Dogtag 10 is being released on f18, and has a number of changes that will affect IPA. In particular, the following changes will affect current IPA code. * The directory layout of the dogtag instance has changed. Instead of using separate tomcat instances to host different subsystems, the standard dogtag installation will allow one to install a CA. KRA, OCSP and TKS within the same instance. There have been corresponding changes in the directory layout, as well as the default instance name (pki-tomcat instead of pki-ca), and startup daemon (pki-tomcatd, instead of pki-cad, pki-krad etc.) * The default instance will use only four ports (HTTPS, HTTP, AJP and tomcat shutdown port) rather than the 6 previously used. The default ports will be changed to the standard tomcat ports. As these ports are local to the ipa server machine, this should not cause too much disruption. * There is a new single step installer written in python. (pkispawn/destroy) vs. pkicreate/pkisilent/pkiremove. * Dogtag 10 runs on tomcat7 - with a new corresponding version of tomcatjss. The attached patch integrates all the above changes in IPA installation and maintenance code. Once the patch is applied, users will be able to: 1. run ipa-server-install to completion on f18 with dogtag 10. 2. install a new replica on f18 on dogtag 10. 3. upgrade an f17 machine with an existing IPA instance to f18/ dogtag 10 - and have that old-style dogtag instance continue to run correctly. This will require the installation of the latest version of tomcatjss as well as the installation of tomcat6. The old-style instance will continue to use tomcat6. 4. in addition, the new cert renewal code has been patched and should continue to work. What is not yet completed / supported: 1. Installation with an external CA is not yet completed in the new installer. We plan to complete this soon. 2. There is some IPA upgrade code that has not yet been touched (install/tools/ipa-upgradeconfig). 3. A script needs to be written to allow admins to convert their old-style dogtag instances to new style instances, as well as code to periodically prompt admins to do this. 4. Installation of old-style instances using pkicreate/pkisilent on dogtag 10 will no longer be supported, and will be disabled soon. 5. The pki-selinux policy has been updated to reflect these changes, but is still in flux. In fact, it is our intention to place the dogtag selinux policy in the base selinux policy for f18. In the meantime, it may be necessary to run installs in permissive mode. The dogtag 10 code will be released shortly into f18. Prior to that though, we have placed the new dogtag 10 and tomcatjss code in a developer repo that is located at http://nkinder.fedorapeople.org/dogtag-devel/ Testing can be done on both f18 and f17 - although the target platform - and the only platform for which official builds will be created is f18. Thanks, Ade From c1677bf96235fb5f71dff899642d459f2fc2e9fc Mon Sep 17 00:00:00 2001 From: Ade Lee a...@redhat.com Date: Sun, 29 Jul 2012 14:07:31 -0400 Subject: [PATCH] Modifications to install scripts for dogtag 10 Dogtag 10 uses a new installer, new directory layout and new default ports. This patch changes the ipa install code to integrate these changes. --- install/conf/ipa-pki-proxy.conf| 16 +- install/conf/ipa.conf |4 +- install/restart_scripts/renew_ca_cert | 18 +- install/restart_scripts/restart_pkicad | 18 +- install/tools/ipa-ca-install | 10 + install/tools/ipa-csreplica-manage |2 +- install/tools/ipa-replica-install |1 + install/tools/ipa-replica-prepare |2 +- install/tools/ipa-server-install |1 + install/ui/test/data/ipa_init.json |6 +- ipa-client/man/default.conf.5 |6 +- ipalib/constants.py|6 +- ipapython/certmonger.py|2 +- ipapython/platform/base.py |5 +- ipapython/platform/fedora16.py |7 +- ipapython/platform/systemd.py |4 +- ipaserver/install/cainstance.py| 330 +--- ipaserver/install/installutils.py |2 +- ipaserver/install/service.py | 13 +- selinux/ipa_dogtag/ipa_dogtag.fc |2 +- 20 files changed, 219 insertions(+), 236 deletions(-) diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf index 91a99aaf9cd9ce3669fbe12450bfae1b220fa67b..7dac76060f3fb7266b99e28cca4070bd1b9d5757 100644 --- a/install/conf/ipa-pki-proxy.conf +++ b/install/conf/ipa-pki-proxy.conf @@ -6,22 +6,22 @@ ProxyRequests Off LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none -ProxyPassMatch ajp://localhost:9447/ -ProxyPassReverse ajp
[Freeipa-devel] Merging dogtag and ipa databases
Hi all, Based on conversations with Adam, Simo and Rob, here are some thoughts on $subject: http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases I'll probably add more later - like the details on how cloned instance installation will run. Comments are welcome. Ade ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Thu, 2011-11-03 at 09:20 -0400, Adam Young wrote: On 11/03/2011 12:56 AM, Simo Sorce wrote: On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote: On 11/02/2011 06:19 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: [...] So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. Sounds reasonable. Can you post a link to the schema that would be added to IPA objects ? Simo. I think this is it: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif Look for cmsuser. Unfortunately it looks like the cmsuser objectclass is of type structural, which means it cannot be added to existing records. The cert seems to comes from 05rfc4523.ldif and is added in 06inetorgperson.ldif Which is already in our user record. CMS only seems to require usertype, which is a string, and allows userstate which is an integer. I wonder if we can convince PKI to use a different schema to reprsent this information. We can use Roles or Groups to tell what type of user a user is, not sure about the state as that schema file has exactly the same comment for both usertype and userstate, seems a bug. I think so. I do not know if CMSuser is really needed, as it looks like everything in there is accounted for some other way. My guess is the type field is used to enforce that someone in one group, say agents, cannot also be in a different group, say auditors but they do use groups for most roles in the system. I think that there are going to be severl layers for the permissions in the IPA approach: For CAAdmins, we create a group CAdmins, and add a Role to to CAAdminRole which contains the appropriate Permissions. Same for Auditors and agents. No one should have the ACI to change these roles. We probably want to put in an RFE for IPA Roles that state two roles are mutually exclusive. userstate is, I think, to disable an account, which is handled using nsaccount lock in IPA. I think we should agree on a single mechanism, and it should be the one in the most standard schema. With just an initial look at the dogtag code, it appears that userState and userType are no longer used in any meaningful way. We'll have to do a more exhaustive search to be sure, but initial indications are that we may no longer need this object class. Adam does bring up a good point, which is that - as a common criteria requirement, users were required to have no more than one of the following roles: agent, admin, auditor. How would this be enforced in the IPA database? IIRC the user we create in CS now has the description attribute set up in a very specific way. Is that still required? What is description used for ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Thu, 2011-11-03 at 09:22 -0400, Rob Crittenden wrote: Ade Lee wrote: On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well For clarification, cmsuser is just an object that is defined in the PKI schema, not the actual admin user created in the install itself. It may be advantageous to actually pre-create this user when applying schema LDIFS and just have pkisilent add the user certs. The description attribute needs to store per-instance specific information such as the requestId. Unless you mean just adding userstate and usertype. In dogtag, I believe we have used the description attribute to store whatever the user provided to describe the user/group. This is more relevant to the console. As IPA will be managing users and groups, then it can also manage this attribute. 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. Pre-creating this user may solve this problem. You can pre-create a user with all the required IPA and PKI attributes and just have pkisilent add the user cert needed. As we will be running as directory manager in this case, we will permissions to do this. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. This of course involves setting up the relevant ACIs. We may want to consider the reverse. That only certain IPA accounts should have access to the PKI data. Which still involves ACIs, right? Right 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. Not needed if we pre-populate as mentioned above. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote: To clarify: there are two types of Data stored in the PKI CA DS instances. One is Users and groups (IdM), and the other is certificates and requests. The CA currently administers its own users: creates, add deletes, add privs and so forth. If we extract the IdM objects from the CA control, we will need to build another mechanism to manage them. The Certificates will stay in their own suffix. I don't think anyone disagrees about this. I'm trying to think through the steps of using the IPA user database for PKI. If I undertand the end state, the general flow will be driven from ipa-server-install and will look like this: 1. Create a unified DS instance. We can continue to name it the way that IPA does: All caps the hostname. 2. Apply the LDAP schema LDIFs to it. At this point, we probably want to create the whole IPA schema, and the cmsUser as well For clarification, cmsuser is just an object that is defined in the PKI schema, not the actual admin user created in the install itself. It may be advantageous to actually pre-create this user when applying schema LDIFS and just have pkisilent add the user certs. 3. Call PKISilent (or equivalent) passing the info for the Unified directory server instance, to include the IPA tree for the users. 4. PKISilent will create the PKI admin user, to include its certificiate in the IPA tree. This user will be half baked from an IPA perspective, but will allow administration of the CA. Pre-creating this user may solve this problem. You can pre-create a user with all the required IPA and PKI attributes and just have pkisilent add the user cert needed. As we will be running as directory manager in this case, we will permissions to do this. 5. Create a PKIDirectory Manager account that has complete control over only the PKI suffix, and not the IPA suffix. Modify the PKI code to use only this account. This account should be able to authenticate against the Dir Srv using a client certificate, stored in the PKI specific NSS database. This of course involves setting up the relevant ACIs. We may want to consider the reverse. That only certain IPA accounts should have access to the PKI data. 6. Restart the CA. 7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. Not needed if we pre-populate as mentioned above. 8. Disable the Directory Manager's password. From here on out, access to the Dir Srv should be either certificate or Keytab only. After IPA is up and running, the management of the User Database is done by IPA. One thing that several people have asked for in IPA is the ability to manage external Roles: ones that don't map to ACIs. PKI has this requirement as well. There are a couple approaches we could take: 1. Attempt to use the current Role mechanism in IPA. This gets hidden to an outside user, but that should be OK. Checking if a user is a PKI Admin, Agent, or Auditor should be done only by a privileged account anyway. 2. Use a User Group: PKIAdmins, PKIAgents, and PKIAuditors.This is what I would suggest. 3. Create an external mechanism. Once IPA has assumed control of the IdM DB, we will still need to be able to get user certificates into the user records CMSUser field. I do not know CS well enough to say how that would work, but I assume it will be one of these two mechanisms: 1. Use the CA Administrative interface to modify an existing user to have the certificate or 2. Add a mechanism to IPA to request and apply the certificate to the IPA User. I'm guessing that the flow would be something like this: 1. Create a user (ipa user-add) 2. Assign them to the PKIAgents groups 3. Call the CA Admin interface to make the user an agent. If we do it this way, the PKI instance will need to be able to modify the IPA user record. Alternatively: 1. ipa user-add 2. ipa group-add-member 3. ipa user-cert So, a user becomes an agent on the ca by having a certificate in the user record and being a member of the relevant admin, agent or auditor group. I see this as follows: 1. ipa cms-user-add (add a user and add the auxilliary cmsuser object class) 2. ipa user-cert (contact the ca and get a certificate for this user, add this cert to the user record in the ipa database) 3. ipa group-add-member (add the user to the relevant group) At no point does PKI need to modify anything in the IPA database. As an added bonus, we get user certs. One discussion we've had on the side is about scalability. As the Databases increase in size, it might become impractical to fully synchroize the user database over to a machine that is dedicated to Certificate operations. For example, we might have a public facing machine in the DMZ that is servering CRLs and OCSP to the world. This machine would
Re: [Freeipa-devel] Unifying the PKI and IPA Directory Server instances
On Tue, 2011-11-01 at 12:49 -0400, Simo Sorce wrote: On Tue, 2011-11-01 at 12:40 -0400, Richard Megginson wrote: - Original Message - We had a brief discussion on unifying the PKI and IPA Directory Server instances. Here are my notes from it. Please fill out the details and correct me if I've mis-stated anything below. Issues: Do IPA and PKI use different suffixes? Currently not as we use completely separate instances, but we will be able to use different suffixes for some stuff. I would suggest that if we use the same database, then we use different suffixes. For one thing, we will want to be able to set ACIs so that the information here is not publicly browsable. It will also be much easier to limit the pki users ability to touch the rest of the db, and visa versa. It also makes it less likely that upgrade scripts will stomp on each other. 1. Both make changes to Config. One identified conflict is he configuration of the Uniqueness plugin It may be easy to enhance this plugin and other plugins to allow different configuration per subtree. If we confirm this conflict this will become a requirement before we can proceed. 2. PKI uses Directory Manager. This is insecure. Can it use a differen, limited admin? Or use ldapi? I don't think ldapjdk can use ldapi. It's a matter of trust for me. I do not want to trust PKI to have free reign on all data. I want it to be confined to only what it needs. So we can use ldapi and user mapping, but we wouldn't map the user to DM anyway. 3. Index strategies are different Use a union? e.g. if ipa needs attribute a indexed for equality only, but PKI needs it indexed for presence and substring only, then we can just index it for eq, sub, and pres. The problem here is finding out and how to make sure pki vs ds/ipa install and upgrade scripts do not stomp on each other. 4. make sure we have a union of the required sets of plugins 5. PKI needs to set D.S. Default Name context What is this? See my other mail, we need DS to support setting defaultNamingContext in rootdse. 6. If PKI uses the IPA datastore for users, it needs to creat the user with all the right prerequisites (object class, defaults) If both PKI and IPA use structural objectclasses, we may have to create corresponding auxiliary objectclasses so that you can mix-in both sets of objectclasses while having only one structural objectclass per entry. The problem here is much bigger, PKI simply do not have enough information to create a proper IPA user, so it should not be allowed to. This is an example of why I want to tightly control through ACIs what PKI can do and prevent it from causing issues. If we do this integration, then I'm OK with IPA creating the users. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Pki-devel] Proxy/Port work status
When I looked at one point, I noticed that /var/log/pki-ca/catalina.out was owned by root. And in fact the whole /var/log/pki-ca directory was owned by root. If the CA process runs as pkiuser, that would explain the permission denied bit. Adam, please reproduce and do not clean up. I can go in at that point and try to figure out what went wrong. Ade On Wed, 2011-08-24 at 22:29 -0400, Adam Young wrote: Had some success earlier today, but I seem to be unable to replicate it. I've been working with the full proxy.conf file lately,. and even that seems to be preventing a replica. It is quite possible that the problem is something on one of the two systems, as I've found that install/uninstall often leaves some of the files being owned by non-existent users. At this point, I'm not sure if the patch I've submitted will work on a vanilla system. Testing it has proven to be a pretty time consuming endeavour. Here's what I've gotten it down to: ON One machine, run ipa-server-install -U -r ` hostname | tr '[:lower:]' '[:upper:]'` -p freeipa4all -a freeipa4all --setup-dns --no-forwarders once that succeeds, I have to reset /etc/resolv.conf as the lab DNS server gets removed: cp ~/resolve.conf /etc then ipa-replica-prepare $REPLICA scp /var/lib/ipa/replica-info-$REPLICA.gpg root@$REPLICA: On the replica: ipa-replica-install --setup-ca replica-info-$HOSTNAME.gpg I have firewall off on master and replica At one point I had a replica install that worked with the Proxy, so I know it is possible, but for the last couple of hours this last command has been failing with: creation of replica failed: Configuration of CA failed pkisilent reports the failure in the debug log, but not the URL it is trying to reach. I'm going to modify it to give some more information in the morning. I'm not seeing anything in /var/log/httpd/error|access.log on the master, which is weird. I see this in /var/log/ipareplica-conncheck.log. We should not be trying to do anything in /home/admin 2011-08-24 21:52:18,544 DEBUG stderr= 2011-08-24 21:52:19,521 DEBUG args=/usr/bin/ssh -q -o StrictHostKeychecking=no -o UserKnownHostsFile=/dev/null ad...@vm-088.idm.lab.bos.redhat.com /usr/sbin/ipa-replica-conncheck --replica vm-116.idm.lab.bos.redhat.com --check-ca 2011-08-24 21:52:19,521 DEBUG stdout=Check connection from master to remote replica 'vm-116.idm.lab.bos.redhat.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos (88): OK PKI-CA: Directory Service port (7389): OK PKI-CA: Agent secure port (9443): OK PKI-CA: EE secure port (9444): OK PKI-CA: Admin secure port (9445): OK PKI-CA: EE secure client auth port (9446): OK PKI-CA: Unsecure port (9180): OK Connection from master to replica is OK. 2011-08-24 21:52:19,522 DEBUG stderr=Could not chdir to home directory /home/admin: No such file or directory Ade Lee noticed that the replica install is failing before it ever attempts to talk to the Master, which corresponds with what I am seeing. I see in the PKI install log that [2011-08-24 22:23:50] [error] FAILED run_command(/sbin/service pki-cad restart pki-ca), exit status=1 output=Stopping pki-ca: [FAILED] Starting pki-ca: [ OK ]^M Running this command by hand gets the same output. In less /var/log/pki-ca/catalina.out /var/lib/pki-ca/logs/catalina.out: Permission denied /var/log/pki-ca/catalina.out (END) SO it looks like another cleanup issue. ___ Pki-devel mailing list pki-de...@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
