Re: [Freeipa-devel] [PATCH 0379 - 0393] Winter code cleanup

[Jan Cholasta]

Hi,

On 17.12.2015 02:11, Martin Basti wrote:

Hello,
following patches cleanup the code and add checks to pylint to avoid the
mess again

Patches: 379-381:
the most important patches, they cleanup imports

Patch 382:
enables various pylint checks, we may reduce the list of check if needed.


Would it be possible to turn this into a blacklist of disabled warnings 
rather than a whitelist of enabled warnings?




Patches 383 - 393:
remove minor issues from code, and enable particular checks
Feel free to nack patches/checks that should not be there.

Please apply patches in order.

Martin^2




Honza

--
Jan Cholasta

--
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 0026] ipatests: replace the test-example.com domain in tests

[Milan Kubík]

Applies to ipa-4-3 and master. Reason in commit message.

--
Milan Kubik

From 912ecd6c48149696eb8ca3c60644e5b24af6e534 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= 
Date: Wed, 16 Dec 2015 16:27:34 +0100
Subject: [PATCH] ipatests: replace the test-example.com domain in tests

Latest DNS patches introduced checks for the added zones.
If a zone exists, the add fails if not forced. The domain
test-example.com is resolvable thus causing errors in the test.

Also adds missing __init__.py to the ipatests.test_cmdline package.
---
 ipatests/test_cmdline/__init__.py |  3 +++
 ipatests/test_cmdline/test_cli.py | 57 ---
 2 files changed, 33 insertions(+), 27 deletions(-)
 create mode 100644 ipatests/test_cmdline/__init__.py

diff --git a/ipatests/test_cmdline/__init__.py b/ipatests/test_cmdline/__init__.py
new file mode 100644
index ..9da42e7b4d782ef596e8fda080b6c1994b901866
--- /dev/null
+++ b/ipatests/test_cmdline/__init__.py
@@ -0,0 +1,3 @@
+#
+# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
+#
diff --git a/ipatests/test_cmdline/test_cli.py b/ipatests/test_cmdline/test_cli.py
index c2203e68f1f90505a457de5cdf17f2716cbcaa0d..ddc4c71a89a245bf2066f6ec0831cecdc3255d35 100644
--- a/ipatests/test_cmdline/test_cli.py
+++ b/ipatests/test_cmdline/test_cli.py
@@ -14,6 +14,8 @@ import pytest
 if six.PY3:
 unicode = str
 
+TEST_ZONE = u'zoneadd.%(domain)s' % api.env
+
 
 @pytest.mark.tier0
 class TestCLIParsing(object):
@@ -123,9 +125,9 @@ class TestCLIParsing(object):
 all=False)
 
 def test_dnsrecord_add(self):
-self.check_command('dnsrecord-add test-example.com ns --a-rec=1.2.3.4',
+self.check_command('dnsrecord-add %s ns --a-rec=1.2.3.4' % TEST_ZONE,
 'dnsrecord_add',
-dnszoneidnsname=u'test-example.com',
+dnszoneidnsname=TEST_ZONE,
 idnsname=u'ns',
 arecord=u'1.2.3.4',
 structured=False,
@@ -135,33 +137,33 @@ class TestCLIParsing(object):
 
 def test_dnsrecord_del_all(self):
 try:
-self.run_command('dnszone_add', idnsname=u'test-example.com')
+self.run_command('dnszone_add', idnsname=TEST_ZONE)
 except errors.NotFound:
 raise nose.SkipTest('DNS is not configured')
 try:
 self.run_command('dnsrecord_add',
-dnszoneidnsname=u'test-example.com',
+dnszoneidnsname=TEST_ZONE,
 idnsname=u'ns', arecord=u'1.2.3.4', force=True)
 with self.fake_stdin('yes\n'):
-self.check_command('dnsrecord_del test-example.com ns',
+self.check_command('dnsrecord_del %s ns' % TEST_ZONE,
 'dnsrecord_del',
-dnszoneidnsname=u'test-example.com',
+dnszoneidnsname=TEST_ZONE,
 idnsname=u'ns',
 del_all=True,
 structured=False)
 with self.fake_stdin('YeS\n'):
-self.check_command('dnsrecord_del test-example.com ns',
+self.check_command('dnsrecord_del %s ns' % TEST_ZONE,
 'dnsrecord_del',
-dnszoneidnsname=u'test-example.com',
+dnszoneidnsname=TEST_ZONE,
 idnsname=u'ns',
 del_all=True,
 structured=False)
 finally:
-self.run_command('dnszone_del', idnsname=u'test-example.com')
+self.run_command('dnszone_del', idnsname=TEST_ZONE)
 
 def test_dnsrecord_del_one_by_one(self):
 try:
-self.run_command('dnszone_add', idnsname=u'test-example.com')
+self.run_command('dnszone_add', idnsname=TEST_ZONE)
 except errors.NotFound:
 raise nose.SkipTest('DNS is not configured')
 try:
@@ -169,26 +171,26 @@ class TestCLIParsing(object):
u'2 1 FD2693C1EFFC11A8D2BE57229212A04B45663791')
 for record in records:
 self.run_command('dnsrecord_add',
-dnszoneidnsname=u'test-example.com', idnsname=u'ns',
+dnszoneidnsname=TEST_ZONE, idnsname=u'ns',
 sshfprecord=record)
 with self.fake_stdin('no\nyes\nyes\n'):
-self.check_command('dnsrecord_del test-example.com ns',
+self.check_command('dnsrecord_del %s ns' % TEST_ZONE,
 'dnsrecord_del',
-dnszoneidnsname=u'test-example.com',
+dnszoneidnsname=TEST_ZONE,
 idnsname=u'ns',
 del_all=False,
 sshfprecord=records,
 structured=False)
 finally:
-self.run_command('dnszone_del', idnsname=u'test-example.com')
+self.run_command('dnszone_del', idnsname=TEST_ZONE)
 
 de

Re: [Freeipa-devel] [PATCH 016 - 017] First part of the replica promotion tests + testplan

[Martin Basti]

On 16.12.2015 15:39, Martin Basti wrote:



On 15.12.2015 10:29, Oleg Fayans wrote:

Hi Martin,

The updated patches are attached. Patch 0017 includes all changes from
patch 0018, so, if you approve this one, there would be no need to
continue with the review of 0018. This one contains all changes related
to you remarks from 0018 review. Please see my explanation on the
stdout+stderr part in the thread from patch 0018.
With these two patches applied one of the tests fails due this bug:
https://fedorahosted.org/freeipa/ticket/5550

On 12/09/2015 12:17 PM, Martin Basti wrote:


On 09.12.2015 12:10, Martin Basti wrote:


On 09.12.2015 11:14, Oleg Fayans wrote:

Hi Martin

On 12/09/2015 10:30 AM, Martin Basti wrote:

On 08.12.2015 23:48, Oleg Fayans wrote:
Substituted a hardcoded suffix name with a constant 
DOMAIN_SUFFIX_NAME


On 12/08/2015 02:33 PM, Oleg Fayans wrote:

Hi all,


The patches are rebased against the current master.

On 12/02/2015 05:10 PM, Martin Basti wrote:

On 02.12.2015 16:18, Oleg Fayans wrote:

Hi Martin,

On 12/01/2015 04:08 PM, Martin Basti wrote:

On 27.11.2015 16:26, Oleg Fayans wrote:

And patch N 16 passes lint too:

On 11/27/2015 04:03 PM, Oleg Fayans wrote:

Hi,

On 11/27/2015 03:26 PM, Martin Basti wrote:

On 27.11.2015 15:04, Oleg Fayans wrote:

Hi Martin,

All your suggestions were taken into account. Both 
patches are

updated. Thank you for your help!

On 11/26/2015 10:50 AM, Martin Basti wrote:

On 26.11.2015 10:04, Oleg Fayans wrote:

Hi Martin,

I agree to all your points but one. please, see my 
comment

below

On 11/25/2015 07:42 PM, Martin Basti wrote:

Hi,

0) Note
Please be aware of
https://fedorahosted.org/freeipa/ticket/5469
during
KRA testing

1)
Please do not use MIN and MAX_DOMAIN_LEVEL constants,
this may
change
over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for 
domain

level 0
and 1

2)
Why uninstall KRA then server, is not enough just 
uninstall

server
which
covers KRA uninstall?

+def teardown_method(self, method):
+for host in self.replicas:
+ host.run_command(self.kra_uninstall,
raiseonerr=False)
+ tasks.uninstall_master(host)


3)
Can be this function more generic? It should allow 
specify

host
where
KRA should be installed not just master

+def test_kra_install_master(self):
+ self.master.run_command(self.kra_install)


4)

TestLevel0(Dummy):
Can be the test name more specific, something like
TestReplicaPromotionLevel0


5)
please remove this, the patch is on review and it 
will be

pushed
sooner
than tests
+@pytest.mark.xfail  # Ticket N 5455

and as I mentioned in ticket #5455, I cannot reproduce
it with
ipa-kra-install, so please provide steps to reproduce if
you
insist
that
this still does not work as expected with KRA.

6) This is completely wrong, it removes everything 
that we

tried to
achieve with previous patches with domain level in CI

Actually, being able to configure domain level per class
is WAY
more
convenient, than to always have to think which domain
level is
appropriate for which particular test during jenkins job
configuration. In fact, I should have thought about it
from the
very
beginning. For example, in test_replica_promotion.py we
have on
class,
which intiates with domain level = 1, while others - with
domain
level
0. With config-based approach, we would have to 
implement a

separate
step that raises domain level. Overall, I am against the
approach,
when you have to remember to set certain domain level in
config
for
any particular test. The tests themselves should be 
aware of

the
domain level they need.
I do not say that we should not have something that 
overrides

settings
in from config in a particular test case, I say your 
patch is

doing it
wrong.

I agree it is useful to have param domain_level in
install_master,
and
intall_topo methods,  but is cannot be MAX_DOMAIN_LEVEL by
default,
because with your current patch the domain_level in 
config is

not
used
at all, it will be always MAX_DOMAIN_LEVEL

For example I want to achieve this goal:
test_vault.py, this test suite can run on domain level1
and on
domain
level0, so with one test we can test 2 domain levels just
with
putting
domain level into config file.

I agree that with extraordinary test like replica
promotion test
is, we
need something that allows override the config file.

As I said bellow, domain_level default value should be
None in
install_master and install_topo plugin. If domain level 
was

specified
use the specified one, if not (value is None) use the 
domain

level
from
config file.

Agreed :)


Martin
[PATCH] Enabled setting domain_level per class 
derived from

TestIntegration

When I configure domain level 0 in yaml config, how 
is this

supposed to
get into install methods when you removed that code?

-"--domain-level=%i" % host.config.domain_level
+"--domain-level=%i" % domain_level


You always use MAX_DOMAIN_LEVEL in this case or 
whatever is

specified in
domain_level option.
I suggest to use domain_l

Re: [Freeipa-devel] [PATCH 0364, 0367] ipa-kra-install: allow first KRA to be installed on replica

[Martin Basti]

On 07.12.2015 14:31, Martin Babinsky wrote:

On 12/02/2015 05:24 PM, Martin Basti wrote:



On 02.12.2015 14:52, Martin Babinsky wrote:

On 11/30/2015 06:29 PM, Martin Basti wrote:



On 30.11.2015 14:16, Martin Babinsky wrote:

On 11/27/2015 05:02 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/5460

I tested just master, I will test ipa-4-2 later.
patch attached.




ACK for the master branch.

Thanks, additional patch improves error message when 
ipa-replica-install

