Re: [Freeipa-devel] certmonger everywhere

[Simo Sorce]

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

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] Testing FreeIPA 4.3 for GA

[Aleš Mareček]

- Original Message -
> From: "Milan Kubík" 
> To: "Petr Vobornik" 
> Cc: "freeipa-devel" , "Ales Marecek" 
> 
> Sent: Tuesday, December 15, 2015 4:53:18 PM
> Subject: Re: [Freeipa-devel] Testing FreeIPA 4.3 for GA
> 
> On 12/15/2015 04:35 PM, Petr Vobornik wrote:
> > On 12/15/2015 01:05 AM, 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].
> >>
> >> [1] https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/
> >> [2] https://fedorahosted.org/freeipa/ticket/5533
> >> [3]
> >> http://www.redhat.com/archives/freeipa-devel/2015-December/msg00234.html
> >> [4] http://www.freeipa.org/page/Releases/4.3.0
> >
> > Copr contains a rebuild with a patch for ticket:
> >   https://fedorahosted.org/freeipa/ticket/5551
> >
> > https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/build/147975/
> >
> > The build has exactly the same version as the one before. Ales, Milan,
> > do we want to differentiate that somehow?
> >
> The job uses fresh install of the rpms. The same version and build
> shouldn't be a problem.

+1, I don't see any issue to use the "same" (not-yet-released) version.

> 
> --
> Milan Kubik
> 
> 

-- 
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] Retro Changelog for bind-dyndb-ldap

[Christian Heimes]

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.

Christian



signature.asc
Description: OpenPGP digital signature
-- 
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

[Milan Kubík]

On 12/15/2015 05:04 PM, Aleš Mareček wrote:


- Original Message -

From: "Milan Kubík" 
To: "Petr Vobornik" 
Cc: "freeipa-devel" , "Ales Marecek" 

Sent: Tuesday, December 15, 2015 4:53:18 PM
Subject: Re: [Freeipa-devel] Testing FreeIPA 4.3 for GA

On 12/15/2015 04:35 PM, Petr Vobornik wrote:

On 12/15/2015 01:05 AM, 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].

[1] https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/
[2] https://fedorahosted.org/freeipa/ticket/5533
[3]
http://www.redhat.com/archives/freeipa-devel/2015-December/msg00234.html
[4] http://www.freeipa.org/page/Releases/4.3.0

Copr contains a rebuild with a patch for ticket:
   https://fedorahosted.org/freeipa/ticket/5551

https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/build/147975/

The build has exactly the same version as the one before. Ales, Milan,
do we want to differentiate that somehow?


The job uses fresh install of the rpms. The same version and build
shouldn't be a problem.

+1, I don't see any issue to use the "same" (not-yet-released) version.


--
Milan Kubik


On a second thought, increasing the build number may be useful. I just 
ran into the cyclic import issue again. Until I looked into the rpm I 
wasn't sure if I got the newer packages.


--
Milan Kubik

--
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 0365] Remove unused KRA code from ipa-server-install

[Alexander Bokovoy]

On Tue, 15 Dec 2015, David Kupka wrote:

On 14/12/15 16:54, Alexander Bokovoy wrote:

On Mon, 14 Dec 2015, David Kupka wrote:

On 14/12/15 15:05, Alexander Bokovoy wrote:

On Mon, 14 Dec 2015, David Kupka wrote:

On 30/11/15 16:31, Martin Basti wrote:

First instance of KRA should be installed only by ipa-kra-install

Patch attached.





Hi,
patch works, but I don't like the approach.

Do we really want to remove '--setup-kra' option from
ipa-server-install?
Why do we remove '--setup-kra' while keeping '--setup-dns'? Why do we
keep installing PKI CA when it can be also installed later?

Yes, we do want. Adding the option was an error in the first place. This
patch fixes the error.


I would love if 'ipa-server-install' installed only the bare minimum
needed and then other features was added using ipa-{feature}-install
but also I don't mind one almighty installer that can install all
possible combinations of features.
But this is neither of it. This just brings another inconsistency into
FreeIPA behavior.

We don't have --with-adtrust either. And we don't want it.


Ok, then are we aiming for 'ipa-server-install' that only installs the
bare minimum and everything else should be installed later?

Or, do we decide per feature if it's appropriate to include it in
'ipa-server-install'? What are the criteria in this case?

