Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
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? -- Petr³ ___ 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 DRM to IPA
On 08/21/2014 10:53 PM, Ade Lee wrote: 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) https://fedorahosted.org/freeipa/ticket/4503 - Missing man page (will be written before the plugin is implemented) https://fedorahosted.org/freeipa/ticket/4504 - Uninstall (will be fixed on Dogtag side, re-tested and enabled) https://fedorahosted.org/freeipa/ticket/4505 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. Pushed to master: a25fe00c62117cb11a1e75fbcc4960a0cfa72aab -- Petr³ ___ 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 22.8.2014 10:03, Petr Viktorin wrote: On 08/21/2014 10:53 PM, Ade Lee wrote: 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) https://fedorahosted.org/freeipa/ticket/4503 - Missing man page (will be written before the plugin is implemented) https://fedorahosted.org/freeipa/ticket/4504 - Uninstall (will be fixed on Dogtag side, re-tested and enabled) https://fedorahosted.org/freeipa/ticket/4505 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. Pushed to master: a25fe00c62117cb11a1e75fbcc4960a0cfa72aab Should the requirement of Dogtag 10.2 be reflected in a spec file? -- Petr Vobornik ___ 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 08/20/2014 09:35 PM, Rob Crittenden wrote: [...] I'm kinda with Petr, I don't know that an uninstall option is needed. On a single master install I successfully did a kra install, uninstall, re-install, so maybe the issue that Petr saw was related to cloning. Yes, on a single master it works great. -- Petr³ ___ 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 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? -- Petr³ ___ 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 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 :-) 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 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 08/18/2014 07:36 PM, Ade Lee wrote:
[...]
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.
It was never the intention of this patch to get the plugin completely
working though. That was the goal of a follow on patch being written by
Endi. This patch is already pretty long and touches a lot of code. I
propose we let Endi fix the above issue.
I understand. However, I don't know another way to do a functional test.
Without the plugin the best I can do is look if there are some extra
entries in DS, and since I don't know KRA internals I can't check if
they're correct.
With the above script, I get:
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')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/site-packages/pki/__init__.py, line 253, in
handler
return fn_call(inst, *args, **kwargs)
File /usr/lib/python2.7/site-packages/pki/key.py, line 616, in
archive_key
key_size=key_size)
File /usr/lib/python2.7/site-packages/pki/__init__.py, line 253, in
handler
return fn_call(inst, *args, **kwargs)
File /usr/lib/python2.7/site-packages/pki/key.py, line 669, in
archive_encrypted_data
return self.create_request(request)
File /usr/lib/python2.7/site-packages/pki/__init__.py, line 253, in
handler
return fn_call(inst, *args, **kwargs)
File /usr/lib/python2.7/site-packages/pki/key.py, line 527, in
create_request
response = self.connection.post(url, key_request, self.headers)
File /usr/lib/python2.7/site-packages/pki/client.py, line 70, in post
params=params)
File /usr/lib/python2.7/site-packages/requests/sessions.py, line
377, in post
return self.request('POST', url, data=data, **kwargs)
File /usr/lib/python2.7/site-packages/requests/sessions.py, line
335, in request
resp = self.send(prep, **send_kwargs)
File /usr/lib/python2.7/site-packages/requests/sessions.py, line
438, in send
r = adapter.send(request, **kwargs)
File /usr/lib/python2.7/site-packages/requests/adapters.py, line
331, in send
raise SSLError(e)
requests.exceptions.SSLError: [Errno 1] _ssl.c:1419: error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message
I have squashed the drm- kra changes and created just a single patch,
which is attached. This is the only patch needed.
I didn't find any issues except the error above.
I'm also starting a new COPR build, just to be sure we all have the most
up-to-date dogtag build.
Things are working nicely for the most part. However I still did manage
to break my installation:
- Install master and replica, both with CA and KRA
- Remove KRA on both hosts
At this point, trying to instal KRA on the replica fails:
$ sudo ipa-kra-install replica-info-file.gpg
Usage: ipa-kra-install [options] [replica_file]
ipa-kra-install: error: Too many parameters provided. No replica file
is required.
$ sudo ipa-kra-install
Directory Manager password:
===
This program will setup Dogtag KRA for the FreeIPA Server.
Configuring KRA server (pki-tomcatd): Estimated time 2 minutes 6 seconds
[1/5]: configuring KRA instance
failed to configure KRA instance Command ''/usr/sbin/pkispawn' '-s'
'KRA' '-f' '/tmp/tmp_FKfkR'' returned non-zero exit status 1
Your system may be partly configured.
Run ipa-kra-install --uninstall to clean up.
Configuration of KRA failed
This seems to cripple the installation: ipa-kra-install --uninstall will
complain that KRA is not installed. Also, ipa-kra-install on the master
will complain that it wasn't given a replica file.
I understand this is an edge case, but we should handle it if we support
uninstallation.
I'd be okay with disabling --uninstall for now and filing a ticket for
later. (After all, ipa-ca-install doesn't have --uninstall at all.)
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
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.
It was never the intention of this patch to get the plugin completely
working though. That was the goal of a follow on patch being written by
Endi. This patch is already pretty long and touches a lot of code. I
propose we let Endi fix the above issue.
I have squashed the drm- kra changes and created just a single patch,
which is attached. This is the only patch needed.
I'm also starting a new COPR build, just to be sure we all have the most
up-to-date dogtag build.
It doesn't look like the --no-host-dns option is used anywhere.
I'm kinda with Petr, I don't know that an uninstall option is needed.
On a single master install I successfully did a kra install, uninstall,
re-install, so maybe the issue that Petr saw was related to cloning.
There is no man page for ipa-kra-install
Functionally the KRA itself seems to be working ok.
rob
___
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
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 ___ 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 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)
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.
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.
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.
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?
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
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
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
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.
I do hope you're planning on adding a minimum build dep at some point?
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
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.
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 used self.log.error() instead of print, because I think at least the
Your system may be partly configured. part of the FAIL_MESSAGE should
end up in the log, not just on screen.
And now onto the code...
class drm
_create_pem_file isnt' exactly descriptive and there is no method
documentation.
_setup. Just a nit: do you want to hardcode the port? I think I'd prefer
it come via the constructor and default to 443.
It may be worth beefing up the return value docs ala what John did in
the dogtag section. I notice, for example, you always return a tuple and
one value as None in store_secret. I assume there is a reason for that
but it isn't obvious. This happens elsewhere too.
Should the copyright dates on existing files be changed? I don't think
they should be, but I'm hardly an expert.
I just did a cursory look-see in the code and things generally looked
ok. I'm hoping Petr^3 will take a closer look.
rob
I also see a scary error I can't make heads or tails of when trying to
install DRM on a replica:
$ sudo ipa-drm-install
Your system may be partly configured.
Run /usr/sbin/ipa_drm_install.py --uninstall to clean up.
HTTPConnectionPool(host='localhost', port=8080):
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
Ade Lee wrote:
Attached is a new patch. I believe I have addressed all the issues
raided by pviktori, edewata and rcrit.
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.
I do hope you're planning on adding a minimum build dep at some point?
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
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.
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.
And now onto the code...
class drm
_create_pem_file isnt' exactly descriptive and there is no method
documentation.
_setup. Just a nit: do you want to hardcode the port? I think I'd prefer
it come via the constructor and default to 443.
It may be worth beefing up the return value docs ala what John did in
the dogtag section. I notice, for example, you always return a tuple and
one value as None in store_secret. I assume there is a reason for that
but it isn't obvious. This happens elsewhere too.
Should the copyright dates on existing files be changed? I don't think
they should be, but I'm hardly an expert.
I just did a cursory look-see in the code and things generally looked
ok. I'm hoping Petr^3 will take a closer look.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
Ade Lee wrote:
Hi all,
I have rebased all the previous patches against master, and have squashed
them all into a single patch.
Its a large patch, but as many folks have already reviewed the constituent
precursor patches, most if it
should be familiar and easier to review.
The main difference with what was specified before is that the DRM database
is installed as a subtree
to o=ipaca. This means that no new replication agreements will be needed to
replicate DRM data.
Replication agreements set up for the Dogtag CA will automatically replicate
DRM data.
In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed -
with specific changes to
allow the ability to install a database as a subtree of an existing tree. At
this time, these
changes have not yet been checked into the dogtag source. You can obtain
such a build from:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/
Please review,
The BuildRequires needs to be updated to avoid a bunch of lint errors:
./make-lint
* Module ipaserver.plugins.dogtag
ipaserver/plugins/dogtag.py:249: [E0611(no-name-in-module), ] No name
'crypto' in module 'pki')
ipaserver/plugins/dogtag.py:250: [E0611(no-name-in-module), ] No name
'key' in module 'pki')
ipaserver/plugins/dogtag.py:251: [E0611(no-name-in-module), ] No name
'kra' in module 'pki')
ipaserver/plugins/dogtag.py:1952: [E1101(no-member), drm._setup]
Instance of 'PKIConnection' has no 'set_authentication_cert' member)
ipaserver/plugins/dogtag.py:1963: [E1101(no-member), drm._setup] Module
'pki' has no 'CERT_HEADER' member)
ipaserver/plugins/dogtag.py:1964: [E1101(no-member), drm._setup] Module
'pki' has no 'CERT_FOOTER' member)
* Module ipaserver.install.dogtaginstance
ipaserver/install/dogtaginstance.py:71: [E1101(no-member),
get_security_domain] Instance of 'SecurityDomainClient' has no
'get_security_domain_info' member)
I forget what back and forth we had on DRM vs no DRM by default, but is
it right to have no option at all to add one at install time, ala DNS?
My first install failed:
Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: ln: failed to create
symbolic link ‘/var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak’: Permission
denied
Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: SUCCESS: Successfully
archived
'/var/lib/pki/pki-tomcat/conf/ca/archives/CS.cfg.bak.20140718153836'
Jul 18 15:38:36 ipa.example.com pkidaemon[16516]: WARNING: Failed to
backup '/var/lib/pki/pki-tomcat/conf/ca/CS.cfg' to
'/var/lib/pki/pki-tomcat/conf/ca/CS.cfg.bak'!
Jul 18 15:38:36 ipa.example.com pkidaemon[16516]:
/usr/share/pki/scripts/operations: line 1579: 0: command not found
Jul 18 15:38:36 ipa.example.com systemd[1]:
pki-tomcatd@pki-tomcat.service: control process exited, code=exited status=1
Jul 18 15:38:36 ipa.example.com systemd[1]: Failed to start PKI Tomcat
Server pki-tomcat.
This is due to SELinux issues:
type=AVC msg=audit(1405712316.049:1656): avc: denied { setfscreate }
for pid=16702 comm=cp scontext=system_u:system_r:pki_tomcat_t:s0
tcontext=system_u:system_r:pki_tomcat_t:s0 tclass=process
type=AVC msg=audit(1405712316.049:1657): avc: denied { relabelfrom }
for pid=16702 comm=cp name=CS.cfg.bak.20140718153836 dev=dm-0
ino=431097 scontext=system_u:system_r:pki_tomcat_t:s0
tcontext=system_u:object_r:pki_tomcat_etc_rw_t:s0 tclass=file
type=AVC msg=audit(1405712316.050:1658): avc: denied { create } for
pid=16703 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
I put it into permissive and continued.
The installer still references backing up /root/drmcert.p12 but it isn't
created by default.
The estimate for configuring the DRM seems off. On my VM it took 126
seconds, not 210. Mileage may vary but since my box was the source for
all the other timings :-)
On the plus side the DRM seems to work. I used the ca-agent cert and was
able to follow the steps at
https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Testing_the_Key_Archival_and_Recovery_Setup.html
to issue and recover a key.
rob
___
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 07/16/2014 02:55 PM, Petr Viktorin wrote:
On 07/14/2014 11:45 AM, Ade Lee wrote:
Hi all,
I have rebased all the previous patches against master, and have
squashed them all into a single patch.
Its a large patch, but as many folks have already reviewed the
constituent precursor patches, most if it
should be familiar and easier to review.
I think it would be nice to have the fixes that aren't related to DRM
(e.g. style issues) separate, so the patch can be reverted easily. But,
what's done is done. Thanks for the cleanup!
The main difference with what was specified before is that the DRM
database is installed as a subtree
to o=ipaca. This means that no new replication agreements will be
needed to replicate DRM data.
Replication agreements set up for the Dogtag CA will automatically
replicate DRM data.
In order for this patch to work, a new 10.2 build of Dogtag 10.2 is
needed - with specific changes to
allow the ability to install a database as a subtree of an existing
tree. At this time, these
changes have not yet been checked into the dogtag source. You can
obtain such a build from:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/
Please review,
I've started reading the code; here are my thoughts on the first part:
In ipa-ca-install and ipa-replica-install, you only ever set
REPLICA_INFO_TOP_DIR to None. In Python, global has module scope,
it's not for the entire process. (And it's bad practice anyway.)
You'll need to pass it around explicitly, perhaps store it in
ReplicaConfig.
It would be nice to use the admintool framework for the new script,
instead of copying the old boilerplate code again. See e.g.
ipa-server-certinstall for an example.
Logging functions interpolate their arguments, so you should use e.g.
root_logger.critical(failed to configure %s instance %s,
subsystem, e)
instead of using the % operator.
Also, in e.g.
root_logger.debug(
'Unable to determine PIN for the Dogtag instance: %s' % str(e))
the s in %s means convert to string, so explicit str() isn't
necessary.
installutils.create_replica_config: Any time you call sys.exit(), please
log a message so we know why the log file ends.
In ipa-drm-install, why do you read /etc/ipa/default.conf manually? The
information is available in api.env once api is finalized.
In ipa-server-install, do we want to display the message about backing
up /root/drmcert.p12 even if DRM is not installed?
Please use path constants from ipaplatform.base.paths, or add new ones
if necessary, instead of DogtagInstance.{AGENT_P12_PATH,AGENT_P12_PATH}.
In ipa-upgradeconfig, you hardcoded '/etc/named.keytab'. Please change
that back to paths.NAMED_KEYTAB.
Same in CAInstance.uninstall with /usr/bin/pkiremove.
In ipa-upgradeconfig.find_subject_base, the docstring should mention to
DsInstance.find_subject_base's docstring rather than being a copy; we
dont' want them getting out of sync.
In DsInstance.find_subject_base, don't use a bare `except:`, at least do
`except Exception:`, so you don't e.g. disable Ctrl+C.
In CADSInstance.uninstall, you don't need the _running and _user_exists
variables at all, just call the functions.
Same in CAInstance.__create_ra_agent_db for _stdout, _stderr, _returncode.
Same in CAInstance.uninstall for _user_exists.
In DogtagInstance, stop_tracking_certificates was moved here from
cainstance, but it no longer stops tracking ipaCert in HTTPD_ALIAS_DIR.
Is that intended?
In CAInstance.__init__, when calling DogtagInstance.__init__, consider
using super, and naming the arguments for clarity:
super(CAInstance, self).__init__(
realm=realm,
subsystem=CA,
service_desc=certificate server,
dogtag_constants=dogtag_constants,
)
Same in DogtagInstance, DRMInstance.
Since CAInstance inherits from DogtagInstance, the `enable`,
`start_instance`, `stop_instance`, `http_proxy` methods that just call
the superclass are unnecessary.
IMO the comment from CAInstance.__enable was important, it should be in
DogtagInstance.enable.
In DogtagInstance.spawn_instance, it's not nice to modify lists the
caller pased in. Take a copy of the nolog first. Ideally combine that
with the conversion to tuple, and allow any sequence to be passed in:
nolog_list = tuple(nolog_list) + (self.admin_password,
self.dm_password)
In CAInstance.__create_ca_user, it's better to use functions instead of
staticmethods, unless you'll want to override them in subclasses (which
you're explicitly discouraging here, by using the double underscore).
Anyway I don't get why you want these to be staticmethods.
dogtaginstance.py, drminstance.py: Avoid star imports, especially in new
code. AFAICS you're only using root_logger from ipapython.ipa_log_manager.
Also consider using an class-specific logger:
class DogtagInstance(...):
def __init__(...):
...
self.log = ipa_log_manager.log_mgr.get_logger(self)
later:
Re: [Freeipa-devel] [PATCH] - Add DRM to IPA
On 07/14/2014 11:45 AM, Ade Lee wrote:
Hi all,
I have rebased all the previous patches against master, and have squashed them
all into a single patch.
Its a large patch, but as many folks have already reviewed the constituent
precursor patches, most if it
should be familiar and easier to review.
I think it would be nice to have the fixes that aren't related to DRM
(e.g. style issues) separate, so the patch can be reverted easily. But,
what's done is done. Thanks for the cleanup!
The main difference with what was specified before is that the DRM database is
installed as a subtree
to o=ipaca. This means that no new replication agreements will be needed to
replicate DRM data.
Replication agreements set up for the Dogtag CA will automatically replicate
DRM data.
In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed -
with specific changes to
allow the ability to install a database as a subtree of an existing tree. At
this time, these
changes have not yet been checked into the dogtag source. You can obtain such
a build from:
http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/
Please review,
I've started reading the code; here are my thoughts on the first part:
In ipa-ca-install and ipa-replica-install, you only ever set
REPLICA_INFO_TOP_DIR to None. In Python, global has module scope,
it's not for the entire process. (And it's bad practice anyway.)
You'll need to pass it around explicitly, perhaps store it in ReplicaConfig.
It would be nice to use the admintool framework for the new script,
instead of copying the old boilerplate code again. See e.g.
ipa-server-certinstall for an example.
Logging functions interpolate their arguments, so you should use e.g.
root_logger.critical(failed to configure %s instance %s,
subsystem, e)
instead of using the % operator.
installutils.create_replica_config: Any time you call sys.exit(), please
log a message so we know why the log file ends.
In ipa-drm-install, why do you read /etc/ipa/default.conf manually? The
information is available in api.env once api is finalized.
In ipa-server-install, do we want to display the message about backing
up /root/drmcert.p12 even if DRM is not installed?
Please use path constants from ipaplatform.base.paths, or add new ones
if necessary, instead of DogtagInstance.{AGENT_P12_PATH,AGENT_P12_PATH}.
In ipa-upgradeconfig, you hardcoded '/etc/named.keytab'. Please change
that back to paths.NAMED_KEYTAB.
Same in CAInstance.uninstall with /usr/bin/pkiremove.
In ipa-upgradeconfig.find_subject_base, the docstring should mention to
DsInstance.find_subject_base's docstring rather than being a copy; we
dont' want them getting out of sync.
In DsInstance.find_subject_base, don't use a bare `except:`, at least do
`except Exception:`, so you don't e.g. disable Ctrl+C.
In CADSInstance.uninstall, you don't need the _running and _user_exists
variables at all, just call the functions.
Same in CAInstance.__create_ra_agent_db for _stdout, _stderr, _returncode.
Same in CAInstance.uninstall for _user_exists.
In DogtagInstance, stop_tracking_certificates was moved here from
cainstance, but it no longer stops tracking ipaCert in HTTPD_ALIAS_DIR.
Is that intended?
In CAInstance.__init__, when calling DogtagInstance.__init__, consider
using super, and naming the arguments for clarity:
super(CAInstance, self).__init__(
realm=realm,
subsystem=CA,
service_desc=certificate server,
dogtag_constants=dogtag_constants,
)
Since CAInstance inherits from DogtagInstance, the `enable`,
`start_instance`, `stop_instance`, `http_proxy` methods that just call
the superclass are unnecessary.
IMO the comment from CAInstance.__enable was important, it should be in
DogtagInstance.enable.
In DogtagInstance.spawn_instance, it's not nice to modify lists the
caller pased in. Take a copy of the nolog first. Ideally combine that
with the conversion to tuple, and allow any sequence to be passed in:
nolog_list = tuple(nolog_list) + (self.admin_password,
self.dm_password)
In CAInstance.__create_ca_user, it's better to use functions instead of
staticmethods, unless you'll want to override them in subclasses (which
you're explicitly discouraging here, by using the double underscore).
Anyway I don't get why you want these to be staticmethods.
(Note to self: I'm at line 1866 of the patch)
--
Petr³
___
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 7/14/2014 4:45 AM, Ade Lee wrote: Hi all, I have rebased all the previous patches against master, and have squashed them all into a single patch. Its a large patch, but as many folks have already reviewed the constituent precursor patches, most if it should be familiar and easier to review. The main difference with what was specified before is that the DRM database is installed as a subtree to o=ipaca. This means that no new replication agreements will be needed to replicate DRM data. Replication agreements set up for the Dogtag CA will automatically replicate DRM data. In order for this patch to work, a new 10.2 build of Dogtag 10.2 is needed - with specific changes to allow the ability to install a database as a subtree of an existing tree. At this time, these changes have not yet been checked into the dogtag source. You can obtain such a build from: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/build/21936/ Please review, Thanks, Ade Some comments/questions: 1. The suffix for the DRM is o=ipadrm,o=ipaca. It's probably better to change it to ou=drm,o=ipaca since another ipa under o=ipaca would be redundant. In the future we might want to migrate the current CA entries into ou=ca,o=ipaca subtree so that ou=ca and ou=drm will be at the same level, and keep o=ipaca as the parent tree for Dogtag subsystems. Alternatively, we probably could merge o=ipaca and o=ipadrm since the structure of each tree seems to have been designed to share the user and groups, but still maintain separate structure for CA/KRA-specific storage. The current Dogtag probably doesn't support this, but it's a possibility with additional works. 2. If a clone doesn't have DRM installed but it's getting replicated DRM data, is there any concern? 3. The Dogtag dependency should be updated to 10.2. Also the dogtag_version and DOGTAG_VERSION variables are probably not granular enough to detect the minor version. This message should be updated too: Dogtag must be version 10.1 or above to install DRM 4. It's probably unnecessary to override the following methods in CAInstance since they only call the base methods. * enable() * start_instance() * stop_instance() * restart_instance() * http_proxy() 5. The following code in ipaserver/plugins/dogtag.py will no longer work due to a recent change in Dogtag: transport_cert = kraclient.system_certs.get_transport_cert() tcert = transport_cert[ len(pki.CERT_HEADER): len(transport_cert) - len(pki.CERT_FOOTER)] crypto.import_cert( self.transport_nick, base64.decodestring(tcert), u,u,u) This is how it's used now in drmtest.py: transport_cert = kraclient.system_certs.get_transport_cert() print Subject DN: + transport_cert.subject_dn print transport_cert.encoded crypto.import_cert(transport_nick, transport_cert, u,u,u) 6. The code in ipaserver/install/drminstance.py creates a file /tmp/drm.p12. How long will this file stay in the /tmp folder? Should it be moved into a more permanent location? If it's a temporary file, can we use the python tempfile module? -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Ade Lee wrote: Attached is a patch that adds the script ipa-drm-install. This script will be used to install a drm in any ipa server that contains a Dogtag CA. Right now, it works for a master. I will add logic in a subsequent patch to allow the installation on a replica using the same script. This patch is to applied on top of the previous one. So, patch 2 and then patch 3. I will create a patch to address the issues mentioned below, as well as some other formatting issues reported by pycharm. I think the ipa-dns-install change should be committed separately. It is surprising that pylint didn't catch that. Please a comment to find_subject_base() that it can only be executed AFTER the ipa server is configured, the api is initialized elsewhere and requires that a ticket already have been acquired. I understand why this call is here, we just need to be clear it is used post-install and requires some pre-setup by the caller. Need a man page for ipa-drm-install. Running the uninstaller completes, then proceeds to install the DRM. I don't think the certmonger warnings apply because some of the certs are duplicates of the CA certs, so if you untracked them you would eventually end up not renewing the subsystem certs and your clone CA would fail. nit, some trailing white space after add_record_to_hosts() The tool failed to add a DRM in my test. The debug log doesn't seem to contain anything interesting at all. The drm install log contained: 2014-04-21T19:00:44Z DEBUG Starting external process 2014-04-21T19:00:44Z DEBUG args=/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ 2014-04-21T19:01:09Z DEBUG Process finished, return code=1 2014-04-21T19:01:09Z DEBUG stdout=Loading deployment configuration from /tmp/tmpWcj8rJ. Installing KRA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/kra/deployment.cfg. Installation failed. 2014-04-21T19:01:09Z DEBUG stderr= 2014-04-21T19:01:09Z CRITICAL failed to configure KRA instance Command '/usr/sbin/pkispawn -s KRA -f /tmp/tmpWcj8rJ' returned non-zero exit status 1 Thanks, Ade On Tue, 2014-04-15 at 11:41 -0400, Rob Crittenden wrote: Ade Lee wrote: Attached a new patch to address some of the concerns below, specifically I created a new base class DogtagInstance, in which much of the common CA/KRA code is placed. I'm sure we could go further in reducing duplication, and I'm open to further suggestions and refinements. I did not tackle the packaging and spec file dependencies, because I'd like some clearer direction on how we want to proceed here. In any case, I think the splitting of the ipa packages into ca and possibly kra packages should be a separate patch. As before, with this patch you can: - install a ca and drm using ipa-server-install - install a ca and drm replica using ipa-replica-prepare hostname ipa-replica-install --setup-ca --setup-drm replia file You need to use a PKI build from the 10.2 (master) branch). One such build is given below: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo The terms KRA and DRM tend to be used interchangeably. Should we pick one? Need to bump the version number in install/conf/ipa-pki-proxy.conf so that upgrades get the new LocationMatch. ipa-replica-install still uses the if/then to set the value of enable_drm when it can be reduced like you did in ipa-server-install. In ipa-server-install you have an extra comment, probably left for yourself: # code to create drm here In dogtaginstance.py there are a few direct references to DRM in comments and output. cainstance.py doesn't need to override is_installed.py I also don't think you need the explicit definitions for enable, start_instance, etc. Those should be inherited from the DogtagInstance class, in both cainstance.py and drminstance.py. I think spawn_instance should take an option to add things to nolog in case there are server-independent things we don't want to log. I don't want to pile too much on, but it seems to me that if we are going to copy in default.conf then we can do away with realm_info completely and just use default.conf. Both would need to be supported for a while though. Martin, what do you think? I still have quite a bit of functional testing to go. I've only installed a fresh standalone master. Still need to do upgrade and replication testing. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Ade Lee wrote: Attached a new patch to address some of the concerns below, specifically I created a new base class DogtagInstance, in which much of the common CA/KRA code is placed. I'm sure we could go further in reducing duplication, and I'm open to further suggestions and refinements. I did not tackle the packaging and spec file dependencies, because I'd like some clearer direction on how we want to proceed here. In any case, I think the splitting of the ipa packages into ca and possibly kra packages should be a separate patch. As before, with this patch you can: - install a ca and drm using ipa-server-install - install a ca and drm replica using ipa-replica-prepare hostname ipa-replica-install --setup-ca --setup-drm replia file You need to use a PKI build from the 10.2 (master) branch). One such build is given below: http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/vakwetu-dogtag-fedora-20-x86_64.repo The terms KRA and DRM tend to be used interchangeably. Should we pick one? Need to bump the version number in install/conf/ipa-pki-proxy.conf so that upgrades get the new LocationMatch. ipa-replica-install still uses the if/then to set the value of enable_drm when it can be reduced like you did in ipa-server-install. In ipa-server-install you have an extra comment, probably left for yourself: # code to create drm here In dogtaginstance.py there are a few direct references to DRM in comments and output. cainstance.py doesn't need to override is_installed.py I also don't think you need the explicit definitions for enable, start_instance, etc. Those should be inherited from the DogtagInstance class, in both cainstance.py and drminstance.py. I think spawn_instance should take an option to add things to nolog in case there are server-independent things we don't want to log. I don't want to pile too much on, but it seems to me that if we are going to copy in default.conf then we can do away with realm_info completely and just use default.conf. Both would need to be supported for a while though. Martin, what do you think? I still have quite a bit of functional testing to go. I've only installed a fresh standalone master. Still need to do upgrade and replication testing. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
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 \
+
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
On 04/07/2014 10:40 PM, Rob Crittenden wrote: Ade Lee wrote: This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be pushed ASAP. Oops, looks like a change that should go to IPA 3.3.x. What is the implication? freeipa-spec.in needs a dependency on pki-kra. Let us stop here. Please see a following RFE I filed: https://fedorahosted.org/freeipa/ticket/4058 I would prefer it KRA files and specifics would be in a new subpackage like freeipa-server-kra. Otherwise we will need to rework it again when we would be splitting CA to freeipa-server-pki in 4.1. 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 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. 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
Martin Kosek wrote: On 04/07/2014 10:40 PM, Rob Crittenden wrote: Ade Lee wrote: This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be pushed ASAP. Oops, looks like a change that should go to IPA 3.3.x. What is the implication? freeipa-spec.in needs a dependency on pki-kra. Let us stop here. Please see a following RFE I filed: https://fedorahosted.org/freeipa/ticket/4058 I would prefer it KRA files and specifics would be in a new subpackage like freeipa-server-kra. Otherwise we will need to rework it again when we would be splitting CA to freeipa-server-pki in 4.1. Yes, that is a question I didn't ask: Is the DRM going to be configured by default on all new installs? I would prefer to start the right modularization now as I do not think that every FreeIPA server needs to run CA/KRA, i.e. it does not need to have the bits installed either. I think the decision on a separate sub-package will be dependent upon whether it is default or not, otherwise we can get away with freeipa-server-ca and just lump everything in there. I am also quite worried about the duplication that the new drminstance.py introduces. There is a lot of functions which do more or less the same thing and have most of the handling code the same with only a very small and predictable pki/kra change. For example __http_proxy function seems to be exactly the same. It would be great to avoid this duplication and rather have some common ground utilized by both PKI and KRA. Otherwise it will be very difficult to maintain the new code. I touched on some of that too, but some of this is just inevitable I think which is why I didn't pound on it too hard. An abstraction would be nice, but I'm not sure abstracting for two things, and only in the installer, is worth the effort. I could be wrong. rob ___ Freeipa-devel mailing list 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
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
On 04/04/2014 02:50 PM, 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 Any takers? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Dmitri Pal wrote: On 04/04/2014 02:50 PM, 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 Any takers? I'm going to look at it. Ade has provided a COPR build of the dogtag bits we'll need at http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/ rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
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. freeipa-spec.in needs a dependency on pki-kra. Is it necessary to check for pkispawn/destroy in check_inst()? That should be handled by the CA install, right? You need to bump the version in ipa-pki-proxy.conf so that upgrades get the new configuration. Rather than this: +if setup_drm: +fd.write(enable_drm=True\n) +else: +fd.write(enable_drm=False\n) Why not: fd.write(enable_drm=%s\n % setup_drm) If o=ipadrm is a new root we'll need to backup/restore it right? You should import PKI_USER and HTTPD_CONFD from cainstance.py rather than redefining them. You should probably call the is_installed() from cainstance.py rather than redefining this. The function might be ok but I'd replace the contents with: ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) return ca.is_installed() If the DRM is already installed we don't have a way to uninstall it so we shouldn't recommend that as an option. The value for pki_issuing_ca_uri doesn't create a valid URL (missing //). You should use this form instead: config.set(KRA, pki_issuing_ca_uri, https://%s; % ipautil.format_netloc(self.fqdn, 443)) I think that update_people_entry() should probably be moved into installutils.py and used for both the CA and DRM instances. It makes a certain amount of sense to use /etc/ipa/default.conf. It may be outside the scope here but it if we're including it, but would it be better to use that for everything rather than splitting between two files? The install failed for me. I've attached the KRA debug log. rob debug.gz Description: GNU Zip compressed data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