--setup-ca --setup-kra is executed and KRA is not installed anywhere
yet.

I'm working on patches for ipa-4-2 branch

Martin


ACK for patch 367.


Pushed to master: bbbe411f357b7fbad533b5211a90bb0558b1abbe

IPA 4.2 patches attached.


ACK.


Pushed to ipa-4-2: cacca7bade36d5b01dd8c3568e41abb2b183aa50

--
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

Re: [Freeipa-devel] [PATCH] ca-less tests updated - POC

[Oleg Fayans]

Hi David,

On 12/16/2015 03:35 PM, David Kupka wrote:
> On 06/11/15 14:04, Oleg Fayans wrote:
>> Hi Jan,
>>
>> On 11/06/2015 09:01 AM, Jan Cholasta wrote:
>>> Actually it might be better to keep them, but fix them to expect
>>> ipa-server-certinstall to success.
>>
>> Done. Updated patch attached.
>> Also in the patch 0013 I removed a trailing whitespace which caused lint
>> to complain
>>
>> Now with domain level 0 the test output looks like this:
>>
>> [11:40:51]ofayans@vm-076:~]$ ipa-run-tests
>> test_integration/test_caless.py
>> 
>>
>> test session starts
>> =
>>
>>
>> platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
>> plugins: multihost, sourceorder
>> collected 88 items
>>
>> test_integration/test_caless.py
>> ..xx..ss...xxssxx..ss...
>>
>>
>>
>> = 76
>> passed, 6 skipped, 6 xfailed in 7871.10 seconds
>> =
>>
>>
>>>
>>> On 6.11.2015 08:47, Jan Cholasta wrote:
 Hi Oleg,

 I think you can just remove
 TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are
 imported correctly in this case and I didn't see anything break.

 Honza

 On 5.11.2015 20:20, Oleg Fayans wrote:
> Patch 0014 updated and passes lint
>
> On 11/05/2015 03:41 PM, Oleg Fayans wrote:
>> Wait a bit, the patch has problems with pylint: it does not build :)
>> The updated version (without the setupmaster nonsense) is being
>> tested
>> now.
>>
>> On 11/05/2015 08:45 AM, Oleg Fayans wrote:
>>> Hi Jan,
>>>
>>> Could you take a look at these, whenever you are free?
>>>
>>> On 10/30/2015 02:57 PM, Oleg Fayans wrote:
 Hi,

 The following patches contain updates to ca-less integration tests.
 It's still a proof of concept: 2 tests still fail seemingly due to
 the
 change in target system logic (marked as xfail with "ask jcholast
 comment")

 The test output looks like this:

 $ ipa-run-tests test_integration/test_caless.py --pdb
 







 test session starts
 =








 platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
 plugins: multihost, sourceorder
 collected 88 items

 test_integration/test_caless.py
 ..xx..sssss.ss.xx..ssxx.









 

 53

 passed, 29 skipped, 6 xfailed in 5620.17 seconds
 =



 Numerous skips correspond to the tests related to
 ipa-replica-prepare
 (unsupported under domain level 1)



>>>
>>
>
>
>


>>>
>>>
>>
>>
>>
>> This body part will be downloaded on demand.
>>
> Hello, thanks for updated patches. I'm really sorry it took so long
> before I got to them.
> There was change in ipapython.ipautil.run that happened after you sent
> the patches. Feel free to squash attached patch that fixes it.

Already noticed this and made the similar fix.

> 
> Unfortunately I see a lot of test failing with domain-level 0:
> http://fpaste.org/301657/50275682/
> 
> domain-level 1 (domain-level 1: http://fpaste.org/301658/02757191/)
> seems better. There are 2 failing test that you're probably mentioning
> in commit message plus one that I think is bug in code rather than bug
> in tests.
> Do you have any proposal for fixing the two failing tests?

I am working on it right now.

> 
> One nitpick: Please use mail for notes like "need further consulting
> ..." rather that commit message. When the patch gets accepted it will
> still need modification before push just because inappropriate commit
> message.

Good to know, thank you!

> 
> Thank you!

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
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

Re: [Freeipa-devel] certmonger everywhere

[Alexander Bokovoy]

On Wed, 16 Dec 2015, Simo Sorce wrote:

On Wed, 2015-12-16 at 15:41 +0100, Jan Cholasta wrote:

On 16.12.2015 15:29, Simo Sorce wrote:
> On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
>> On 15.12.2015 18:22, Simo Sorce wrote:
>>> On Tue, 2015-12-15 at 16:23 +0100, Martin Kosek wrote:
 On 12/15/2015 08:54 AM, Jan Cholasta wrote:
> Hi,
>
> recently I and David discussed the direction of installers with regard to
> requesting certificates. Currently there are four (!) different ways of
> requesting certificates in the installer [1][2][3][4]. We would like to 
reduce
> it to one.
>
> Since all the certificates are tracked by certmonger and certmonger 
already
> knows how to request certificates from Dogtag (and other CAs), we believe 
that
> all certificates should be requested using certmonger.
>
> Taking our meditation further, we thought "Why not use certmonger for the
> cert-request command as well?" What is the benefit, do you ask?
>
>a) single code path for requesting certificates (seriously, the 
current state
> is ridiculous)
>
>b) use any CA supported by certmonger as the IPA CA (i.e. Let's 
Encrypt [5],
> once certmonger gains support for it)
>
>c) automate external CA install, using any CA supported by certmonger 
[6]
>
>d) support multiple different CAs at once (generalization of the 
Sub-CA feature)
>
>e) uniform configuration on clients (configure once, use forever, even 
for
> CA-less)
>
> The idea is to store configuration for the different CAs in LDAP and have
> cert-request redirect requests to a proper CA helper according to that
> configuration. This would require a new certmonger D-Bus method to call a 
CA
> helper without associated certificate storage, but that should be rather 
easy
> to add. In return, it would be possible to do all of the above.
>
> Note that this should not conflict with tighter integration with Dogtag
> (profiles, ACLs, etc.).
>
> Comments are welcome.
>
> Honza
>
> [1]
> 

> [2]
> 

>
> [3]
> 

>
> [4]
> 

>
> [5] 
> [6] 

 Interesting idea! I would be definitely interested to hear what Fraser, 
Rob or
 Simo thinks here.
>>>
>>> Sounds great to me in principle.
>>>
>>> How do you handle CAs that do not have automatic workflows for csr
>>> handling ?
>>>
>>> That's the reason we did the 2 step process (in reference to [6])
>>
>> This could be handled by a dummy "manual" CA helper in certmonger, which
>> would dump the CSR into the filesystem and wait for the user to provide
>> the signed certificate in the filesystem and resume the certmonger request.
>>
>> As you pointed out, we currently do the same, although manually, in
>> external CA install. It is also done when renewing the externally signed
>> CA certificate - this time it is done using certmonger, but it is
>> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
>> helper.
>
> The reason why we did the 2 step process is that it can take days in
> some cases to get back a cert given a csr.
>
> I do not think it is safe to wait for days mid-install.
> At the very least we'll need to be able to stop the install and resume
> it when the certs are available.

I'm not suggesting to wait, we don't wait in ipa-cacert-manage when
renewing the CA certificate either. We can monitor the status of the
certmonger request and interrupt the install when it reaches
NEED_GUIDANCE (which means user intervention is needed).
\

Ok so we'll keep the 2 stages install for this case, fine with me and +1
to reducing parallel paths.

I guess this still wouldn't help automated installs as there are
problems in running certmonger in Anaconda's chroot but it would
probably be unlikely that someone would do automated installs with
two-stage process.
--
/ Alexander Bokovoy

--
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

Re: [Freeipa-devel] [TESTS][PATCH 0008] Fix tests for (stage)user plugin

[Martin Basti]

On 16.12.2015 16:03, Martin Babinsky wrote:

On 12/16/2015 01:51 PM, Lenka Doudova wrote:

Hi,

this patch fixes few Tracker methods for staged and 'normal' user, which
were mistakenly modified by my patch 0006.3. Applies for ipa-4-2 branch
only.

Lenka



ACK.


Pushed to ipa-4-2: d62f023d75a659fa22bfb52de94b70eb084b7ac4

--
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

Re: [Freeipa-devel] [TESTS][PATCH 0008] Fix tests for (stage)user plugin

[Martin Babinsky]

On 12/16/2015 01:51 PM, Lenka Doudova wrote:

Hi,

this patch fixes few Tracker methods for staged and 'normal' user, which
were mistakenly modified by my patch 0006.3. Applies for ipa-4-2 branch
only.

Lenka



ACK.

--
Martin^3 Babinsky

--
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

Re: [Freeipa-devel] certmonger everywhere

[Simo Sorce]

On Wed, 2015-12-16 at 15:41 +0100, Jan Cholasta wrote:
> On 16.12.2015 15:29, Simo Sorce wrote:
> > On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
> >> On 15.12.2015 18:22, Simo Sorce wrote:
> >>> On Tue, 2015-12-15 at 16:23 +0100, Martin Kosek wrote:
>  On 12/15/2015 08:54 AM, Jan Cholasta wrote:
> > Hi,
> >
> > recently I and David discussed the direction of installers with regard 
> > to
> > requesting certificates. Currently there are four (!) different ways of
> > requesting certificates in the installer [1][2][3][4]. We would like to 
> > reduce
> > it to one.
> >
> > Since all the certificates are tracked by certmonger and certmonger 
> > already
> > knows how to request certificates from Dogtag (and other CAs), we 
> > believe that
> > all certificates should be requested using certmonger.
> >
> > Taking our meditation further, we thought "Why not use certmonger for 
> > the
> > cert-request command as well?" What is the benefit, do you ask?
> >
> >a) single code path for requesting certificates (seriously, the 
> > current state
> > is ridiculous)
> >
> >b) use any CA supported by certmonger as the IPA CA (i.e. Let's 
> > Encrypt [5],
> > once certmonger gains support for it)
> >
> >c) automate external CA install, using any CA supported by 
> > certmonger [6]
> >
> >d) support multiple different CAs at once (generalization of the 
> > Sub-CA feature)
> >
> >e) uniform configuration on clients (configure once, use forever, 
> > even for
> > CA-less)
> >
> > The idea is to store configuration for the different CAs in LDAP and 
> > have
> > cert-request redirect requests to a proper CA helper according to that
> > configuration. This would require a new certmonger D-Bus method to call 
> > a CA
> > helper without associated certificate storage, but that should be 
> > rather easy
> > to add. In return, it would be possible to do all of the above.
> >
> > Note that this should not conflict with tighter integration with Dogtag
> > (profiles, ACLs, etc.).
> >
> > Comments are welcome.
> >
> > Honza
> >
> > [1]
> > 
> > [2]
> > 
> >
> > [3]
> > 
> >
> > [4]
> > 
> >
> > [5] 
> > [6] 
> 
>  Interesting idea! I would be definitely interested to hear what Fraser, 
>  Rob or
>  Simo thinks here.
> >>>
> >>> Sounds great to me in principle.
> >>>
> >>> How do you handle CAs that do not have automatic workflows for csr
> >>> handling ?
> >>>
> >>> That's the reason we did the 2 step process (in reference to [6])
> >>
> >> This could be handled by a dummy "manual" CA helper in certmonger, which
> >> would dump the CSR into the filesystem and wait for the user to provide
> >> the signed certificate in the filesystem and resume the certmonger request.
> >>
> >> As you pointed out, we currently do the same, although manually, in
> >> external CA install. It is also done when renewing the externally signed
> >> CA certificate - this time it is done using certmonger, but it is
> >> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
> >> helper.
> >
> > The reason why we did the 2 step process is that it can take days in
> > some cases to get back a cert given a csr.
> >
> > I do not think it is safe to wait for days mid-install.
> > At the very least we'll need to be able to stop the install and resume
> > it when the certs are available.
> 
> I'm not suggesting to wait, we don't wait in ipa-cacert-manage when 
> renewing the CA certificate either. We can monitor the status of the 
> certmonger request and interrupt the install when it reaches 
> NEED_GUIDANCE (which means user intervention is needed).
> \
Ok so we'll keep the 2 stages install for this case, fine with me and +1
to reducing parallel paths.