Per feature decision is a bit better description of an ad-hoc process we
have so far.

As we had this discussion with Simo today, let me quickly capture
arguments for both. We typically allow options in ipa-server-install for
features that can be present and used very early. Certificates are
issued early in the process, DNS records are critical to exist before
hosts can be added and can start using Kerberos and so on. However,
trust to AD cannot be established to 'just deployed' FreeIPA realm, you
need to pre-configure your and that remote realm.

Certificates were in particular important part of the story before we
added support for GSSAPI authentication between replicas (4.3 release is
going to have it). This meant we were constrained by the fact that some
entity had to issue certificates before we even create a replica.

I was arguing that having KRA would require us to have full fledged CA
as we depend on ability to issue certificates for KRA feature to be
useful as well. While standard CA is somewhat optional in the case only
end-point service certs are needed (Let's Encrypt is a solution there),
having KRA means use of some CA. So to me having KRA means we have CA
already, why not to simply merge the two setting into --setup-ca at all?

Separate installers also were used in past as a gap-bridging tool to
allow people to upgrade their old deployments and gain new
functionality. So separate installer has another function than just
deploying a service.

Having --with-kra option thus makes less sense. We can consider KRA
functionality to be in a default feature set at some point, that would
still require us to have a separate installer, ipa-kra-install, to allow
extending old deployments to provide new feature.



The fact that the DNS records need to exist for some (core) IPA 
functionality does not necessary mean that we need DNS server 
installed as a part of FreeIPA. We even support DNS-less install and 
user is then responsible for maintaining DNS records in server of his 
choice.
IOW 'ipa-server-install --setup-dns' results in the same as 
'ipa-server-install && ipa-dns-install'.

It means we require DNS is there -- be it internal or as external
service provided by something else. There is no DNS-less install in
reality, something has to provide SRV records, you cannot have FreeIPA
deployment without DNS at all for some use cases -- for example, trust
to AD requires DNS infrastructure to exist.

The difference we have for DNS and CA/KRA is that we cannot work with
any other CA for all certificate types yet and KRA is simply not
supporting anything but Dogtag CA on the same IPA master, so --setup-kra
is implying --setup-ca, and thus could be simply merged into --setup-ca
once we decide KRA functionality is stable enough to be part of default
install.

In case of trust, would it be really impossible to preconfigure the 
remote realm and then provide all necessary information to 
'ipa-server-install --setup-trust'? Or is it just the way we're doing 
it right now for some maybe really good reason?

It is always possible to merge functionality into a single installer but
I'm not sure we'll gain anything reasonable from it in this particular
case. Configuring trust is about two things: (a) setup software on IPA
master, and (b) create a number of special objects in both IPA and
Active Directory. To do (a) you can merge things into the installer but
to do (b) you need to perform operations on AD side and which operations
you would perform depends on what other choices you did when installed
IPA -- if you did not install internal DNS, you would need to create a
number of SRV records for IPA 

Re: [Freeipa-devel] certmonger everywhere

[Petr Spacek]

On 15.12.2015 08:54, 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.

It makes a lot of sense to me!

Petr^2 Spacek

> Honza
> 
> [1]
> 
> [2]
> 
> 
> [3]
> 
> 
> [4]
> 
> 
> [5] 
> [6] 

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

[Oleg Fayans]

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

Re: [Freeipa-devel] [PATCH 0365] Remove unused KRA code from ipa-server-install

[Alexander Bokovoy]

On Tue, 15 Dec 2015, Jan Cholasta wrote:

On 14.12.2015 16:54, Alexander Bokovoy wrote:

On Mon, 14 Dec 2015, David Kupka wrote:

On 14/12/15 15:05, Alexander Bokovoy wrote:

On Mon, 14 Dec 2015, David Kupka wrote:

On 30/11/15 16:31, Martin Basti wrote:

First instance of KRA should be installed only by ipa-kra-install

Patch attached.





Hi,
patch works, but I don't like the approach.

Do we really want to remove '--setup-kra' option from
ipa-server-install?
Why do we remove '--setup-kra' while keeping '--setup-dns'? Why do we
keep installing PKI CA when it can be also installed later?

Yes, we do want. Adding the option was an error in the first place. This
patch fixes the error.


I would love if 'ipa-server-install' installed only the bare minimum
needed and then other features was added using ipa-{feature}-install
but also I don't mind one almighty installer that can install all
possible combinations of features.
But this is neither of it. This just brings another inconsistency into
FreeIPA behavior.

We don't have --with-adtrust either. And we don't want it.


Ok, then are we aiming for 'ipa-server-install' that only installs the
bare minimum and everything else should be installed later?

Or, do we decide per feature if it's appropriate to include it in
'ipa-server-install'? What are the criteria in this case?

Per feature decision is a bit better description of an ad-hoc process we
have so far.

As we had this discussion with Simo today, let me quickly capture
arguments for both. We typically allow options in ipa-server-install for
features that can be present and used very early. Certificates are
issued early in the process, DNS records are critical to exist before
hosts can be added and can start using Kerberos and so on. However,
trust to AD cannot be established to 'just deployed' FreeIPA realm, you
need to pre-configure your and that remote realm.

Certificates were in particular important part of the story before we
added support for GSSAPI authentication between replicas (4.3 release is
going to have it). This meant we were constrained by the fact that some
entity had to issue certificates before we even create a replica.

I was arguing that having KRA would require us to have full fledged CA
as we depend on ability to issue certificates for KRA feature to be
useful as well. While standard CA is somewhat optional in the case only
end-point service certs are needed (Let's Encrypt is a solution there),
having KRA means use of some CA. So to me having KRA means we have CA
already, why not to simply merge the two setting into --setup-ca at all?


Because KRA is a separate component that does something completely 
different than a CA and is configured separately even in Dogtag. The 
logic here is exactly the reverse - if you want to install KRA, you 
have to install (Dogtag) CA, not the other way around, so merging both 
into --setup-ca does not make sense.

That's exactly what I said, isn't it: CA is required to be installed
before KRA. However, if we would like to have KRA functionality by
default every time we have CA (we are not going to have a separate
replication topology for KRA, aren't we?), then --setup-ca would cover
installing both and --setup-kra would not be needed.



Separate installers also were used in past as a gap-bridging tool to
allow people to upgrade their old deployments and gain new
functionality. So separate installer has another function than just
deploying a service.

Having --with-kra option thus makes less sense. We can consider KRA
functionality to be in a default feature set at some point, that would
still require us to have a separate installer, ipa-kra-install, to allow
extending old deployments to provide new feature.


We can always have both. With the new installer framework it is 
trivial to fold installers like this without code duplication. It is 
still work in progress though, so I would prefer not to add 
--setup-kra to ipa-server-install now (if ever).

Yep.

--
/ 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] certmonger everywhere

[Martin Basti]

On 15.12.2015 08:54, 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] 


LGTM

--
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 0007] Multiple managers per user