Simo.



-- 
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

Re: [Freeipa-devel] Fwd: [PUBLIC] Re: [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion

[Martin Babinsky]

On 12/16/2015 03:17 PM, Nikhil Dehadrai wrote:

  Hi There,

Based on the URL for REPLICA PROMOTION Test plan
(http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan), I have
following observations / queries.

Observations:
---
1. For "ipa-kra-install" and "ipa-ca-install" , expected result for step
1 should be FAILED, But it is marked as SUCCEED. (What is the correct
behavior here).

Questions:
--
1. As per current design  (IPA 4.2) we can prepare replica server file
on an existing replica  server using "ipa-replica-prepare" and use this
file to setup new replica host, how can we achieve this behavior under
this new feature when MASTER domain level is set to 1.?


You can't. The whole point of replica installation by promotion is to 
eliminate the need to lug around files to set up new replicas.


In domain level 1 the ipa-replica-prepare command is disabled and 
running it raises an error (See test case 2 in 
http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan). Also there 
is no MASTER domain level, the domain level is uniform across the whole 
topology



2. How will the "ipa topologysegment-add" work for a 3 repilca scenario?
Since, under domain level 1 it uses "rightnode" and "leftnode" to form a
new segment. Can I add 3rd replica to this already created "Newsegment"
or we need to have it created separately? How will it work?

Topology segments describe replication agreements between *two* 
endpoints (think about them as graph edges connecting two nodes). So you 
set up a segment between replica1 and replica2. To connect third replica 
to the topology, you have to create new segment connecting either 
replica1 and replica3, or replica2 and replica3.



We can add New Test Scenarios as well:
-
1. Add scenario for domain level details at UI. Since it talks of
reflecting the domain level changes at UI.
2. Add scenario to validate once domain level of master is raised to 1,
after that it cannot be lowered.
3. Add scenario for "ipa-restore" using master and replica topology , so
as to identify the effect of restoration on replica by using "ipa
topologysegment-find realm" command.( What will be the expected behavior
in this case)

I'm not quite sure about point 3 either. I guess that you have to 
reenroll the replica after restore, but maybe someone more knowledgeable 
about the feature will chime in.


Let me know.

Thanks and Best Regards,
Nikhil Dehadrai





--
Martin^3 Babinsky

--
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

Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

On 16.12.2015 15:29, Simo Sorce wrote:

On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:

On 15.12.2015 18:22, Simo Sorce wrote:

On Tue, 2015-12-15 at 16:23 +0100, Martin Kosek wrote:

On 12/15/2015 08:54 AM, Jan Cholasta wrote:

Hi,

recently I and David discussed the direction of installers with regard to
requesting certificates. Currently there are four (!) different ways of
requesting certificates in the installer [1][2][3][4]. We would like to reduce
it to one.

Since all the certificates are tracked by certmonger and certmonger already
knows how to request certificates from Dogtag (and other CAs), we believe that
all certificates should be requested using certmonger.

Taking our meditation further, we thought "Why not use certmonger for the
cert-request command as well?" What is the benefit, do you ask?

   a) single code path for requesting certificates (seriously, the current state
is ridiculous)

   b) use any CA supported by certmonger as the IPA CA (i.e. Let's Encrypt [5],
once certmonger gains support for it)

   c) automate external CA install, using any CA supported by certmonger [6]

   d) support multiple different CAs at once (generalization of the Sub-CA 
feature)

   e) uniform configuration on clients (configure once, use forever, even for
CA-less)

The idea is to store configuration for the different CAs in LDAP and have
cert-request redirect requests to a proper CA helper according to that
configuration. This would require a new certmonger D-Bus method to call a CA
helper without associated certificate storage, but that should be rather easy
to add. In return, it would be possible to do all of the above.

Note that this should not conflict with tighter integration with Dogtag
(profiles, ACLs, etc.).

Comments are welcome.

Honza

[1]

[2]


[3]


[4]


[5] 
[6] 


Interesting idea! I would be definitely interested to hear what Fraser, Rob or
Simo thinks here.


Sounds great to me in principle.

How do you handle CAs that do not have automatic workflows for csr
handling ?

That's the reason we did the 2 step process (in reference to [6])


This could be handled by a dummy "manual" CA helper in certmonger, which
would dump the CSR into the filesystem and wait for the user to provide
the signed certificate in the filesystem and resume the certmonger request.

As you pointed out, we currently do the same, although manually, in
external CA install. It is also done when renewing the externally signed
CA certificate - this time it is done using certmonger, but it is
handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate
helper.


The reason why we did the 2 step process is that it can take days in
some cases to get back a cert given a csr.

I do not think it is safe to wait for days mid-install.
At the very least we'll need to be able to stop the install and resume
it when the certs are available.


I'm not suggesting to wait, we don't wait in ipa-cacert-manage when 
renewing the CA certificate either. We can monitor the status of the 
certmonger request and interrupt the install when it reaches 
NEED_GUIDANCE (which means user intervention is needed).


--
Jan Cholasta

--
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

Re: [Freeipa-devel] [PATCH 016 - 017] First part of the replica promotion tests + testplan

[Martin Basti]

On 15.12.2015 10:29, Oleg Fayans wrote:

Hi Martin,

The updated patches are attached. Patch 0017 includes all changes from
patch 0018, so, if you approve this one, there would be no need to
continue with the review of 0018. This one contains all changes related
to you remarks from 0018 review. Please see my explanation on the
stdout+stderr part in the thread from patch 0018.
With these two patches applied one of the tests fails due this bug:
https://fedorahosted.org/freeipa/ticket/5550

On 12/09/2015 12:17 PM, Martin Basti wrote:


On 09.12.2015 12:10, Martin Basti wrote:


On 09.12.2015 11:14, Oleg Fayans wrote:

Hi Martin

On 12/09/2015 10:30 AM, Martin Basti wrote:

On 08.12.2015 23:48, Oleg Fayans wrote:

Substituted a hardcoded suffix name with a constant DOMAIN_SUFFIX_NAME

On 12/08/2015 02:33 PM, Oleg Fayans wrote:

Hi all,


The patches are rebased against the current master.

On 12/02/2015 05:10 PM, Martin Basti wrote:

On 02.12.2015 16:18, Oleg Fayans wrote:

Hi Martin,

On 12/01/2015 04:08 PM, Martin Basti wrote:

On 27.11.2015 16:26, Oleg Fayans wrote:

And patch N 16 passes lint too:

On 11/27/2015 04:03 PM, Oleg Fayans wrote:

Hi,

On 11/27/2015 03:26 PM, Martin Basti wrote:

On 27.11.2015 15:04, Oleg Fayans wrote:

Hi Martin,

All your suggestions were taken into account. Both patches are
updated. Thank you for your help!

On 11/26/2015 10:50 AM, Martin Basti wrote:

On 26.11.2015 10:04, Oleg Fayans wrote:

Hi Martin,

I agree to all your points but one. please, see my comment
below

On 11/25/2015 07:42 PM, Martin Basti wrote:

Hi,

0) Note
Please be aware of
https://fedorahosted.org/freeipa/ticket/5469
during
KRA testing

1)
Please do not use MIN and MAX_DOMAIN_LEVEL constants,
this may
change
over time, use DOMAIN_LEVEL_0 and DOMAIN_LEVEL_1 for domain
level 0
and 1

2)
Why uninstall KRA then server, is not enough just uninstall
server
which
covers KRA uninstall?

+def teardown_method(self, method):
+for host in self.replicas:
+ host.run_command(self.kra_uninstall,
raiseonerr=False)
+ tasks.uninstall_master(host)


3)
Can be this function more generic? It should allow specify
host
where
KRA should be installed not just master

+def test_kra_install_master(self):
+ self.master.run_command(self.kra_install)


4)

TestLevel0(Dummy):
Can be the test name more specific, something like
TestReplicaPromotionLevel0


5)
please remove this, the patch is on review and it will be
pushed
sooner
than tests
+@pytest.mark.xfail  # Ticket N 5455

and as I mentioned in ticket #5455, I cannot reproduce
it with
ipa-kra-install, so please provide steps to reproduce if
you
insist
that
this still does not work as expected with KRA.

6) This is completely wrong, it removes everything that we
tried to
achieve with previous patches with domain level in CI

Actually, being able to configure domain level per class
is WAY
more
convenient, than to always have to think which domain
level is
appropriate for which particular test during jenkins job
configuration. In fact, I should have thought about it
from the
very
beginning. For example, in test_replica_promotion.py we
have on
class,
which intiates with domain level = 1, while others - with
domain
level
0. With config-based approach, we would have to implement a
separate
step that raises domain level. Overall, I am against the
approach,
when you have to remember to set certain domain level in
config
for
any particular test. The tests themselves should be aware of
the
domain level they need.

I do not say that we should not have something that overrides
settings
in from config in a particular test case, I say your patch is
doing it
wrong.

I agree it is useful to have param domain_level in
install_master,
and
intall_topo methods,  but is cannot be MAX_DOMAIN_LEVEL by
default,
because with your current patch the domain_level in config is
not
used
at all, it will be always MAX_DOMAIN_LEVEL

For example I want to achieve this goal:
test_vault.py, this test suite can run on domain level1
and on
domain
level0, so with one test we can test 2 domain levels just
with
putting
domain level into config file.

I agree that with extraordinary test like replica
promotion test
is, we
need something that allows override the config file.

As I said bellow, domain_level default value should be
None in
install_master and install_topo plugin. If domain level was
specified
use the specified one, if not (value is None) use the domain
level
from
config file.

Agreed :)


Martin

[PATCH] Enabled setting domain_level per class derived from
TestIntegration

When I configure domain level 0 in yaml config, how is this
supposed to
get into install methods when you removed that code?

-"--domain-level=%i" % host.config.domain_level
+"--domain-level=%i" % domain_level


You always use MAX_DOMAIN_LEVEL in this case or whatever is
specified in
domain_level option.
I suggest to use domain_level=None, and when it is None use
'host.config.domain_level', if it is not N

Re: [Freeipa-devel] [PATCH] ca-less tests updated - POC

[David Kupka]

On 06/11/15 14:04, Oleg Fayans wrote:

Hi Jan,

On 11/06/2015 09:01 AM, Jan Cholasta wrote:

Actually it might be better to keep them, but fix them to expect
ipa-server-certinstall to success.


Done. Updated patch attached.
Also in the patch 0013 I removed a trailing whitespace which caused lint
to complain

Now with domain level 0 the test output looks like this:

[11:40:51]ofayans@vm-076:~]$ ipa-run-tests test_integration/test_caless.py

test session starts
=

platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items

test_integration/test_caless.py
..xx..ss...xxssxx..ss...


= 76
passed, 6 skipped, 6 xfailed in 7871.10 seconds
=




On 6.11.2015 08:47, Jan Cholasta wrote:

Hi Oleg,

I think you can just remove
TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are
imported correctly in this case and I didn't see anything break.