[Lenka Doudova]

Hi,

I updated the (stage)user tests to reflect the multiple managers per 
user feature.

Corresponding ticket: https://fedorahosted.org/freeipa/ticket/5344

Lenka
From 03b4673debf019562d00d0c0f4cfcf3f295fa612 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Mon, 14 Dec 2015 06:51:47 +0100
Subject: [PATCH] Tests: Multiple managers per user

Adding Tracker methods and new tests to test multiple managers per (stage)user feature.
https://fedorahosted.org/freeipa/ticket/5344
---
 ipatests/test_xmlrpc/test_stageuser_plugin.py| 127 +++
 ipatests/test_xmlrpc/test_user_plugin.py |  96 +
 ipatests/test_xmlrpc/tracker/stageuser_plugin.py |  97 +
 ipatests/test_xmlrpc/tracker/user_plugin.py  | 117 -
 4 files changed, 434 insertions(+), 3 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_stageuser_plugin.py b/ipatests/test_xmlrpc/test_stageuser_plugin.py
index 42ecf046884369bd74b03194937c425215b99f6c..e597acf0d32a2cf707d69eced655d5e34cb3a3be 100644
--- a/ipatests/test_xmlrpc/test_stageuser_plugin.py
+++ b/ipatests/test_xmlrpc/test_stageuser_plugin.py
@@ -673,3 +673,130 @@ class TestGroups(XMLRPC_test):
 command = group.make_add_member_command(options={u'user': user.uid})
 result = command()
 group.check_add_member_negative(result)