Honza

On 5.11.2015 20:20, Oleg Fayans wrote:

Patch 0014 updated and passes lint

On 11/05/2015 03:41 PM, Oleg Fayans wrote:

Wait a bit, the patch has problems with pylint: it does not build :)
The updated version (without the setupmaster nonsense) is being tested
now.

On 11/05/2015 08:45 AM, Oleg Fayans wrote:

Hi Jan,

Could you take a look at these, whenever you are free?

On 10/30/2015 02:57 PM, Oleg Fayans wrote:

Hi,

The following patches contain updates to ca-less integration tests.
It's still a proof of concept: 2 tests still fail seemingly due to
the
change in target system logic (marked as xfail with "ask jcholast
comment")

The test output looks like this:

$ ipa-run-tests test_integration/test_caless.py --pdb







test session starts
=







platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items

test_integration/test_caless.py
..xx..sssss.ss.xx..ssxx.









53

passed, 29 skipped, 6 xfailed in 5620.17 seconds
=


Numerous skips correspond to the tests related to
ipa-replica-prepare
(unsupported under domain level 1)





















This body part will be downloaded on demand.

Hello, thanks for updated patches. I'm really sorry it took so long 
before I got to them.
There was change in ipapython.ipautil.run that happened after you sent 
the patches. Feel free to squash attached patch that fixes it.


Unfortunately I see a lot of test failing with domain-level 0: 
http://fpaste.org/301657/50275682/


domain-level 1 (domain-level 1: http://fpaste.org/301658/02757191/) 
seems better. There are 2 failing test that you're probably mentioning 
in commit message plus one that I think is bug in code rather than bug 
in tests.

Do you have any proposal for fixing the two failing tests?

One nitpick: Please use mail for notes like "need further consulting 
..." rather that commit message. When the patch gets accepted it will 
still need modification before push just because inappropriate commit 
message.


Thank you!
--
David Kupka
From 2a6e8f02ecd00da2b86d2f3f9847a86caa35e74d Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Wed, 16 Dec 2015 09:12:56 +0100
Subject: [PATCH] Addapt CA less test to new ipapython.ipautil.run

---
 ipatests/test_integration/test_caless.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ipatests/test_integration/test_caless.py b/ipatests/test_integration/test_caless.py
index 4b88ee9da1d5a476f13604f9a833e748a093..6cb55a708517062edb1bb950a72d6a66f717432e 100644
--- a/ipatests/test_integration/test_caless.py
+++ b/ipatests/test_integration/test_caless.py
@@ -300,10 +300,10 @@ class CALessBase(IntegrationTest):
 
 @classmethod
 def get_pem(cls, nickname):
-pem_cert, _stderr, _returncode = ipautil.run(
+result = ipautil.run(
 ['certutil', '-L', '-d', 'nssdb', '-n', nickname, '-a'],
-cwd=cls.cert_dir)
-return pem_cert
+cwd=cls.cert_dir, capture_output=True)
+return result.output
 
 def verify_installation(self):
 """Verify CA cert PEM file and LDAP entry created by install
-- 
2.5.0

-- 
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

Re: [Freeipa-devel] [PATCH 535] ipautil: remove unused import causing cyclic import in tests

[Oleg Fayans]

ACK, the issue is gone

On 12/15/2015 03:39 PM, Jan Cholasta wrote:
> Hi,
> 
> the attached patch fixes .
> 
> Pushed to under the one-liner rule:
> master: c265e8736e51d5b4fede94a414d83b3e0ada2853
> ipa-4-3: 2b28704f926d24e1562b481880b111d12d2020f2
> 
> Honza
> 
> 
> 

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
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

Re: [Freeipa-devel] certmonger everywhere

[Simo Sorce]

On Wed, 2015-12-16 at 07:17 +0100, Jan Cholasta wrote:
> On 15.12.2015 18:22, Simo Sorce wrote:
> > On Tue, 2015-12-15 at 16:23 +0100, Martin Kosek wrote:
> >> On 12/15/2015 08:54 AM, Jan Cholasta wrote:
> >>> Hi,
> >>>
> >>> recently I and David discussed the direction of installers with regard to
> >>> requesting certificates. Currently there are four (!) different ways of
> >>> requesting certificates in the installer [1][2][3][4]. We would like to 
> >>> reduce
> >>> it to one.
> >>>
> >>> Since all the certificates are tracked by certmonger and certmonger 
> >>> already
> >>> knows how to request certificates from Dogtag (and other CAs), we believe 
> >>> that
> >>> all certificates should be requested using certmonger.
> >>>
> >>> Taking our meditation further, we thought "Why not use certmonger for the
> >>> cert-request command as well?" What is the benefit, do you ask?
> >>>
> >>>   a) single code path for requesting certificates (seriously, the current 
> >>> state
> >>> is ridiculous)
> >>>
> >>>   b) use any CA supported by certmonger as the IPA CA (i.e. Let's Encrypt 
> >>> [5],
> >>> once certmonger gains support for it)
> >>>
> >>>   c) automate external CA install, using any CA supported by certmonger 
> >>> [6]
> >>>
> >>>   d) support multiple different CAs at once (generalization of the Sub-CA 
> >>> feature)
> >>>
> >>>   e) uniform configuration on clients (configure once, use forever, even 
> >>> for
> >>> CA-less)
> >>>
> >>> The idea is to store configuration for the different CAs in LDAP and have
> >>> cert-request redirect requests to a proper CA helper according to that
> >>> configuration. This would require a new certmonger D-Bus method to call a 
> >>> CA
> >>> helper without associated certificate storage, but that should be rather 
> >>> easy
> >>> to add. In return, it would be possible to do all of the above.
> >>>
> >>> Note that this should not conflict with tighter integration with Dogtag
> >>> (profiles, ACLs, etc.).
> >>>
> >>> Comments are welcome.
> >>>
> >>> Honza
> >>>
> >>> [1]
> >>> 
> >>> [2]
> >>> 
> >>>
> >>> [3]
> >>> 
> >>>
> >>> [4]
> >>> 
> >>>
> >>> [5] 
> >>> [6] 
> >>
> >> Interesting idea! I would be definitely interested to hear what Fraser, 
> >> Rob or
> >> Simo thinks here.
> >
> > Sounds great to me in principle.
> >
> > How do you handle CAs that do not have automatic workflows for csr
> > handling ?
> >
> > That's the reason we did the 2 step process (in reference to [6])
> 
> This could be handled by a dummy "manual" CA helper in certmonger, which 
> would dump the CSR into the filesystem and wait for the user to provide 
> the signed certificate in the filesystem and resume the certmonger request.
> 
> As you pointed out, we currently do the same, although manually, in 
> external CA install. It is also done when renewing the externally signed 
> CA certificate - this time it is done using certmonger, but it is 
> handled by the dogtag-ipa-ca-renewal-agent helper rather than a separate 
> helper.

The reason why we did the 2 step process is that it can take days in
some cases to get back a cert given a csr.

I do not think it is safe to wait for days mid-install.
At the very least we'll need to be able to stop the install and resume
it when the certs are available.

Simo.



-- 
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

Re: [Freeipa-devel] [PATCH 0071] dns: Handle SERVFAIL in check if domain already exists

[Petr Vobornik]

On 12/16/2015 03:18 PM, David Kupka wrote:

On 16/12/15 14:23, Petr Spacek wrote:

Hello,

dns: Handle SERVFAIL in check if domain already exists.

In cases where domain is already delegated to IPA prior installation
we might get timeout or SERVFAIL. The answer depends on the recursive
server we are using for the check.




Works for me, ACK.



Pushed to:
master: 58331208a5ded367e521d42d99de2835f329fab7
ipa-4-3: d35067515e20de764e58d3ad8e343b3e2282a780
--
Petr Vobornik

--
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

Re: [Freeipa-devel] [PATCH 0071] dns: Handle SERVFAIL in check if domain already exists

[David Kupka]

On 16/12/15 14:23, Petr Spacek wrote:

Hello,

dns: Handle SERVFAIL in check if domain already exists.

In cases where domain is already delegated to IPA prior installation
we might get timeout or SERVFAIL. The answer depends on the recursive
server we are using for the check.




Works for me, ACK.

--
David Kupka

--
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

Re: [Freeipa-devel] Fwd: [PUBLIC] Re: [IPAQE][REVIEW-REQUEST][TEST PLAN] Replica promotion

[Nikhil Dehadrai]

 Hi There,

Based on the URL for REPLICA PROMOTION Test plan 
(http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan), I have 
following observations / queries.


Observations:
---
1. For "ipa-kra-install" and "ipa-ca-install" , expected result for step 
1 should be FAILED, But it is marked as SUCCEED. (What is the correct 
behavior here).


Questions:
--
1. As per current design  (IPA 4.2) we can prepare replica server file 
on an existing replica  server using "ipa-replica-prepare" and use this 
file to setup new replica host, how can we achieve this behavior under 
this new feature when MASTER domain level is set to 1.?
2. How will the "ipa topologysegment-add" work for a 3 repilca scenario? 
Since, under domain level 1 it uses "rightnode" and "leftnode" to form a 
new segment. Can I add 3rd replica to this already created "Newsegment" 
or we need to have it created separately? How will it work?


We can add New Test Scenarios as well:
-
1. Add scenario for domain level details at UI. Since it talks of 
reflecting the domain level changes at UI.
2. Add scenario to validate once domain level of master is raised to 1, 
after that it cannot be lowered.
3. Add scenario for "ipa-restore" using master and replica topology , so 
as to identify the effect of restoration on replica by using "ipa 
topologysegment-find realm" command.( What will be the expected behavior 
in this case)



Let me know.

Thanks and Best Regards,
Nikhil Dehadrai


--
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 0075-0076] Fix installer regression

[David Kupka]

https://www.redhat.com/archives/freeipa-users/2015-December/msg00203.html
--
David Kupka
From 114b4e2c1ffaa5c09dbfed54bb1f90cfa41f4678 Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Wed, 16 Dec 2015 12:43:13 +
Subject: [PATCH 1/2] installer: Propagate option values from components
 instead of copying them.

---
 ipapython/install/core.py  |  7 +++
 ipaserver/install/server/common.py | 28 
 2 files changed, 7 insertions(+), 28 deletions(-)

diff --git a/ipapython/install/core.py b/ipapython/install/core.py
index 6b2da05..62756da 100644
--- a/ipapython/install/core.py
+++ b/ipapython/install/core.py
@@ -528,6 +528,13 @@ class Composite(Configurable):
 for order, owner_cls, name in result:
 yield owner_cls, name
 
+def __getattr__(self, name):
+for owner_cls, knob_name in self.knobs():
+for component in self.__components:
+if isinstance(component, owner_cls):
+return getattr(component, knob_name)
+raise AttributeError(name)
+
 def _reset(self):
 self.__components = list(self._get_components())
 
diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 3eb7279..948aac8 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -409,34 +409,6 @@ class BaseServer(common.Installable, common.Interactive, core.Composite):
 # Automatically disable pkinit w/ dogtag until that is supported
 self.no_pkinit = True
 
-self.external_ca = self.ca.external_ca
-self.external_ca_type = self.ca.external_ca_type
-self.external_cert_files = self.ca.external_cert_files
-self.dirsrv_cert_files = self.ca.dirsrv_cert_files
-self.http_cert_files = self.ca.http_cert_files
-self.pkinit_cert_files = self.ca.pkinit_cert_files
-self.dirsrv_pin = self.ca.dirsrv_pin
-self.http_pin = self.ca.http_pin
-self.pkinit_pin = self.ca.pkinit_pin
-self.dirsrv_cert_name = self.ca.dirsrv_cert_name
-self.http_cert_name = self.ca.http_cert_name
-self.pkinit_cert_name = self.ca.pkinit_cert_name
-self.ca_cert_files = self.ca.ca_cert_files
-self.subject = self.ca.subject
-self.ca_signing_algorithm = self.ca.ca_signing_algorithm
-self.skip_schema_check = self.ca.skip_schema_check
-
-self.forwarders = self.dns.forwarders
-self.no_forwarders = self.dns.no_forwarders
-self.reverse_zones = self.dns.reverse_zones
-self.no_reverse = self.dns.no_reverse
-self.no_dnssec_validation = self.dns.no_dnssec_validation
-self.dnssec_master = self.dns.dnssec_master
-self.disable_dnssec_master = self.dns.disable_dnssec_master
-self.kasp_db_file = self.dns.kasp_db_file
-self.force = self.dns.force
-self.zonemgr = self.dns.zonemgr
-
 self.unattended = not self.interactive
 
 ca = core.Component(BaseServerCA)
-- 
2.5.0

From b726b613d0f5afcbe7665368b9aaba336d6e2974 Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Wed, 16 Dec 2015 12:43:13 +
Subject: [PATCH 1/2] installer: Propagate option values from components
 instead of copying them.

---
 ipapython/install/core.py  |  7 +++
 ipaserver/install/server/common.py | 31 ---
 2 files changed, 7 insertions(+), 31 deletions(-)

diff --git a/ipapython/install/core.py b/ipapython/install/core.py
index 2f62b85..3eb38d3 100644
--- a/ipapython/install/core.py
+++ b/ipapython/install/core.py
@@ -531,6 +531,13 @@ class Composite(Configurable):
 for order, owner_cls, name in result:
 yield owner_cls, name
 
+def __getattr__(self, name):
+for owner_cls, knob_name in self.knobs():
+for component in self.__components:
+if isinstance(component, owner_cls):
+return getattr(component, knob_name)
+raise AttributeError(name)
+
 def _reset(self):
 self.__components = list(self._get_components())
 
diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 19a1cc8..00b05c9 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -461,37 +461,6 @@ class BaseServer(common.Installable, common.Interactive, core.Composite):
 # Automatically disable pkinit w/ dogtag until that is supported
 self.no_pkinit = True
 
-self.external_ca = self.ca.external_ca
-self.external_ca_type = self.ca.external_ca_type
-self.external_cert_files = self.ca.external_cert_files
-self.dirsrv_cert_files = self.ca.dirsrv_cert_files
-self.http_cert_files = self.ca.http_cert_files
-self.pkinit_cert_files = self.ca.pkinit_cert_files
-self.dirsrv_pin = self.ca.dirsrv_pin
-self.http_pin = self.ca.http_pin
-self.pkinit_pin = self.ca.p

[Freeipa-devel] [PATCH 0071] dns: Handle SERVFAIL in check if domain already exists

[Petr Spacek]

Hello,

dns: Handle SERVFAIL in check if domain already exists.

In cases where domain is already delegated to IPA prior installation
we might get timeout or SERVFAIL. The answer depends on the recursive
server we are using for the check.

-- 
Petr^2 Spacek
From 37741a8ed01ada5059791f38c52ed2159396c0cc Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Wed, 16 Dec 2015 13:37:39 +0100
Subject: [PATCH] dns: Handle SERVFAIL in check if domain already exists.

In cases where domain is already delegated to IPA prior installation
we might get timeout or SERVFAIL. The answer depends on the recursive
server we are using for the check.
---
 ipapython/ipautil.py  | 11 +--
 ipaserver/install/bindinstance.py |  2 +-
 ipaserver/install/dns.py  |  6 --
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index 47879c4afa17e119bd4fa32c9a297b993113..bd1cf78fac79c7816db4b96f46c9c5c1b4b2f1d9 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -41,7 +41,7 @@ import locale
 import collections
 
 from dns import resolver, rdatatype, reversename
-from dns.exception import DNSException, Timeout
+from dns.exception import DNSException
 import six
 from six.moves import input
 from six.moves import urllib
@@ -1046,7 +1046,7 @@ def reverse_record_exists(ip_address):
 return True
 
 
-def check_zone_overlap(zone, raise_on_timeout=True):
+def check_zone_overlap(zone, raise_on_error=True):
 root_logger.info("Checking DNS domain %s, please wait ..." % zone)
 if not isinstance(zone, DNSName):
 zone = DNSName(zone).make_absolute()
@@ -1058,10 +1058,9 @@ def check_zone_overlap(zone, raise_on_timeout=True):
 
 try:
 containing_zone = resolver.zone_for_name(zone)
-except Timeout as e:
-msg = ("DNS check for domain %s failed: %s. Please make sure that the "
-   "domain is properly delegated to this IPA server." % (zone, e))
-if raise_on_timeout:
+except DNSException as e:
+msg = ("DNS check for domain %s failed: %s." % (zone, e))
+if raise_on_error:
 raise ValueError(msg)
 else:
 root_logger.warning(msg)
diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index 93744875ef895e93aff5fdf7b55fdadcc6c6d227..8daca552d58f4c1ce795d4a0be352fc9f9c51762 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -291,7 +291,7 @@ def read_reverse_zone(default, ip_address, allow_zone_overlap=False):
 continue
 if not allow_zone_overlap:
 try:
-ipautil.check_zone_overlap(zone, raise_on_timeout=False)
+ipautil.check_zone_overlap(zone, raise_on_error=False)
 except ValueError as e:
 root_logger.error("Reverse zone %s will not be used: %s"
   % (zone, e))
diff --git a/ipaserver/install/dns.py b/ipaserver/install/dns.py
index 94e9017b6f33ef28bc8cb88aee79ce39462f11a7..763b2aca475d5f5b25d2aded05bc540ce3836f81 100644
--- a/ipaserver/install/dns.py
+++ b/ipaserver/install/dns.py
@@ -126,10 +126,12 @@ def install_check(standalone, replica, options, hostname):
 domain = dnsutil.DNSName(util.normalize_zone(api.env.domain))
 print("Checking DNS domain %s, please wait ..." % domain)
 try:
-ipautil.check_zone_overlap(domain, raise_on_timeout=False)
+ipautil.check_zone_overlap(domain, raise_on_error=False)
 except ValueError as e:
 if options.force or options.allow_zone_overlap:
-root_logger.warning(e.message)
+root_logger.warning("%s Please make sure that the domain is "
+"properly delegated to this IPA server.",
+e.message)
 else:
 raise e
 
-- 
2.5.0

-- 
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] [TESTS][PATCH 0008] Fix tests for (stage)user plugin

[Lenka Doudova]

Hi,

this patch fixes few Tracker methods for staged and 'normal' user, which 
were mistakenly modified by my patch 0006.3. Applies for ipa-4-2 branch 
only.


Lenka
From f632687a338bd17f1b143fa72e040f4111510998 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Wed, 16 Dec 2015 13:44:28 +0100
Subject: [PATCH] Tests: Fix tests for (stage)user plugin

Fixes tests for (stage)user plugin that were mistakenly modified in commit 75675f (patch 0006.3 by ldoudova).
---
 ipatests/test_xmlrpc/test_stageuser_plugin.py | 2 +-
 ipatests/test_xmlrpc/test_user_plugin.py  | 4 
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_stageuser_plugin.py b/ipatests/test_xmlrpc/test_stageuser_plugin.py
index ed5fc8b72a944e89a35e1960fee54852955d1a58..efbbab7e68f2ab1c6bd7a3182898aa13c46fad37 100644
--- a/ipatests/test_xmlrpc/test_stageuser_plugin.py
+++ b/ipatests/test_xmlrpc/test_stageuser_plugin.py
@@ -186,7 +186,7 @@ class StageUserTracker(Tracker):
 (self.kwargs[key].split('@'))[0].lower(),
 (self.kwargs[key].split('@'))[1])]
 elif key == u'manager':
-self.attrs[key] = [self.kwargs[key]]
+self.attrs[key] = [get_user_dn(self.kwargs[key])]
 elif key == u'ipasshpubkey':
 self.attrs[u'sshpubkeyfp'] = [sshpubkeyfp]
 self.attrs[key] = [self.kwargs[key]]
diff --git a/ipatests/test_xmlrpc/test_user_plugin.py b/ipatests/test_xmlrpc/test_user_plugin.py
index cce769f8f31fc05df218fd4f5afa8978bce091be..81185e449acaa127aa9429fff9587d39a2be81e6 100644
--- a/ipatests/test_xmlrpc/test_user_plugin.py
+++ b/ipatests/test_xmlrpc/test_user_plugin.py
@@ -1903,10 +1903,6 @@ class UserTracker(Tracker):
 summary=u'Stage user %s activated' % self.uid,
 result=self.filter_attrs(self.activate_keys))
 
-if 'manager' in expected['result']:
-expected['result']['manager'] = [
-unicode(get_user_dn(expected['result']['manager'][0]))]
-
 # work around to eliminate inconsistency in returned objectclass
 # (case sensitive assertion)
 expected['result']['objectclass'] = [item.lower() for item in
-- 
2.4.3

-- 
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

Re: [Freeipa-devel] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3

[Petr Viktorin]

On 12/07/2015 04:22 PM, Jan Cholasta wrote:
> On 2.12.2015 13:38, Petr Viktorin wrote:
>> On 12/01/2015 02:37 PM, Jan Cholasta wrote:
[...]
>>
>> As for new provides, Fedora's Python packaging guidelines say:
>>
>> """
>> Using a fictional module named "example", the subpackage containing
>> the python2 version must provide python2-example. This is of course
>> always the case if the subpackage is named python2-example [...]
>> If the subpackage has some other name then then Provides:
>> python2-example
>> must be added explicitly (but see the %python_provide macro below).
>>
>> The python3 subpackage must provide python3-example. However, as the
>> naming guidelines mandate that the python3 subpackage be named
>> python3-example, this will happen automatically.
>> """
>>
>> so I'm now adding Provides for the top-level modules.
>
> The goal of this work is to add support for Python 3, not to comply
> with
> Fedora packaging guidelines. FreeIPA on Fedora uses its own spec file
> anyway.

 The goal of this patch is to add new packages that support Python 3.
 Yes, the Fedora spec is different, but it's heavily based on the
 upstream one, and this is a good thing. I consider the Fedora
 guidelines
 the standard in Python RPM packaging. If IPA uses different packaging
 guidelines, can you point me to them?
>>>
>>> FreeIPA never fully complied to Fedora packaging guidelines AFAIK and I
>>> don't see any reason to start now, since nobody seemed to care so far.
>>> Following them in just py3 sub-packages does not improve the state of
>>> FreeIPA as a whole and only brings inconsistency into it, so there's no
>>> benefit in doing it at all.
>>>
> Again, if you insist on doing this, do it for Python 2 as well.
>>
>> OK, when your patches are ACKed I'll send patches to both improve py2
>> packaging and add the new packages.

Here is the patch rebased onto current master, which includes your
packaging improvements.


-- 
Petr Viktorin
From 0e577e143a77c54e0c7bd8a6c6c154e36d0a218d Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Tue, 3 Nov 2015 16:39:40 +0100
Subject: [PATCH] Package ipapython, ipalib, ipaplatform, ipatests for Python 3

Running make with PYTHON=/usr/bin/python3 will build/install the
bits for Python 3.

Executable scripts in ipatests have symlinks Python version suffixes
as per Fedora guidelines. Suffix-less names point to the Python 2 versions.
---
 .gitignore |   3 +
 Makefile   |   8 +-
 freeipa.spec.in| 154 +
 ipalib/Makefile|  25 ++
 ipalib/cli.py  |   1 +
 ipalib/setup.py.in |  73 
 ipapython/Makefile |  18 ++--
 ipapython/ipap11helper/Makefile|  11 ++-
 ipapython/py_default_encoding/Makefile |  21 +++--
 setup.py   |   2 -
 10 files changed, 284 insertions(+), 32 deletions(-)
 create mode 100644 ipalib/Makefile
 create mode 100644 ipalib/setup.py.in

diff --git a/.gitignore b/.gitignore
index 13f9eb34a4528fc22af59a3b364057f642109153..06b017df2c12a920fd81de6640ca787b0a4ddd87 100644
--- a/.gitignore
+++ b/.gitignore
@@ -67,6 +67,9 @@ freeipa2-dev-doc
 
 /ipatests/setup.py
 
+/ipalib/setup.py
+!/ipalib/Makefile
+
 /ipapython/setup.py
 /ipapython/version.py
 !/ipapython/Makefile
diff --git a/Makefile b/Makefile
index ab2524db11eb7eaf69a2d4f0f5365c9d541c0694..7b9f95a1d06fdd73f7c1c9f1edb7fb694aaf8579 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,7 @@
 
 include VERSION
 
-SUBDIRS=asn1 daemons install ipapython ipa-client
+SUBDIRS=asn1 daemons install ipapython ipalib ipa-client
 CLIENTDIRS=ipapython ipa-client asn1
 
 PRJ_PREFIX=freeipa
@@ -143,6 +143,8 @@ version-update: release-update
 		> ipapython/setup.py
 	sed -e s/__VERSION__/$(IPA_VERSION)/ ipaplatform/setup.py.in \
 		> ipaplatform/setup.py
+	sed -e s/__VERSION__/$(IPA_VERSION)/ ipalib/setup.py.in \
+		> ipalib/setup.py
 	sed -e s/__VERSION__/$(IPA_VERSION)/ ipapython/version.py.in \
 		> ipapython/version.py
 	sed -e s/__VERSION__/$(IPA_VERSION)/ ipatests/setup.py.in \
@@ -240,7 +242,7 @@ rpms: rpmroot rpmdistdir version-update lint tarballs
 	cp dist/sources/$(TARBALL) $(RPMBUILD)/SOURCES/.
 	rpmbuild --define "_topdir $(RPMBUILD)" -ba freeipa.spec
 	cp $(RPMBUILD)/RPMS/*/$(PRJ_PREFIX)-*-$(IPA_VERSION)-*.rpm dist/rpms/
-	cp $(RPMBUILD)/RPMS/*/python2-ipa*-$(IPA_VERSION)-*.rpm dist/rpms/
+	cp $(RPMBUILD)/RPMS/*/python?-ipa*-$(IPA_VERSION)-*.rpm dist/rpms/
 	cp $(RPMBUILD)/SRPMS/$(PRJ_PREFIX)-$(IPA_VERSION)-*.src.rpm dist/srpms/
 	rm -rf $(RPMBUILD)
 
@@ -248,7 +250,7 @@ client-rpms: rpmroot rpmdistdir version-update lint tarballs
 	cp dist/sources/$(TARBALL) $(RPMBUILD)/SOURCES/.
 	rpmbuild --define "_topdir $(RPMBUILD)" --define "ONLY_CLIENT 1" -ba freeipa.spec
 	cp

Re: [Freeipa-devel] certmonger everywhere

[Fraser Tweedale]

On Wed, Dec 16, 2015 at 11:11:42AM +0100, Martin Kosek wrote:
> On 12/16/2015 09:17 AM, Jan Cholasta wrote:
> > On 16.12.2015 08:54, Martin Kosek wrote:
> ...
> >>>   7. cert-request fetches the configuration for the specified sub-CA,
> >>> or the
> >>> default sub-CA if none was specified, from LDAP
> >>>
> >>>   8. cert-request forwards the request to the certmonger CA helper
> >>> specified in
> >>> the LDAP configuration over D-Bus (this is the D-Bus method that
> >>> currently does
> >>> not exist and needs to be implemented)
> >>>
> >>>   9. certmonger executes the specified CA helper to handle the request
> >>>
> >>>   10. the CA helper requests the certificate from the CA and returns
> >>> either the
> >>> certificate, wait delay or error
> >>>
> >>>   11. certmonger returns the result back to cert-request
> >>
> >> These steps are subject to Fraser's question (and I am curious too), i.e.:
> >>
> >> - how is authentication done? certmonger runs with FreeIPA server host
> >> principal.
> > 
> > We are on the server, so the RA agent cert is used to authenticate to 
> > Dogtag as
> > usual, and whatever authentication is configured for other CAs is used for
> > other CAs.
> 
> Right, this is how it works now. However, in FreeIPA 4.4 or later, we plan to
> switch GSSAPI authentication with Dogtag to get better authorization 
> capabilities:
> 
> https://fedorahosted.org/freeipa/ticket/5011
> 
> But maybe this could be done via S4U2Proxy as Fraser suggested, although in
> this case it would be more complicated as certmonger itself does not have
> access to user HTTP/ipa.server ticket, like Apache does, given that Apache
> would contact certmonger via DBUS.
> 
If I am not mistaken, Certmonger already uses host credentials, so
IPA framework can S4U2Proxy to get user ticket for Certmonger, then
Certmonger can S4U2Proxy to get user ticket for Dogtag.

Big +1 to the fact that we are pushing away from RA cert to GSS-API
for authenticating to Dogtag.

> > 
> >> - how will we handle 3-step certificate request, i.e.:
> >>- certificate is requested and in moderation/wait queue
> >>- request have to be acked by Dogtag administrator (we do not have
> >> API yet)
> >>- client should be able to ask for generated certificate
> > 
> > This is not really related to my proposal, since we have to figure this out 
> > for
> > our Dogtag IPA CA anyway, but the CA helper can return a wait delay in this
> > case, so certmonger can poll the request until it is approved.
> 
> Ok.
> 
> >>>   12. cert-request returns the result back to IPA CA helper on the client
> >>>
> >>>   13. the IPA CA helper on the client returns the result back to
> >>> certmonger
> >>>
> >>>   14. if the result was wait delay, certmonger waits and then retries the
> >>> request from step 4, otherwise it stores the certificate or sets error
> >>> status
> >>>
> >>
> >> Right, 12-14 is again the standard flow. Good summary of the steps!
> > 
> > 
> 

-- 
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

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Martin Kosek]

On 12/16/2015 12:01 PM, Petr Spacek wrote:
> On 16.12.2015 11:15, Martin Kosek wrote:
>> On 12/16/2015 10:02 AM, Petr Spacek wrote:
>>> On 16.12.2015 09:53, Jan Cholasta wrote:
 On 16.12.2015 09:45, Petr Spacek wrote:
> On 11.12.2015 15:50, Jan Cholasta wrote:
>> Hi,
>>
>> On 10.12.2015 18:04, Petr Spacek wrote:
>>> On 9.12.2015 15:30, Petr Spacek wrote:
 Hello,

 this patch automates some of sanity checks proposed by Petr Vobornik.

 'make review' should be used in root of clean Git tree which has 
 patches
 under
 review applied.

 Magic in review.sh attempts to detect nearest remote branch which can 
 be
 used
 as diff base for review. Please see review.sh for further details.
>>>
>>> And here is the patch! :-)
>>
>> Nice, but I would rather see this in ipatool
>> (). Or is there any obvious 
>> benefit
>> in having this in freeipa itself that I'm missing?
>
> For me the obvious benefit is:
> git clone
> git am
> make review
>
> Done.
>
> No need to find & learn other tool, no risk of using wrong version of the 
> tool
> to wrong version of source tree etc.

 AFAIK all IPA developers are supposed to use ipatool, and it already has a
>>>
>>> Good to know. How does a newcomer learn about it? Honestly I never used
>>> ipatool (or not even cloned it).
>>
>> ipatool targets rather upstream members with write access, so they are hardly
>> newcomers.
> 
> I though that we want to make it easy to contribute, so why are you talking
> about core developers?

I was mostly refering to ipatool's "push" command that I mostly used, but it's
true there is also "start-review" or "am" commands that could be useful to
others too.

> Shouldn't we make it easy to self-review own patches for everyone? Including
> random people who want to submit few patches and go away? (Think how we can
> apply usability principles to development.)

We should, I hope my reply did not suggest otherwise.

Martin

-- 
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

Re: [Freeipa-devel] certmonger everywhere

[Fraser Tweedale]

On Wed, Dec 16, 2015 at 09:17:09AM +0100, Jan Cholasta wrote:
> On 16.12.2015 08:54, Martin Kosek wrote:
> >On 12/16/2015 08:09 AM, Jan Cholasta wrote:
> >>On 16.12.2015 01:40, Fraser Tweedale wrote:
> >>>On Tue, Dec 15, 2015 at 04:23:33PM +0100, Martin Kosek wrote:
> On 12/15/2015 08:54 AM, Jan Cholasta wrote:
> >Hi,
> >
> >recently I and David discussed the direction of installers with
> >regard to
> >requesting certificates. Currently there are four (!) different
> >ways of
> >requesting certificates in the installer [1][2][3][4]. We would
> >like to reduce
> >it to one.
> >
> >Since all the certificates are tracked by certmonger and certmonger
> >already
> >knows how to request certificates from Dogtag (and other CAs), we
> >believe that
> >all certificates should be requested using certmonger.
> >
> >Taking our meditation further, we thought "Why not use certmonger
> >for the
> >cert-request command as well?" What is the benefit, do you ask?
> >
> >  a) single code path for requesting certificates (seriously, the
> >current
> >state
> >is ridiculous)
> >
> >  b) use any CA supported by certmonger as the IPA CA (i.e. Let's
> >Encrypt [5],
> >once certmonger gains support for it)
> >
> >  c) automate external CA install, using any CA supported by
> >certmonger [6]
> >
> >  d) support multiple different CAs at once (generalization of the
> >Sub-CA
> >feature)
> >
> >  e) uniform configuration on clients (configure once, use forever,
> >even for
> >CA-less)
> >
> >The idea is to store configuration for the different CAs in LDAP
> >and have
> >cert-request redirect requests to a proper CA helper according to that
> >configuration. This would require a new certmonger D-Bus method to
> >call a CA
> >helper without associated certificate storage, but that should be
> >rather easy
> >to add. In return, it would be possible to do all of the above.
> >
> >Note that this should not conflict with tighter integration with
> >Dogtag
> >(profiles, ACLs, etc.).
> >
> >Comments are welcome.
> >
> >Honza
> >
> >[1]
> >
> >
> >
> >[2]
> >
> >
> >
> >
> >[3]
> >
> >
> >
> >
> >[4]
> >
> >
> >
> >
> >[5] 
> >[6] 
> 
> Interesting idea! I would be definitely interested to hear what
> Fraser, Rob or
> Simo thinks here.
> 
> >>>For the installer cases, +1 from me.
> >>>
> >>>For the general cert-request case, currently Certmonger calls `ipa
> >>>cert-request' using host credentials (Kerberos), and IPA framework
> >>>does some validation (e.g. ensure CN and altNames correspond to
> >>>subject principal), before requesting cert from Dogtag using RA
> >>>Agent credentials (TLS client cert).
> >>>
> >>>There are a few things that have to happen before Certmonger can
> >>>request certs directly from Dogtag, in IPA scenario:
> >>>
> >>>1. support SNPEGO authentication in Dogtag (work has started)
> >>>
> >>>2. perform all validation that IPA framework currently performs in
> >>>Dogtag, or make the validation no longer required by pulling cert
> >>>data straight from LDAP according to the profile.
> >>>
> >>>3. Requestor credentials must be delegated to Certmonger so that the
> >>>correct principal is used to talk to Dogtag.  Presumably this would
> >>>be S4U2Proxy constrained delegation with host/ as
> >>>impersonator and Dogtag service principal as target.
> >>>
> >>>At that point `ipa cert-request' can become a client-side command
> >>>that merely configures Certmonger to request the cert.
> >>
> >>I'm not proposing to change cert-request to a client side command - I'm
> >>proposing to change the way cert-request is handled *on the server*.
> >
> >I do not think Fraser was suggesting to change cert-request to a client
> >side command. More below.
> 
> See 3 paragraphs above: "... `ipa cert-request' can become a client-side
> command...".
> 
Indeed; my commentary was based on misunderstanding that Jan was
proposing Certmonger on would talk to Dogtag.  Thanks for
clarifying, Jan.

> >
> >>This way
> >>we can keep all the configuration on the server and make changes to it
> >>without
> >>having to reconfigure all clients.
> >>
> >>This is how I envision the workflow:
> >>
> >>  1. client requests a certificate with "getcert request", using "IPA"
> >>as the
> >>C

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Petr Spacek]

On 16.12.2015 11:15, Martin Kosek wrote:
> On 12/16/2015 10:02 AM, Petr Spacek wrote:
>> On 16.12.2015 09:53, Jan Cholasta wrote:
>>> On 16.12.2015 09:45, Petr Spacek wrote:
 On 11.12.2015 15:50, Jan Cholasta wrote:
> Hi,
>
> On 10.12.2015 18:04, Petr Spacek wrote:
>> On 9.12.2015 15:30, Petr Spacek wrote:
>>> Hello,
>>>
>>> this patch automates some of sanity checks proposed by Petr Vobornik.
>>>
>>> 'make review' should be used in root of clean Git tree which has patches
>>> under
>>> review applied.
>>>
>>> Magic in review.sh attempts to detect nearest remote branch which can be
>>> used
>>> as diff base for review. Please see review.sh for further details.
>>
>> And here is the patch! :-)
>
> Nice, but I would rather see this in ipatool
> (). Or is there any obvious 
> benefit
> in having this in freeipa itself that I'm missing?

 For me the obvious benefit is:
 git clone
 git am
 make review

 Done.

 No need to find & learn other tool, no risk of using wrong version of the 
 tool
 to wrong version of source tree etc.
>>>
>>> AFAIK all IPA developers are supposed to use ipatool, and it already has a
>>
>> Good to know. How does a newcomer learn about it? Honestly I never used
>> ipatool (or not even cloned it).
> 
> ipatool targets rather upstream members with write access, so they are hardly
> newcomers.

I though that we want to make it easy to contribute, so why are you talking
about core developers?

Shouldn't we make it easy to self-review own patches for everyone? Including
random people who want to submit few patches and go away? (Think how we can
apply usability principles to development.)

Petr^2 Spacek

> But still, here you go:
> https://www.freeipa.org/page/Contribute/Repository#Process_tools
> 
>>> start-review command, so it would better fit in there. Or we could merge
>>> freeipa-tools into freeipa. My point is that I don't think having half of 
>>> the
>>> stuff in ipatool and the other half in IPA itself is a good thing to do.
>>
>> I agree with this in general.
>>
>> Would it make sense to at least have review target for make which executes
>> ipa-tool and if it is not installed it tells you where to grab it?
>>
>> Or possibly make ipatool submodule of ipa git tree, so there is no risk of
>> using wrong review tool for particular checkout?
> 
> Please do not overcomplicate it :-) ipatool works nicely at the moment, it is
> in a separate repo with other tools where every core developer can contribute
> and is easy to be update.

-- 
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

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Martin Kosek]

On 12/16/2015 10:02 AM, Petr Spacek wrote:
> On 16.12.2015 09:53, Jan Cholasta wrote:
>> On 16.12.2015 09:45, Petr Spacek wrote:
>>> On 11.12.2015 15:50, Jan Cholasta wrote:
 Hi,

 On 10.12.2015 18:04, Petr Spacek wrote:
> On 9.12.2015 15:30, Petr Spacek wrote:
>> Hello,
>>
>> this patch automates some of sanity checks proposed by Petr Vobornik.
>>
>> 'make review' should be used in root of clean Git tree which has patches
>> under
>> review applied.
>>
>> Magic in review.sh attempts to detect nearest remote branch which can be
>> used
>> as diff base for review. Please see review.sh for further details.
>
> And here is the patch! :-)

 Nice, but I would rather see this in ipatool
 (). Or is there any obvious 
 benefit
 in having this in freeipa itself that I'm missing?
>>>
>>> For me the obvious benefit is:
>>> git clone
>>> git am
>>> make review
>>>
>>> Done.
>>>
>>> No need to find & learn other tool, no risk of using wrong version of the 
>>> tool
>>> to wrong version of source tree etc.
>>
>> AFAIK all IPA developers are supposed to use ipatool, and it already has a
> 
> Good to know. How does a newcomer learn about it? Honestly I never used
> ipatool (or not even cloned it).

ipatool targets rather upstream members with write access, so they are hardly
newcomers.

But still, here you go:
https://www.freeipa.org/page/Contribute/Repository#Process_tools

>> start-review command, so it would better fit in there. Or we could merge
>> freeipa-tools into freeipa. My point is that I don't think having half of the
>> stuff in ipatool and the other half in IPA itself is a good thing to do.
> 
> I agree with this in general.
> 
> Would it make sense to at least have review target for make which executes
> ipa-tool and if it is not installed it tells you where to grab it?
> 
> Or possibly make ipatool submodule of ipa git tree, so there is no risk of
> using wrong review tool for particular checkout?

Please do not overcomplicate it :-) ipatool works nicely at the moment, it is
in a separate repo with other tools where every core developer can contribute
and is easy to be update.

-- 
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

Re: [Freeipa-devel] certmonger everywhere

[Martin Kosek]

On 12/16/2015 09:17 AM, Jan Cholasta wrote:
> On 16.12.2015 08:54, Martin Kosek wrote:
...
>>>   7. cert-request fetches the configuration for the specified sub-CA,
>>> or the
>>> default sub-CA if none was specified, from LDAP
>>>
>>>   8. cert-request forwards the request to the certmonger CA helper
>>> specified in
>>> the LDAP configuration over D-Bus (this is the D-Bus method that
>>> currently does
>>> not exist and needs to be implemented)
>>>
>>>   9. certmonger executes the specified CA helper to handle the request
>>>
>>>   10. the CA helper requests the certificate from the CA and returns
>>> either the
>>> certificate, wait delay or error
>>>
>>>   11. certmonger returns the result back to cert-request
>>
>> These steps are subject to Fraser's question (and I am curious too), i.e.:
>>
>> - how is authentication done? certmonger runs with FreeIPA server host
>> principal.
> 
> We are on the server, so the RA agent cert is used to authenticate to Dogtag 
> as
> usual, and whatever authentication is configured for other CAs is used for
> other CAs.

Right, this is how it works now. However, in FreeIPA 4.4 or later, we plan to
switch GSSAPI authentication with Dogtag to get better authorization 
capabilities:

https://fedorahosted.org/freeipa/ticket/5011

But maybe this could be done via S4U2Proxy as Fraser suggested, although in
this case it would be more complicated as certmonger itself does not have
access to user HTTP/ipa.server ticket, like Apache does, given that Apache
would contact certmonger via DBUS.

> 
>> - how will we handle 3-step certificate request, i.e.:
>>- certificate is requested and in moderation/wait queue
>>- request have to be acked by Dogtag administrator (we do not have
>> API yet)
>>- client should be able to ask for generated certificate
> 
> This is not really related to my proposal, since we have to figure this out 
> for
> our Dogtag IPA CA anyway, but the CA helper can return a wait delay in this
> case, so certmonger can poll the request until it is approved.

Ok.

>>>   12. cert-request returns the result back to IPA CA helper on the client
>>>
>>>   13. the IPA CA helper on the client returns the result back to
>>> certmonger
>>>
>>>   14. if the result was wait delay, certmonger waits and then retries the
>>> request from step 4, otherwise it stores the certificate or sets error
>>> status
>>>
>>
>> Right, 12-14 is again the standard flow. Good summary of the steps!
> 
> 

-- 
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

Re: [Freeipa-devel] Testing FreeIPA 4.3 for GA

[Lukas Slebodnik]

On (15/12/15 08:32), Lukas Slebodnik wrote:
>On (15/12/15 01:05), Petr Vobornik wrote:
>>Blocking patches for FreeIPA 4.3 were pushed, ipa-4-3 branch was created.
>>Master branch is ready for 4.4 development.
>>
>>A build is available for testing in my pvoborni/freeipa-4-3 COPR repo [1]
>>until the official 4.3 repo is created. The repo contains only this build.
>>The build is not pure upstream ipa-4-3 branch but rather a build which will
>>go to Fedora rawhide and official 4.3 copr repo - Fedora downstream spec with
>>the SELinux workaround applied [2][3].
>>
>>Known issues:
>>* https://fedorahosted.org/freeipa/ticket/5469 - requires fix in PKI
>>* https://bugzilla.redhat.com/show_bug.cgi?id=1289930 - SELinux Policy update
>>needed for connection check
>>
>>I have started drafting release page [4].
>>
>It looks like there is a bug in dnf, because it cannot install
>freeipa-tests package; which was renamed to python2-ipatests.
>
>[root@3a8359f9e1cd ~]# rpm -q freeipa-server
>freeipa-server-4.3.0-1.fc23.x86_64
>
>
>[root@3a8359f9e1cd ~]# dnf install -y --best freeipa-tests
>Last metadata expiration check performed 0:09:23 ago on Tue Dec 15 07:16:26
>2015.
>Error: package freeipa-tests-4.2.3-1.1.fc23.x86_64 requires freeipa-client =
>4.2.3-1.1.fc23, but none of the providers can be installed.
>package freeipa-tests-4.2.2-1.fc23.x86_64 requires freeipa-python =
>4.2.2-1.fc23, but none of the providers can be installed
>(try to add '--allowerasing' to command line to replace conflicting packages)
>
>
>[root@3a8359f9e1cd ~]# rpm -qp --provides
>./python2-ipatests-4.3.0-1.fc23.noarch.rpm
>freeipa-tests(x86-64) = 4.3.0-1.fc23
>ipa-tests(x86-64) = 4.3.0
>python-ipatests = 4.3.0-1.fc23
>python2-ipatests = 4.3.0-1.fc23
>
>
>FYI: It works with yum-deprecated.
>
dnf bug https://bugzilla.redhat.com/show_bug.cgi?id=1291850

LS

-- 
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

Re: [Freeipa-devel] limiting SyncRepl's scope

[Jakub Hrozek]

On Wed, Dec 16, 2015 at 09:26:11AM +0100, Sumit Bose wrote:
> On Wed, Dec 16, 2015 at 08:49:04AM +0100, Petr Spacek wrote:
> > On 15.12.2015 19:10, Christian Heimes wrote:
> > > Hi,
> > > 
> > > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has
> > > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes
> > > vault-archive fails because of a failed write to the Retro Changelog.
> > > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967
> > > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal
> > > circumstances because 389 doesn't use SyncRepl for replication. In #3967
> > > Nathan has expressed his concerns for possible performance issues, too.
> > > 
> > > Petr, Ludwig,
> > > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than
> > > excluding o=ipaca? The plugin supports both includes and exclude,
> > > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html.
> > 
> > >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX.
> > 
> > One other thing to consider is theoretical use of SyncRepl for future 
> > versions
> > of slapi-nis, Alexander can tell you more about it.
> > 
> > In any case, if we decide to limit scope where SyncRepl is applicable, I 
> > would
> > like to see checks in SyncRepl plugin which will ensure that error
> > UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a
> > 'wrong' scope.
> > 
> 
> There are discussions about using SyncRepl in SSSD as well which would
> include users, groups, sudo and HBAC rules, trusted domains, ... But
> afaik no work in the direction has been started yet, so it might be ok
> to limit the scope for now and add it when there are patches for SSSD
> which really try to use it.

The more I was looking into the sssd performance problems in the last
couple of weeks, the more I think we don't actually need syncrepl on the
clients, maybe only in server mode sssd..

Even the refreshOnly mode has cost associated (IIRC Ludwig told me the
server has to check all changelog entries since the cookie) and I think
on the clients we could improve performance with looking up entries as we
do now, checking if the modifyTimestamp has changed and if not, avoid the
cache write as we discussed over the phone the other day.

For server mode sssd, syncrepl might be interesting, yes. But as you said, so
far I only looked into issues that would also benefit the pure client case.

-- 
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

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Petr Spacek]

On 16.12.2015 09:53, Jan Cholasta wrote:
> On 16.12.2015 09:45, Petr Spacek wrote:
>> On 11.12.2015 15:50, Jan Cholasta wrote:
>>> Hi,
>>>
>>> On 10.12.2015 18:04, Petr Spacek wrote:
 On 9.12.2015 15:30, Petr Spacek wrote:
> Hello,
>
> this patch automates some of sanity checks proposed by Petr Vobornik.
>
> 'make review' should be used in root of clean Git tree which has patches
> under
> review applied.
>
> Magic in review.sh attempts to detect nearest remote branch which can be
> used
> as diff base for review. Please see review.sh for further details.

 And here is the patch! :-)
>>>
>>> Nice, but I would rather see this in ipatool
>>> (). Or is there any obvious 
>>> benefit
>>> in having this in freeipa itself that I'm missing?
>>
>> For me the obvious benefit is:
>> git clone
>> git am
>> make review
>>
>> Done.
>>
>> No need to find & learn other tool, no risk of using wrong version of the 
>> tool
>> to wrong version of source tree etc.
> 
> AFAIK all IPA developers are supposed to use ipatool, and it already has a

Good to know. How does a newcomer learn about it? Honestly I never used
ipatool (or not even cloned it).


> start-review command, so it would better fit in there. Or we could merge
> freeipa-tools into freeipa. My point is that I don't think having half of the
> stuff in ipatool and the other half in IPA itself is a good thing to do.

I agree with this in general.

Would it make sense to at least have review target for make which executes
ipa-tool and if it is not installed it tells you where to grab it?

Or possibly make ipatool submodule of ipa git tree, so there is no risk of
using wrong review tool for particular checkout?

-- 
Petr^2 Spacek

-- 
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

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Jan Cholasta]

On 16.12.2015 09:45, Petr Spacek wrote:

On 11.12.2015 15:50, Jan Cholasta wrote:

Hi,

On 10.12.2015 18:04, Petr Spacek wrote:

On 9.12.2015 15:30, Petr Spacek wrote:

Hello,

this patch automates some of sanity checks proposed by Petr Vobornik.

'make review' should be used in root of clean Git tree which has patches under
review applied.

Magic in review.sh attempts to detect nearest remote branch which can be used
as diff base for review. Please see review.sh for further details.


And here is the patch! :-)


Nice, but I would rather see this in ipatool
(). Or is there any obvious benefit
in having this in freeipa itself that I'm missing?


For me the obvious benefit is:
git clone
git am
make review

Done.

No need to find & learn other tool, no risk of using wrong version of the tool
to wrong version of source tree etc.


AFAIK all IPA developers are supposed to use ipatool, and it already has 
a start-review command, so it would better fit in there. Or we could 
merge freeipa-tools into freeipa. My point is that I don't think having 
half of the stuff in ipatool and the other half in IPA itself is a good 
thing to do.


--
Jan Cholasta

--
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

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Petr Spacek]

On 11.12.2015 15:50, Jan Cholasta wrote:
> Hi,
> 
> On 10.12.2015 18:04, Petr Spacek wrote:
>> On 9.12.2015 15:30, Petr Spacek wrote:
>>> Hello,
>>>
>>> this patch automates some of sanity checks proposed by Petr Vobornik.
>>>
>>> 'make review' should be used in root of clean Git tree which has patches 
>>> under
>>> review applied.
>>>
>>> Magic in review.sh attempts to detect nearest remote branch which can be 
>>> used
>>> as diff base for review. Please see review.sh for further details.
>>
>> And here is the patch! :-)
> 
> Nice, but I would rather see this in ipatool
> (). Or is there any obvious benefit
> in having this in freeipa itself that I'm missing?

For me the obvious benefit is:
git clone
git am
make review

Done.

No need to find & learn other tool, no risk of using wrong version of the tool
to wrong version of source tree etc.

-- 
Petr^2 Spacek

-- 
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

Re: [Freeipa-devel] limiting SyncRepl's scope

[Ludwig Krispenz]

On 12/16/2015 08:49 AM, Petr Spacek wrote:

On 15.12.2015 19:10, Christian Heimes wrote:

Hi,

in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has
suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes
vault-archive fails because of a failed write to the Retro Changelog.
The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967
for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal
circumstances because 389 doesn't use SyncRepl for replication. In #3967
Nathan has expressed his concerns for possible performance issues, too.

Petr, Ludwig,
would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than
excluding o=ipaca? The plugin supports both includes and exclude,
http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html.

 From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX.

One other thing to consider is theoretical use of SyncRepl for future versions
of slapi-nis, Alexander can tell you more about it.

In any case, if we decide to limit scope where SyncRepl is applicable, I would
like to see checks in SyncRepl plugin which will ensure that error
UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a
'wrong' scope.

yes, that makes sense




--
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

Re: [Freeipa-devel] limiting SyncRepl's scope

[Sumit Bose]

On Wed, Dec 16, 2015 at 08:49:04AM +0100, Petr Spacek wrote:
> On 15.12.2015 19:10, Christian Heimes wrote:
> > Hi,
> > 
> > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has
> > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes
> > vault-archive fails because of a failed write to the Retro Changelog.
> > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967
> > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal
> > circumstances because 389 doesn't use SyncRepl for replication. In #3967
> > Nathan has expressed his concerns for possible performance issues, too.
> > 
> > Petr, Ludwig,
> > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than
> > excluding o=ipaca? The plugin supports both includes and exclude,
> > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html.
> 
> >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX.
> 
> One other thing to consider is theoretical use of SyncRepl for future versions
> of slapi-nis, Alexander can tell you more about it.
> 
> In any case, if we decide to limit scope where SyncRepl is applicable, I would
> like to see checks in SyncRepl plugin which will ensure that error
> UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a
> 'wrong' scope.
> 

There are discussions about using SyncRepl in SSSD as well which would
include users, groups, sudo and HBAC rules, trusted domains, ... But
afaik no work in the direction has been started yet, so it might be ok
to limit the scope for now and add it when there are patches for SSSD
which really try to use it.

bye,
Sumit

-- 
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

Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

On 16.12.2015 08:54, Martin Kosek wrote:

On 12/16/2015 08:09 AM, Jan Cholasta wrote:

On 16.12.2015 01:40, Fraser Tweedale wrote:

On Tue, Dec 15, 2015 at 04:23:33PM +0100, Martin Kosek wrote:

On 12/15/2015 08:54 AM, Jan Cholasta wrote:

Hi,

recently I and David discussed the direction of installers with
regard to
requesting certificates. Currently there are four (!) different
ways of
requesting certificates in the installer [1][2][3][4]. We would
like to reduce
it to one.

Since all the certificates are tracked by certmonger and certmonger
already
knows how to request certificates from Dogtag (and other CAs), we
believe that
all certificates should be requested using certmonger.

Taking our meditation further, we thought "Why not use certmonger
for the
cert-request command as well?" What is the benefit, do you ask?

  a) single code path for requesting certificates (seriously, the
current
state
is ridiculous)

  b) use any CA supported by certmonger as the IPA CA (i.e. Let's
Encrypt [5],
once certmonger gains support for it)

  c) automate external CA install, using any CA supported by
certmonger [6]

  d) support multiple different CAs at once (generalization of the
Sub-CA
feature)

  e) uniform configuration on clients (configure once, use forever,
even for
CA-less)

The idea is to store configuration for the different CAs in LDAP
and have
cert-request redirect requests to a proper CA helper according to that
configuration. This would require a new certmonger D-Bus method to
call a CA
helper without associated certificate storage, but that should be
rather easy
to add. In return, it would be possible to do all of the above.

Note that this should not conflict with tighter integration with
Dogtag
(profiles, ACLs, etc.).

Comments are welcome.

Honza

[1]



[2]




[3]




[4]




[5] 
[6] 


Interesting idea! I would be definitely interested to hear what
Fraser, Rob or
Simo thinks here.


For the installer cases, +1 from me.

For the general cert-request case, currently Certmonger calls `ipa
cert-request' using host credentials (Kerberos), and IPA framework
does some validation (e.g. ensure CN and altNames correspond to
subject principal), before requesting cert from Dogtag using RA
Agent credentials (TLS client cert).

There are a few things that have to happen before Certmonger can
request certs directly from Dogtag, in IPA scenario:

1. support SNPEGO authentication in Dogtag (work has started)

2. perform all validation that IPA framework currently performs in
Dogtag, or make the validation no longer required by pulling cert
data straight from LDAP according to the profile.

3. Requestor credentials must be delegated to Certmonger so that the
correct principal is used to talk to Dogtag.  Presumably this would
be S4U2Proxy constrained delegation with host/ as
impersonator and Dogtag service principal as target.

At that point `ipa cert-request' can become a client-side command
that merely configures Certmonger to request the cert.


I'm not proposing to change cert-request to a client side command - I'm
proposing to change the way cert-request is handled *on the server*.


I do not think Fraser was suggesting to change cert-request to a client
side command. More below.


See 3 paragraphs above: "... `ipa cert-request' can become a client-side 
command...".





This way
we can keep all the configuration on the server and make changes to it
without
having to reconfigure all clients.

This is how I envision the workflow:

  1. client requests a certificate with "getcert request", using "IPA"
as the
CA and, optionally, a string identifying the sub-CA (for the lack of
better term)

  2. "getcert request" forwards the request to certmonger over D-Bus
and exits

  3. certmonger creates CSR for the request

  4. certmonger executes the IPA CA helper to handle the request

  5. the IPA CA helper calls the cert-request command on the server
over RPC,
using local host credentials for authentication

  6. cert-request on the server validates the request


Right. These are the steps that happen already, AFAIK.


Correct.




  7. cert-request fetches the configuration for the specified sub-CA,
or the
default sub-CA if none was specified, from LDAP

  8. cert-request forwards the request to the certmonger CA helper
specified in
the LDAP configuration over D-Bus (this is the D-Bus method that
currently does
not exist and needs to be implemented)

  9. certmonger executes the specified CA helper to handle the request

  10. the CA helper requests the certificate from th