+
+
+@pytest.fixture(scope='class')
+def stageduser_with_manager(request):
+tracker = StageUserTracker(u'tuser1', u'test', u'user')
+return tracker.make_fixture_activate(request)
+
+
+@pytest.fixture(scope='class')
+def manager1(request):
+tracker = UserTracker(u'manager1', u'test', u'manager')
+return tracker.make_fixture(request)
+
+
+@pytest.fixture(scope='class')
+def manager2(request):
+tracker = UserTracker(u'manager2', u'test', u'manager')
+return tracker.make_fixture(request)
+
+
+@pytest.fixture(scope='class')
+def user_activated_with_manager(request):
+tracker = UserTracker(u'tuser1', u'test', u'user')
+return tracker.make_fixture(request)
+
+
+@pytest.mark.tier1
+class TestMultipleManagers(XMLRPC_test):
+def test_add_manager(
+self, stageduser_with_manager, manager1, manager2,
+user_activated_with_manager):
+stageduser_with_manager.ensure_exists()
+manager1.ensure_exists()
+manager2.ensure_exists()
+stageduser_with_manager.add_manager(
+managers=[manager1.uid, manager2.uid])
+
+# verify managers are preserved after activation
+user_activated_with_manager.activate(stageduser_with_manager)
+user_activated_with_manager.delete()
+
+def test_add_duplicate_manager(self, stageduser, manager1):
+stageduser.ensure_exists()
+manager1.ensure_exists()
+stageduser.add_manager(
+managers=[manager1.uid, manager1.uid],
+expected_fail={manager1.uid: u'already_manager'})
+stageduser.delete()
+
+def test_add_nonexistent_manager(self, stageduser, manager1):
+stageduser.ensure_exists()
+manager1.ensure_missing()
+stageduser.add_manager(
+managers=[manager1.uid],
+expected_fail={manager1.uid: 'nonexistent'})
+stageduser.delete()
+
+def test_remove_manager(self, stageduser, manager1, manager2):
+stageduser.ensure_exists()
+manager1.ensure_exists()
+manager2.ensure_exists()
+stageduser.add_manager(managers=[manager1.uid, manager2.uid])
+stageduser.remove_manager(managers=[manager1.uid])
+stageduser.delete()
+
+def test_remove_nonmanager(self, stageduser, manager1):
+stageduser.ensure_exists()
+manager1.ensure_exists()
+stageduser.remove_manager(
+managers=[manager1.uid],
+expected_fail={manager1.uid: u'not_manager'})
+stageduser.delete()
+
+def test_remove_nonexistent(self, stageduser, manager1):
+stageduser.ensure_exists()
+manager1.ensure_missing()
+stageduser.remove_manager(
+managers=[manager1.uid],
+expected_fail=[manager1.uid])
+stageduser.delete()
+
+def test_show_multiple_managers(self, stageduser, manager1, manager2):
+""" Verifies that multiple managers are listed properly
+on 'stageuser-show' command """
+stageduser.ensure_exists()
+manager1.ensure_exists()
+manager2.ensure_exists()
+stageduser.add_manager(managers=[manager1.uid, manager2.uid])
+
+command = stageduser.make_retrieve_command()
+result = command()
+stageduser.check_retrieve(result)
+stageduser.delete()
+
+def test_delete_all_managers(self, stageduser, manager1, manager2):
+""" Verifies that all managers assigned to a user are removed
+when original 'stageuser-mod' command is used with empty
+--manager option """
+stageduser.ensure_exists()
+

Re: [Freeipa-devel] [PATCH 0117] ipa-client-install: create a temporary directory for ccache files

[Martin Kosek]

On 12/15/2015 08:03 AM, Martin Babinsky wrote:
> On 12/15/2015 07:19 AM, Jan Cholasta wrote:
>> On 14.12.2015 18:51, Tomas Babej wrote:
>>>
>>>
>>> On 12/14/2015 05:31 PM, Martin Babinsky wrote:
 fixes https://fedorahosted.org/freeipa/ticket/5528
>>>
>>> Works as expected, code-wise looks good.
>>>
>>> Thanks for looking into this, ACK!
>>>
>>> Pushed to master: 5886f87f974fa508047a21350c2e6e75a3001da6
>>
>> It would probably be better if ipa-client-install used
>> ipautil.private_ccache(), but I guess we can fix that later, once we
>> start digging into ipa-client-install componentization / rectofaring.
>>
> Yes since that would probably require heroic amounts of spaghetti untangling 
> to
> get it right. Anyway we have any milestone for ipa-client refactoring? Is it a
> part of 4.4 installer redesign effort?

Client refactoring is not currently planned for 4.4. There are plans for "Thin
Client", but not ipa-client-install refactoring. This would fall in 4.5 or even
later, I think.

-- 
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 0117] ipa-client-install: create a temporary directory for ccache files

[Martin Kosek]

On 12/14/2015 06:51 PM, Tomas Babej wrote:
> 
> 
> On 12/14/2015 05:31 PM, Martin Babinsky wrote:
>> fixes https://fedorahosted.org/freeipa/ticket/5528
> 
> Works as expected, code-wise looks good.
> 
> Thanks for looking into this, ACK!
> 
> Pushed to master: 5886f87f974fa508047a21350c2e6e75a3001da6
> 

Looks like something that should also land in ipa-4-3, no?

-- 
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 0117] ipa-client-install: create a temporary directory for ccache files

[Martin Kosek]

On 12/15/2015 12:39 PM, Martin Kosek wrote:
> On 12/14/2015 06:51 PM, Tomas Babej wrote:
>>
>>
>> On 12/14/2015 05:31 PM, Martin Babinsky wrote:
>>> fixes https://fedorahosted.org/freeipa/ticket/5528
>>
>> Works as expected, code-wise looks good.
>>
>> Thanks for looking into this, ACK!
>>
>> Pushed to master: 5886f87f974fa508047a21350c2e6e75a3001da6
>>
> 
> Looks like something that should also land in ipa-4-3, no?
> 

Ah, the actual push was yesterday before the branch - please disregard my
message :-)

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

On 12/15/2015 10:29 AM, 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



That may be due to SELinux preventing oddjob to run 
'org.freeipa.server.conn_check'. Try running the tests with permissive 
SELinux on all VMs.



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 

Re: [Freeipa-devel] [PATCH 0117] ipa-client-install: create a temporary directory for ccache files

[Jan Cholasta]

On 15.12.2015 12:41, Martin Kosek wrote:

On 12/15/2015 08:03 AM, Martin Babinsky wrote:

On 12/15/2015 07:19 AM, Jan Cholasta wrote:

On 14.12.2015 18:51, Tomas Babej wrote:



On 12/14/2015 05:31 PM, Martin Babinsky wrote:

fixes https://fedorahosted.org/freeipa/ticket/5528


Works as expected, code-wise looks good.

Thanks for looking into this, ACK!

Pushed to master: 5886f87f974fa508047a21350c2e6e75a3001da6


It would probably be better if ipa-client-install used
ipautil.private_ccache(), but I guess we can fix that later, once we
start digging into ipa-client-install componentization / rectofaring.


Yes since that would probably require heroic amounts of spaghetti untangling to
get it right. Anyway we have any milestone for ipa-client refactoring? Is it a
part of 4.4 installer redesign effort?


Client refactoring is not currently planned for 4.4. There are plans for "Thin
Client", but not ipa-client-install refactoring. This would fall in 4.5 or even
later, I think.


For further server/replica installer improvements, it's necessary to at 
least create a module from ipa-client-install. So, unless you want to 
freeze server installers in their current (WIP) state, we have to touch 
ipa-client-install as well.


--
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] certmonger everywhere

[Fraser Tweedale]

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.

Cheers,
Fraser

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Milan Kubík]

On 12/15/2015 04:35 PM, Petr Vobornik wrote:

On 12/15/2015 01:05 AM, 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].

[1] https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/
[2] https://fedorahosted.org/freeipa/ticket/5533
[3]
http://www.redhat.com/archives/freeipa-devel/2015-December/msg00234.html
[4] http://www.freeipa.org/page/Releases/4.3.0


Copr contains a rebuild with a patch for ticket:
  https://fedorahosted.org/freeipa/ticket/5551

https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/build/147975/

The build has exactly the same version as the one before. Ales, Milan, 
do we want to differentiate that somehow?


The job uses fresh install of the rpms. The same version and build 
shouldn't be a problem.


--
Milan Kubik

--
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 0001] ipa-server-certinstall should not tell certmonger to track 3rd party certificates

[Thorsten Scherf]

>From 13c564e106300f19ba59531ebdf3ba90b7b8ef35 Mon Sep 17 00:00:00 2001
From: Thorsten Scherf 
Date: Tue, 15 Dec 2015 14:17:26 +0100
Subject: [PATCH] ipa-server-certinstall should not tell certmonger to track
 3rd party certs

There is no point in tracking a 3rd party cert, as it cannot be renewed
automatically.

https://fedorahosted.org/freeipa/ticket/4785
---
 ipaserver/install/ipa_server_certinstall.py | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/ipaserver/install/ipa_server_certinstall.py 
b/ipaserver/install/ipa_server_certinstall.py
index 
ac0b0274e4e36db4ea6fb695afb527e2b83a8c77..b5f317cd6328dbaec694b5eff6230f8a9fe302a7
 100644
--- a/ipaserver/install/ipa_server_certinstall.py
+++ b/ipaserver/install/ipa_server_certinstall.py
@@ -175,9 +175,6 @@ class ServerCertInstall(admintool.AdminTool):
 cdb.import_pkcs12(pkcs12_file.name, pin)
 server_cert = cdb.find_server_certs()[0][0]
 
-if ca_enabled:
-cdb.track_server_cert(server_cert, principal, cdb.passwd_fname,
-  command)
 except RuntimeError as e:
 raise admintool.ScriptError(str(e))
 
-- 
1.9.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

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

[Jan Cholasta]

Hi,

the attached patch fixes .

Pushed to under the one-liner rule:
master: c265e8736e51d5b4fede94a414d83b3e0ada2853
ipa-4-3: 2b28704f926d24e1562b481880b111d12d2020f2

Honza

--
Jan Cholasta
From 5bc2cf27e6dc38b71e6dae61efd3ba67f4973ed2 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Tue, 15 Dec 2015 15:29:36 +0100
Subject: [PATCH] ipautil: remove unused import causing cyclic import in tests

https://fedorahosted.org/freeipa/ticket/5551
---
 ipapython/ipautil.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index 7509f08..478 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -52,7 +52,6 @@ from ipapython import config
 from ipaplatform.paths import paths
 from ipapython.dn import DN
 from ipapython.dnsutil import DNSName
-from ipalib.util import normalize_zone
 
 SHARE_DIR = paths.USR_SHARE_IPA_DIR
 PLUGINS_SHARE_DIR = paths.IPA_PLUGINS
-- 
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] 0751 spec: Split out python-ipap11helper and, python-default_encoding_utf8

[Petr Viktorin]

On 12/14/2015 08:18 AM, Jan Cholasta wrote:
> On 4.12.2015 14:29, Jan Cholasta wrote:
>> Hi,
>>
>> On 3.12.2015 17:32, Petr Viktorin wrote:
>>> Hello,
>>> This specfile patch makes python-ipalib noarch, by splitting out the
>>> arch-dependent stuff.
>>
>> I'm not sure if this should be done at all. Both py_default_encoding and
>> (especially) _ipap11helper are internal submodules of ipapython and I
>> don't think they should be packaged separately.

Technically they aren't – it's "import _ipap11helper", not "import
ipapython._ipap11helper". Their source is in the ipapython directory,
but they're built as independent modules.

>> If this is just about packaging arch-specific code separately from
>> noarch code, I'm not sure either - all other packages with both Python
>> and C modules I have seen (e.g. python-ldap, PyYAML) simply do not care
>> and put everything in a single arch-specific package. IMHO we should
>> follow.
> 
> This would mean putting everything into the architecture-specific
> prefix. Currently the python files in python2-ipalib are installed into
> the architecture-agnostic prefix, which is wrong, because you can't
> install both python2-ipalib.i686 and python2-ipalib.x86_64 at the same
> time.

Putting everything into arch-specific prefix would mean that if you do
install both arches simultaneously, you'd get two identical copies of
ipalib, ipapython, and ipaplatform. So if having both installed is a
concern, I think the noarch bits should be split out.


-- 
Petr Viktorin

-- 
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] 0751 spec: Split out python-ipap11helper and, python-default_encoding_utf8

[Jan Cholasta]

On 15.12.2015 15:53, Petr Viktorin wrote:

On 12/14/2015 08:18 AM, Jan Cholasta wrote:

On 4.12.2015 14:29, Jan Cholasta wrote:

Hi,

On 3.12.2015 17:32, Petr Viktorin wrote:

Hello,
This specfile patch makes python-ipalib noarch, by splitting out the
arch-dependent stuff.


I'm not sure if this should be done at all. Both py_default_encoding and
(especially) _ipap11helper are internal submodules of ipapython and I
don't think they should be packaged separately.


Technically they aren't – it's "import _ipap11helper", not "import
ipapython._ipap11helper". Their source is in the ipapython directory,
but they're built as independent modules.


This is an implementation detail rather than an architectural decision. 
For _ipap11helper, we haven't figured out how to properly put it inside 
ipapython, so it's build separately, but it actually is a part of ipapython.





If this is just about packaging arch-specific code separately from
noarch code, I'm not sure either - all other packages with both Python
and C modules I have seen (e.g. python-ldap, PyYAML) simply do not care
and put everything in a single arch-specific package. IMHO we should
follow.


This would mean putting everything into the architecture-specific
prefix. Currently the python files in python2-ipalib are installed into
the architecture-agnostic prefix, which is wrong, because you can't
install both python2-ipalib.i686 and python2-ipalib.x86_64 at the same
time.


Putting everything into arch-specific prefix would mean that if you do
install both arches simultaneously, you'd get two identical copies of
ipalib, ipapython, and ipaplatform. So if having both installed is a
concern, I think the noarch bits should be split out.


I'm aware this means two identical copies of the modules, but the same 
thing works for python-ldap and PyYAML (as I pointed out above), so why 
shouldn't it work for us?


--
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] certmonger everywhere

[Martin Kosek]

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.



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.


  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 

Re: [Freeipa-devel] [PATCH 0365] Remove unused KRA code from ipa-server-install

[David Kupka]

On 15/12/15 16:20, Martin Kosek wrote:

On 12/15/2015 07:42 AM, Jan Cholasta wrote:

On 14.12.2015 16:54, Alexander Bokovoy wrote:

On Mon, 14 Dec 2015, David Kupka wrote:

...

We can always have both. With the new installer framework it is trivial to fold
installers like this without code duplication. It is still work in progress
though, so I would prefer not to add --setup-kra to ipa-server-install now (if
ever).


+1, I would also rather not make ipa-server-install too monolithic. Even from
testing POV, I think doing KRA fixes in one installer is much more easier than
doing it also in replica or server installers (although Jan's patches help
here, that's true).



If you look on the patch Martin send, you will see that there is nothing 
monolithic in installing KRA in ipa-server-install.
In fact, it calls kra.check_install() and kra.install(), the very same 
functions that are called from ipa-kra-install.


But it seems that majority of us is decided to remove the ability to 
install KRA from ipa-server-install and since I've tested the patch and 
didn't find any issues we can push it, 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] [PATCH 0365] Remove unused KRA code from ipa-server-install

[Martin Kosek]

On 12/15/2015 07:42 AM, Jan Cholasta wrote:
> On 14.12.2015 16:54, Alexander Bokovoy wrote:
>> On Mon, 14 Dec 2015, David Kupka wrote:
...
> We can always have both. With the new installer framework it is trivial to 
> fold
> installers like this without code duplication. It is still work in progress
> though, so I would prefer not to add --setup-kra to ipa-server-install now (if
> ever).

+1, I would also rather not make ipa-server-install too monolithic. Even from
testing POV, I think doing KRA fixes in one installer is much more easier than
doing it also in replica or server installers (although Jan's patches help
here, that's true).

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

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

[Petr Vobornik]

On 12/15/2015 01:05 AM, 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].

[1] https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/
[2] https://fedorahosted.org/freeipa/ticket/5533
[3]
http://www.redhat.com/archives/freeipa-devel/2015-December/msg00234.html
[4] http://www.freeipa.org/page/Releases/4.3.0


Copr contains a rebuild with a patch for ticket:
  https://fedorahosted.org/freeipa/ticket/5551

https://copr.fedoraproject.org/coprs/pvoborni/freeipa-4-3/build/147975/

The build has exactly the same version as the one before. Ales, Milan, 
do we want to differentiate that somehow?


--
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] certmonger everywhere

[Jan Cholasta]

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

 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

 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 

Re: [Freeipa-devel] certmonger everywhere

[Jan Cholasta]

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.


--
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] limiting SyncRepl's scope

[Petr Spacek]

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.

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