Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA

[David Kupka]

On 02/09/15 14:27, Simo Sorce wrote:

On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote:

On 01/09/15 16:53, Simo Sorce wrote:

On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote:

Hi list,

I own the following ticket https://fedorahosted.org/freeipa/ticket/3864
and I would like to clarify what needs to be done in order to make IPA
to fully support multiple aliases per entry.

So far I have identified these task based on the ticket comments and
discussion with Simo way back in the past:

1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is
not used in the new code.

2.) fix ACIs that do not permit setting multiple values of
'krbPrincipalName' attribute per entry (see
https://fedorahosted.org/freeipa/ticket/3961)

3.) Modify KDB backend (namely 'ipadb_fetch_principal' and
'ipadb_find_principal' functions) to correctly perform lookup of
krbprincipalname/krbcanonicalname, i.e. search krbprincipalname
case-insensitively and krbcanonicalname case-sensitively, return
krbcanonicalname when canonicalization is requested.

4.) Modify KDB backend and IPA framework to handle creation of both
krbprincipalname and krbcanonicalname. I am not quite sure what cases
should be covered here (I remember that we should create
krbcanonicalname when we add another aliases to krbprincipalname), so it
would be nice if you could comment on this.

5.) write tests which cover all this stuff so that we don't shoot
ourselves in the foot.

I am not very well versed in Kerberos so I might get some of this stuff
wrong. If that's the case please point me to the right direction. Also
please write me some additional stuff which I have fogot and needs to be
done.



I think the summary is correct, the only thing we need to be careful is
to keep handling entries that have only a single valued krbprincipalname
correctly as that will happen in upgrade paths and potentially if
someone uses external tools.

The tricky part for point 3 is to implement it *without* changing the
schema. KrbPrincipalName is case-sensitive, however I think we can solve
the issue of "searching case-insensitively" by always lower-casing the
principal name components and always upper casing the realm part on
storage. If we always store a krbCanonicalName we get the "correct" case
there anyway so out mucking with the krbPrincipalName case will not be a
problem for any new entry.


Or as Honza pointed out we can use case-insensitive search like this:
(krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return
all variants of casing and reduce the need for fallback code.


The principal name is not case insensitive, a search like that would
probably cause DS to do a full search through the krbPrincipalName
index, it might quickly become a performance issue. Before choosing a
method please create an install with a 1 principals, and then
compare the speed of a few thousand search with exact matching case and
a few with specifying caseIgnoreMatch and see the difference.

Simo.


We will add index for caseIgnoreCaseIA5Match matching rule on 
krbPrincipalName and then the case insensitive match should be as quick 
as the case sensitive.


Without the index it is indeed far slower. I've generated 10k users and 
compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the 
nonindexed one ~2 minutes. That's by two orders of magnitude worse.


When we tried to add the index into DS we uncovered a bug in the way DS 
handles nsMatchingRule attributes. Thierry investigated it and is 
filling the ticket for DS right now. Thierry can you please send link?


Once it's fixed we should be good.

David




This *may* cause issues with upgrades though, so we may need fallback
code that searches with the case sent by the client if we determine the
entry has no krbCanonicalName attribute (sign that it was created before
we started adding krbCanonicalName and never "updated").

Note that we also need to think what will happen during and upgrade when
some servers still use the current code and some servers will use the
new code. So I guess it would be nice if you could write down a table
with all possible forms a principal can be in on rows, and old/new
server states in columns, and mark what will happen for various
operations in each case.

Simo.







--
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 0057] DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5

[Martin Basti]

On 09/01/2015 06:16 PM, Petr Spacek wrote:

Hello,

DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5.

This fixes an forgotten TODO in ipa-ods-exporter.



ACK

--
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 0053-0056] DNSSEC: Fix deadlocks & export to LDAP

[Martin Basti]

On 09/03/2015 10:40 AM, Oleg Fayans wrote:

NACK from me.

2 out of 5 tests still fail with assertion errors:
https://paste.fedoraproject.org/262926/44126948/

Although, I am not sure these failures are caused by the same very 
problem.


On 08/31/2015 06:50 PM, Petr Spacek wrote:

Hello,

Attached patch set should fix the deadlock you discovered + few more 
issues I

spotted when testing the original patch.

Known problems (more patches needed):
- /etc/opendnssec/zonelist.xml should be restored during server 
uninstall

- ccache for ipa-ods-exporter should be removed during server uninstall
- timestamps in .private key files do not reflect (?) current key 
state in

OpenDNSSEC database (I will look into this tomorrow.)







Actually, I did testing and these patches fixing the deadlock.

ACK from me.

You may hit another issue, which is reproducible only by DNSSEC CI test:
named is not able to read keys (we don't know why, because keys are 
ready and readable)

Workaround is just to restart named, and everything will work.

--
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 0307] Server Install: print message that client is being installed

[Simo Sorce]

On Thu, 2015-09-03 at 15:32 +0200, Martin Basti wrote:
> 
> On 09/03/2015 02:42 PM, Simo Sorce wrote:
> > On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote:
> >> On 09/02/2015 06:00 PM, Simo Sorce wrote:
> >>> On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote:
>  Client installation is done as "Restarting web server". This step
>  deserve own message.
> 
>  Patch attached
> >>> I've seen various cases like this. And I can't understand why these
> >>> steps aren't embedded in the actual instance install steps that need the
> >>> restart (which implicitly also provide a message).
> >>>
> >>> In the promotion patchset I did move steps like this into the proper
> >>> instances, so I would prefer you do the same with the install path as
> >>> that is more appropriate.
> >>>
> >>> Simo.
> >>>
> >> We need restart httpd after CA, DNS(optional) installation, so thats why
> >> it is outside of httpd instance.
> > You need to restart httpd always after CA install as it changes the
> > proxy settings, but why do you need to restart it after DNS
> > installation ?
> It is needed due changes in resolv.conf
> >
> > (I think it is fine to restart it twice if it is really needed after DNS
> > change).
> IMO it is waste of time to restart httpd twice in one minute
> 
> Can we resolve this in 4.4, where might be place to finish improvements 
> in installer? (If this is not blocking replica promotion)

Ok, it is not important enough to waste time now.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] 0197 client referral support for trusted domain principal

[Alexander Bokovoy]

On Thu, 03 Sep 2015, Alexander Bokovoy wrote:

Hi,

attached patch adds support for issuing client referrals when FreeIPA
KDC is asked to give a TGT for a principal from a trusted forest.

We return a matching forest name as a realm and KDC then returns an
error pointing a client to a direction of that realm. You can see how it
looks with http://fpaste.org/263064/14412849/ -- it shows behavior for
both 'kinit -E -C' and 'kinit -E'.

Note that current MIT Kerberos KDC has a bug that prevents us from
responding with a correct client referral. A patched version for Fedora
22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is
https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs to
Fedora and RHEL versions.

With the version in my abbra/krb5-test COPR you can test the patch with
the help of kinit like fpaste URL above shows.

After discussing with Simo and Sumit, here is updated patch that
operates directly on 'search_for' krb5_principal and avoids
strchr()/strrchr() and additional memory allocations -- it uses
memrchr() to find '@' in the last component of the search_for principal
and considers the part of the component after '@' as an enterprise realm
to check.

--
/ Alexander Bokovoy
From af2ce7db9c51b7b058c5077801416f2757eb4896 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 20 Aug 2015 15:06:12 +0300
Subject: [PATCH] client referral support for trusted domain principals

https://fedorahosted.org/freeipa/ticket/3559
---
 daemons/ipa-kdb/ipa_kdb.h|  8 +
 daemons/ipa-kdb/ipa_kdb_mspac.c  | 60 
 daemons/ipa-kdb/ipa_kdb_principals.c | 55 +
 3 files changed, 123 insertions(+)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 4abb733..a6f4481 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -274,6 +274,14 @@ krb5_error_code ipadb_check_transited_realms(krb5_context 
kcontext,
 const krb5_data *tr_contents,
 const krb5_data *client_realm,
 const krb5_data *server_realm);
+/* Checks whether a principal's realm is one of trusted domains' realm or 
NetBIOS name
+ * and returns the realm of the matched trusted domain in 'trusted_domain'
+ * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise
+ * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */
+krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext,
+  const char *test_realm, 
size_t size,
+  char **trusted_realm);
+
 /* DELEGATION CHECKS */
 
 krb5_error_code ipadb_check_allowed_to_delegate(krb5_context kcontext,
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 3c0dca8..8594309 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2790,3 +2790,63 @@ krb5_error_code 
ipadb_check_transited_realms(krb5_context kcontext,
}
return ret;
 }
+
+/* Checks whether a principal's realm is one of trusted domains' realm or 
NetBIOS name
+ * and returns the realm of the matched trusted domain in 'trusted_domain'
+ * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise
+ * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */
+krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext,
+ const char *test_realm, 
size_t size,
+ char **trusted_realm)
+{
+   struct ipadb_context *ipactx;
+   int i, j, length;
+   const char *name;
+
+   if (test_realm == NULL || test_realm[0] == '\0') {
+   return KRB5_KDB_NOENTRY;
+   }
+
+   ipactx = ipadb_get_context(kcontext);
+   if (!ipactx || !ipactx->mspac) {
+   return KRB5_KDB_DBNOTINITED;
+   }
+
+   /* First, compare realm with ours, it would not be from a trusted realm 
then */
+   if (strncasecmp(test_realm, ipactx->realm, size) == 0) {
+   return KRB5_KDB_NOENTRY;
+   }
+
+   if (!ipactx->mspac || !ipactx->mspac->trusts) {
+   return KRB5_KDB_NOENTRY;
+   }
+
+   /* Iterate through list of trusts and check if input realm belongs to 
any of the trust */
+   for(i = 0 ; i < ipactx->mspac->num_trusts ; i++) {
+   if ((strncasecmp(test_realm,
+ipactx->mspac->trusts[i].domain_name,
+size) == 0) ||
+   (strncasecmp(test_realm,
+ipactx->mspac->trusts[i].flat_name,
+size) == 0)) {
+   /* return the realm if caller supplied a place for it */
+   if (trusted_realm != NULL) {
+ 

Re: [Freeipa-devel] [PATCH 0305-0306] DNSSEC: better cleanup after uninstall to avoid temporal malfunction

[Petr Spacek]

On 2.9.2015 14:58, Martin Basti wrote:
> Related to ticket  https://fedorahosted.org/freeipa/ticket/5273
> 
> Patches attached.

ACK

-- 
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 0304] Installer: do not modify /etc/hosts before user agreement

[Martin Basti]

On 09/03/2015 03:31 PM, David Kupka wrote:

On 02/09/15 14:12, Martin Basti wrote:

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

This also fixes: https://fedorahosted.org/freeipa/ticket/5266

Patch attached.



Looks good an works for me, ACK.


Pushed to ipa-4-2: af10e865f7c60e19f6f487968a3ba7018c98a325
Pushed to master: 0bcf0c1be9be99a0301051eef048fac9b178f735

--
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] [PATCHES 362-366] Realmdomains handling improvements

[Alexander Bokovoy]

On Thu, 03 Sep 2015, Tomas Babej wrote:

Hi,

this couple of patches fix https://fedorahosted.org/freeipa/ticket/5278
and improve our handling of realmdomains in general.

The code looks good to me. I haven't tested it yet, though.

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

[Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal

[Alexander Bokovoy]

Hi,

attached patch adds support for issuing client referrals when FreeIPA
KDC is asked to give a TGT for a principal from a trusted forest.

We return a matching forest name as a realm and KDC then returns an
error pointing a client to a direction of that realm. You can see how it
looks with http://fpaste.org/263064/14412849/ -- it shows behavior for
both 'kinit -E -C' and 'kinit -E'.

Note that current MIT Kerberos KDC has a bug that prevents us from
responding with a correct client referral. A patched version for Fedora
22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is
https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs to
Fedora and RHEL versions.

With the version in my abbra/krb5-test COPR you can test the patch with
the help of kinit like fpaste URL above shows.


--
/ Alexander Bokovoy
From 22cdeeb87e82b13d518c1514a5a4feb84c5a6e16 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 20 Aug 2015 15:06:12 +0300
Subject: [PATCH] client referral support for trusted domain principals

https://fedorahosted.org/freeipa/ticket/3559
---
 daemons/ipa-kdb/ipa_kdb.h|  8 +
 daemons/ipa-kdb/ipa_kdb_mspac.c  | 60 
 daemons/ipa-kdb/ipa_kdb_principals.c | 47 
 3 files changed, 115 insertions(+)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 4abb733..a6f4481 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -274,6 +274,14 @@ krb5_error_code ipadb_check_transited_realms(krb5_context 
kcontext,
 const krb5_data *tr_contents,
 const krb5_data *client_realm,
 const krb5_data *server_realm);
+/* Checks whether a principal's realm is one of trusted domains' realm or 
NetBIOS name
+ * and returns the realm of the matched trusted domain in 'trusted_domain'
+ * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise
+ * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */
+krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext,
+  const char *test_realm, 
size_t size,
+  char **trusted_realm);
+
 /* DELEGATION CHECKS */
 
 krb5_error_code ipadb_check_allowed_to_delegate(krb5_context kcontext,
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 3c0dca8..8594309 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2790,3 +2790,63 @@ krb5_error_code 
ipadb_check_transited_realms(krb5_context kcontext,
}
return ret;
 }
+
+/* Checks whether a principal's realm is one of trusted domains' realm or 
NetBIOS name
+ * and returns the realm of the matched trusted domain in 'trusted_domain'
+ * Returns 0 in case of success and KRB5_KDB_NOENTRY otherwise
+ * If DAL driver is not initialized, returns KRB5_KDB_DBNOTINITED */
+krb5_error_code ipadb_is_princ_from_trusted_realm(krb5_context kcontext,
+ const char *test_realm, 
size_t size,
+ char **trusted_realm)
+{
+   struct ipadb_context *ipactx;
+   int i, j, length;
+   const char *name;
+
+   if (test_realm == NULL || test_realm[0] == '\0') {
+   return KRB5_KDB_NOENTRY;
+   }
+
+   ipactx = ipadb_get_context(kcontext);
+   if (!ipactx || !ipactx->mspac) {
+   return KRB5_KDB_DBNOTINITED;
+   }
+
+   /* First, compare realm with ours, it would not be from a trusted realm 
then */
+   if (strncasecmp(test_realm, ipactx->realm, size) == 0) {
+   return KRB5_KDB_NOENTRY;
+   }
+
+   if (!ipactx->mspac || !ipactx->mspac->trusts) {
+   return KRB5_KDB_NOENTRY;
+   }
+
+   /* Iterate through list of trusts and check if input realm belongs to 
any of the trust */
+   for(i = 0 ; i < ipactx->mspac->num_trusts ; i++) {
+   if ((strncasecmp(test_realm,
+ipactx->mspac->trusts[i].domain_name,
+size) == 0) ||
+   (strncasecmp(test_realm,
+ipactx->mspac->trusts[i].flat_name,
+size) == 0)) {
+   /* return the realm if caller supplied a place for it */
+   if (trusted_realm != NULL) {
+   name = (ipactx->mspac->trusts[i].parent_name != 
NULL) ?
+   ipactx->mspac->trusts[i].parent_name :
+   ipactx->mspac->trusts[i].domain_name;
+   length = strlen(name) + 1;
+   *trusted_realm = calloc(1, length);
+

Re: [Freeipa-devel] [PATCH 0057] DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5

[Martin Basti]

On 09/03/2015 05:41 PM, Martin Basti wrote:



On 09/01/2015 06:16 PM, Petr Spacek wrote:

Hello,

DNSSEC: Wrap master key using RSA OAEP instead of old PKCS v1.5.

This fixes an forgotten TODO in ipa-ods-exporter.



ACK


Pushed to:
master: ecf796e9c021a3b06e670f0602e8a10dcfd6f1f1
ipa-4-2: 5ad806ecf89f1aa4119398e65dff4e986b19b1a6

--
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 0053-0056] DNSSEC: Fix deadlocks & export to LDAP

[Martin Basti]

On 09/03/2015 05:44 PM, Martin Basti wrote:



On 09/03/2015 10:40 AM, Oleg Fayans wrote:

NACK from me.

2 out of 5 tests still fail with assertion errors:
https://paste.fedoraproject.org/262926/44126948/

Although, I am not sure these failures are caused by the same very 
problem.


On 08/31/2015 06:50 PM, Petr Spacek wrote:

Hello,

Attached patch set should fix the deadlock you discovered + few more 
issues I

spotted when testing the original patch.

Known problems (more patches needed):
- /etc/opendnssec/zonelist.xml should be restored during server 
uninstall

- ccache for ipa-ods-exporter should be removed during server uninstall
- timestamps in .private key files do not reflect (?) current key 
state in

OpenDNSSEC database (I will look into this tomorrow.)







Actually, I did testing and these patches fixing the deadlock.

ACK from me.

You may hit another issue, which is reproducible only by DNSSEC CI test:
named is not able to read keys (we don't know why, because keys are 
ready and readable)

Workaround is just to restart named, and everything will work.


Pushed to:
master: e84006117637832f63904edeb45b7296151be6ad
ipa-4-2: 73058caa625e5e966beff9122cf235cb45d6b0bc

--
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] [PATCHES 481-486] Metaclass and str modernization

[Petr Viktorin]

On 09/01/2015 04:47 PM, Jan Cholasta wrote:
> Hi,
> 
> the attached patches add some more modernization to our code.
> 
> Honza

481: ACK
482: ACK
483: ACK

You can push these without waiting on the later ones.


484:
To avoid merge conflicts later, perhaps it would be better to have

if six.PY3:
unicode = str

at the start of each affected file, instead of scattering changes in the
files?
(I can prepare the patch if you agree)


485:
six.binary_type is named "bytes" since Python 2.6. I think it would be
better to use that, to avoid another change when py2 is dropped.
(I can prepare the patch here, too)


486: ACK

-- 
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 0305-0306] DNSSEC: better cleanup after uninstall to avoid temporal malfunction

[Martin Basti]

On 09/03/2015 05:36 PM, Petr Spacek wrote:

On 2.9.2015 14:58, Martin Basti wrote:

Related to ticket  https://fedorahosted.org/freeipa/ticket/5273

Patches attached.

ACK


Pushed to master: e7a876d88a0ed07de69d9654ebdbf8ebb7bda364
Pushed to ipa-4-2: 8767fff853a68389ed6786abf0b0eea3f4ef6764

--
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 0309-0310] DNSSEC CI: extend DNSSEC CI tests

[Martin Basti]

Attached patches improve DNSSEC CI tests.


From b6271dfde300835e21b815a809a32c46dd46f3dc Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Tue, 1 Sep 2015 12:07:13 +0200
Subject: [PATCH 1/2] DNSSEC: improve CI test

Test disabling and re-enabling zone signing.
---
 ipatests/test_integration/test_dnssec.py | 113 +--
 1 file changed, 109 insertions(+), 4 deletions(-)

diff --git a/ipatests/test_integration/test_dnssec.py b/ipatests/test_integration/test_dnssec.py
index 74dc1be25476353e676f2601ace673212234df63..35b7652786b122ab6d2b5b137deefde9a8c647af 100644
--- a/ipatests/test_integration/test_dnssec.py
+++ b/ipatests/test_integration/test_dnssec.py
@@ -30,13 +30,17 @@ def resolve_with_dnssec(nameserver, query, log, rtype="SOA"):
 ans = res.query(query, rtype)
 return ans
 
+def get_RRSIG_record(nameserver, query, log, rtype="SOA"):
+ans = resolve_with_dnssec(nameserver, query, log, rtype=rtype)
+return ans.response.find_rrset(
+ans.response.answer, dns.name.from_text(query),
+dns.rdataclass.IN, dns.rdatatype.RRSIG,
+dns.rdatatype.from_text(rtype))
+
 
 def is_record_signed(nameserver, query, log, rtype="SOA"):
 try:
-ans = resolve_with_dnssec(nameserver, query, log, rtype=rtype)
-ans.response.find_rrset(ans.response.answer, dns.name.from_text(query),
-dns.rdataclass.IN, dns.rdatatype.RRSIG,
-dns.rdatatype.from_text(rtype))
+get_RRSIG_record(nameserver, query, log, rtype=rtype)
 except KeyError:
 return False
 except dns.exception.DNSException:
@@ -130,6 +134,103 @@ class TestInstallDNSSECLast(IntegrationTest):
 self.master.ip, test_zone_repl, self.log, timeout=5
 ), "DNS zone %s is not signed (master)" % test_zone
 
+def test_disable_reenable_signing_master(self):
+
+dnskey_old = resolve_with_dnssec(self.master.ip, test_zone,
+ self.log, rtype="DNSKEY").rrset
+
+# disable DNSSEC signing of zone on master
+args = [
+"ipa",
+"dnszone-mod", test_zone,
+"--dnssec", "false",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert not is_record_signed(
+self.master.ip, test_zone, self.log
+), "Zone %s is still signed (master)" % test_zone
+
+# test replica
+assert not is_record_signed(
+self.replicas[0].ip, test_zone, self.log
+), "DNS zone %s is still signed (replica)" % test_zone
+
+# reenable DNSSEC signing
+args = [
+"ipa",
+"dnszone-mod", test_zone,
+"--dnssec", "true",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert wait_until_record_is_signed(
+self.master.ip, test_zone, self.log, timeout=100
+), "Zone %s is not signed (master)" % test_zone
+
+# test replica
+assert wait_until_record_is_signed(
+self.replicas[0].ip, test_zone, self.log, timeout=200
+), "DNS zone %s is not signed (replica)" % test_zone
+
+dnskey_new = resolve_with_dnssec(self.master.ip, test_zone,
+ self.log, rtype="DNSKEY").rrset
+assert dnskey_old != dnskey_new, "RRSIG should be different"
+
+def test_disable_reenable_signing_replica(self):
+
+dnskey_old = resolve_with_dnssec(self.replicas[0].ip, test_zone_repl,
+ self.log, rtype="DNSKEY").rrset
+
+# disable DNSSEC signing of zone on replica
+args = [
+"ipa",
+"dnszone-mod", test_zone_repl,
+"--dnssec", "false",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert not is_record_signed(
+self.master.ip, test_zone_repl, self.log
+), "Zone %s is still signed (master)" % test_zone_repl
+
+# test replica
+assert not is_record_signed(
+self.replicas[0].ip, test_zone_repl, self.log
+), "DNS zone %s is still signed (replica)" % test_zone_repl
+
+# reenable DNSSEC signing
+args = [
+"ipa",
+"dnszone-mod", test_zone_repl,
+"--dnssec", "true",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert wait_until_record_is_signed(
+self.master.ip, test_zone_repl, self.log, timeout=100
+), "Zone %s is not signed (master)" % test_zone_repl
+
+# test replica
+assert 

Re: [Freeipa-devel] [PATCH 0052] Add Chromium configuration note under Chrome section in ssbrowser

[Gabe Alford]

Bump for review

On Wed, Jul 29, 2015 at 7:49 AM, Gabe Alford  wrote:

> Hello,
>
> As Chromium and Chrome are configured similarly but are configured in
> different /etc directories, this patch adds a note to the Chrome section in
> ssbrowser.html stating that.
>
> Thanks,
>
> Gabe
>
-- 
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 0309-0310] DNSSEC CI: extend DNSSEC CI tests

[Oleg Fayans]

Hi Martin,

The two functions
test_disable_reenable_signing_master and
test_disable_reenable_signing_replica
the error message for the laste assertion is different, although the 
assertions are identical:

"RRSIG should be different" and "DNSKEY should be different".
Other than that, it's fine


On 09/03/2015 05:55 PM, Martin Basti wrote:

Attached patches improve DNSSEC CI tests.




--
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] [PATCH] Updated no of legacy permission in ipatests

[Abhijeet Kasurde]

Ping

On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote:

Hi All,

This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264

Thanks,
Abhijeet Kasurde


--
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 0053-0056] DNSSEC: Fix deadlocks & export to LDAP

[Oleg Fayans]

NACK from me.

2 out of 5 tests still fail with assertion errors:
https://paste.fedoraproject.org/262926/44126948/

Although, I am not sure these failures are caused by the same very problem.

On 08/31/2015 06:50 PM, Petr Spacek wrote:

Hello,

Attached patch set should fix the deadlock you discovered + few more issues I
spotted when testing the original patch.

Known problems (more patches needed):
- /etc/opendnssec/zonelist.xml should be restored during server uninstall
- ccache for ipa-ods-exporter should be removed during server uninstall
- timestamps in .private key files do not reflect (?) current key state in
OpenDNSSEC database (I will look into this tomorrow.)





--
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] [PATCHSET] Replica promotion patches

[Martin Basti]

On 09/02/2015 10:37 PM, Simo Sorce wrote:

On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:

On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:

On 08/26/2015 11:27 PM, Simo Sorce wrote:

This patchset implements https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to install
kra instances and the ability to install a CA (via ipa-ca-install) with
externally signed certs.

However it is massive enough that warrants review and pushing, the resat
of the changes can be applied later as this work should not disrupt the
classic install methods.

In order to build my previous patches (530-533) are needed as well as a
number of updated components.

I used the following coprs for testing:
simo/jwcrypto
simo/custodia
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 > 1.3.4.4)
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in replicas,
eventually his patches should be committed in 389-ds-base 1.3.4.4 when
it will be released.

We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a
replica).

The domain must be raised to level 1 in order to use replica promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca


These patches are also available in this git tree rebnase on current
master:
https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review

Simo.




I'm running in a issue when upgrading RPMs:

2015-08-31T10:53:32Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
 return_value = self.run()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 48, in run
 server.upgrade()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1596, in upgrade
 upgrade_configuration()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1508, in upgrade_configuration
 custodia.upgrade_instance()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line
57, in upgrade_instance
 self.__gen_keys()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line
51, in __gen_keys
 KeyStore.generate_server_keys()
   File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
generate_server_keys
 ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
   File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
set_key
 conn.modify_s(dn, mods)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
364, in modify_s
 return self.result(msgid,all=1,timeout=self.timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
465, in result
 resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
469, in result2
 resp_type, resp_data, resp_msgid, resp_ctrls =
self.result3(msgid,all,timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
476, in result3
 resp_ctrl_classes=resp_ctrl_classes
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
483, in result4
 ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
106, in _ldap_call
 result = func(*args,**kwargs)

2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed,
exception: NO_SUCH_OBJECT: {'desc': 'No such object'}
2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT
No such object

Have you found out what this was about ?

I just found a different probelm affecting ipa-server-upgrade on my
master, it tracebacks trying to update the schema, which is odd:

2015-09-02T19:06:39Z DEBUG   [5/8]: updating schema
2015-09-02T19:06:39Z DEBUG flushing 
ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache
2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache 
url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket 
conn=
2015-09-02T19:06:40Z DEBUG Processing schema LDIF file 
/usr/share/ipa/60kerberos.ldif
2015-09-02T19:06:40Z DEBUG Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
417, in start_creation
 run_step(full_msg, method)
   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", 

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

[Oleg Fayans]

I've encountered this today too. Filed a ticket about it:

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

On 09/03/2015 10:57 AM, Martin Basti wrote:



On 09/02/2015 10:37 PM, Simo Sorce wrote:

On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:

On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:

On 08/26/2015 11:27 PM, Simo Sorce wrote:

This patchset implements https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to
achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to install
kra instances and the ability to install a CA (via ipa-ca-install)
with
externally signed certs.

However it is massive enough that warrants review and pushing, the
resat
of the changes can be applied later as this work should not disrupt
the
classic install methods.

In order to build my previous patches (530-533) are needed as well
as a
number of updated components.

I used the following coprs for testing:
simo/jwcrypto
simo/custodia
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 > 1.3.4.4)
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in
replicas,
eventually his patches should be committed in 389-ds-base 1.3.4.4 when
it will be released.

We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a
replica).

The domain must be raised to level 1 in order to use replica
promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca


These patches are also available in this git tree rebnase on current
master:
https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review


Simo.




I'm running in a issue when upgrading RPMs:

2015-08-31T10:53:32Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
 return_value = self.run()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",

line 48, in run
 server.upgrade()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1596, in upgrade
 upgrade_configuration()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1508, in upgrade_configuration
 custodia.upgrade_instance()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py",
line
57, in upgrade_instance
 self.__gen_keys()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py",
line
51, in __gen_keys
 KeyStore.generate_server_keys()
   File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
generate_server_keys
 ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
   File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
set_key
 conn.modify_s(dn, mods)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
364, in modify_s
 return self.result(msgid,all=1,timeout=self.timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
465, in result
 resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
469, in result2
 resp_type, resp_data, resp_msgid, resp_ctrls =
self.result3(msgid,all,timeout)
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
476, in result3
 resp_ctrl_classes=resp_ctrl_classes
   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
483, in result4
 ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)

   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
106, in _ldap_call
 result = func(*args,**kwargs)

2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed,
exception: NO_SUCH_OBJECT: {'desc': 'No such object'}
2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT
No such object

Have you found out what this was about ?

I just found a different probelm affecting ipa-server-upgrade on my
master, it tracebacks trying to update the schema, which is odd:

2015-09-02T19:06:39Z DEBUG   [5/8]: updating schema
2015-09-02T19:06:39Z DEBUG flushing
ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache
2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket
conn=
2015-09-02T19:06:40Z DEBUG Processing schema LDIF file
/usr/share/ipa/60kerberos.ldif
2015-09-02T19:06:40Z DEBUG Traceback (most recent call last):
   File

Re: [Freeipa-devel] [PATCH 0307] Server Install: print message that client is being installed

[Martin Basti]

On 09/02/2015 06:00 PM, Simo Sorce wrote:

On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote:

Client installation is done as "Restarting web server". This step
deserve own message.

Patch attached

I've seen various cases like this. And I can't understand why these
steps aren't embedded in the actual instance install steps that need the
restart (which implicitly also provide a message).

In the promotion patchset I did move steps like this into the proper
instances, so I would prefer you do the same with the install path as
that is more appropriate.

Simo.



We need restart httpd after CA, DNS(optional) installation, so thats why 
it is outside of httpd instance.


Client install has no own step yet, it is just call of ipa-client-install.

Martin^2

--
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 0004] Rewrap errors in get_principal to CCacheError

[Michael Šimáček]

After porting to gssapi, the ipa command prints ugly traceback when 
kerberos credentials are not available. Rewrapping to CCacheError when 
getting the principal name results in nicer error message.


https://fedorahosted.org/freeipa/ticket/5272
From 227df758d0ac0cfc971a39e63c33bc4bfc0e992b Mon Sep 17 00:00:00 2001
From: Michael Simacek 
Date: Mon, 31 Aug 2015 14:04:33 +0200
Subject: [PATCH] Rewrap errors in get_principal to CCacheError

Causes nicer error message when kerberos credentials are not available.

https://fedorahosted.org/freeipa/ticket/5272
---
 install/tools/ipa-adtrust-install |  2 +-
 ipalib/krb_utils.py   | 10 --
 ipalib/rpc.py |  6 --
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install
index 9ff1ac9be24a9f16f59ebe8dd46b2ff0d27b06aa..92c6ef3bda16de8e45a2a12011181541bbb0672c 100755
--- a/install/tools/ipa-adtrust-install
+++ b/install/tools/ipa-adtrust-install
@@ -306,7 +306,7 @@ def main():
 
 try:
 principal = krb_utils.get_principal()
-except gssapi.exceptions.GSSError as e:
+except errors.CCacheError as e:
 sys.exit("Must have Kerberos credentials to setup AD trusts on server: %s" % e.message)
 
 try:
diff --git a/ipalib/krb_utils.py b/ipalib/krb_utils.py
index db1cffc1e32a2e50fba64897ff1eba005f90fdc3..71348e8c895e963cca72b0e7267188a36b595399 100644
--- a/ipalib/krb_utils.py
+++ b/ipalib/krb_utils.py
@@ -168,9 +168,15 @@ def get_principal(ccache_name=None):
 default
 :returns:
   Default principal name as string
+:raises:
+  errors.CCacheError if the principal cannot be retrieved from given
+  ccache
 '''
-creds = get_credentials(ccache_name=ccache_name)
-return unicode(creds.name)
+try:
+creds = get_credentials(ccache_name=ccache_name)
+return unicode(creds.name)
+except gssapi.exceptions.GSSError as e:
+raise errors.CCacheError(str(e))
 
 def get_credentials_if_valid(name=None, ccache_name=None):
 '''
diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index dcbfafe0567d653273fccb96d31d4c407fdf256c..a3580453fa4631f5e8c90591cdf6ea31b3a356ff 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -67,7 +67,7 @@ import ipapython.nsslib
 from ipapython.nsslib import NSSHTTPS, NSSConnection
 from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT_EXPIRED, \
  KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, \
- KRB5_REALM_CANT_RESOLVE, get_principal
+ KRB5_REALM_CANT_RESOLVE, KRB5_CC_NOTFOUND, get_principal
 from ipapython.dn import DN
 from ipalib.capabilities import VERSION_WITHOUT_CAPABILITIES
 from ipalib import api
@@ -532,6 +532,8 @@ class KerbTransport(SSLTransport):
 raise errors.BadCCacheFormat()
 elif minor == KRB5_REALM_CANT_RESOLVE:
 raise errors.CannotResolveKDC()
+elif minor == KRB5_CC_NOTFOUND:
+raise errors.CCacheError()
 else:
 raise errors.KerberosError(major=e.maj_code, minor=minor)
 
@@ -839,7 +841,7 @@ class RPCClient(Connectible):
 # is still valid
 if not delegate:
 rpc_uri = self.apply_session_cookie(rpc_uri)
-except ValueError:
+except (errors.CCacheError, ValueError):
 # No session key, do full Kerberos auth
 pass
 # This might be dangerous. Use at your own risk!
-- 
2.1.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] [PATCH 0308] Server Upgrade: fix traceback caused by cidict

[Martin Basti]

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

Patch attached.
From 6afdb8a8bfe5dba3dc117c8ed15e0d90e2d63ce2 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 3 Sep 2015 12:55:05 +0200
Subject: [PATCH] Server Upgrade: fix traceback caused by cidict

Traceback caused by recent py3 code migration.

https://fedorahosted.org/freeipa/ticket/5283
---
 ipaserver/install/schemaupdate.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/install/schemaupdate.py b/ipaserver/install/schemaupdate.py
index 432c44d42b14b0699142f3e32316942cc50d86f3..b3d7ee899df8151f4bfd6664b7961dc8b7df730b 100644
--- a/ipaserver/install/schemaupdate.py
+++ b/ipaserver/install/schemaupdate.py
@@ -56,7 +56,7 @@ def _get_oid_dependency_order(schema, cls):
 # remove top_node from tree, it breaks ordering
 # we don't need this, tree from file is not consistent
 del tree[top_node]
-unordered_oids = set(tree)
+unordered_oids = set(tree.keys())
 
 # split into two groups, parents and child nodes, and iterate until
 # child nodes are not empty
-- 
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] cert profiles - test plan + patches

[Lenka Doudova]

Hi,

I took a look at it at Milan's request.

patch 0008 - tracker looks ok, ACK
patch 0009 - test cases look ok as well, but can't get it to run, 10 out 
of 14 tests fail, starting with internal error, which I haven't been 
able to track down, nor fix it.


Lenka

=== FAILURES 
===
 TestProfileCRUD.test_create_duplicate 
_


self = object at 0x7f36459e7110>
user_profile = 
at 0x7f36459e73d0>


def test_create_duplicate(self, user_profile):
msg = u'Certificate Profile with name "{}" already exists'
>   user_profile.ensure_exists()

ipatests/test_xmlrpc/test_certprofile_plugin.py:178:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists
self.create(force=True)
ipatests/test_xmlrpc/ldaptracker.py:206: in create
result = command()
ipatests/test_xmlrpc/ldaptracker.py:127: in run_command
result = cmd(*args, **options)
ipalib/frontend.py:443: in __call__
ret = self.run(*args, **options)
ipalib/frontend.py:761: in run
return self.forward(*args, **options)
ipalib/frontend.py:782: in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
ipalib/rpc.py:947: in forward
return self._call_command(command, params)
ipalib/rpc.py:924: in _call_command
return command(*params)
ipalib/rpc.py:1075: in _call
return self.__request(name, args)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


self = 
name = 'certprofile_import'
args = (('caIPAserviceCert_mod',), {'all': False, 'description': 
'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion Default

policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
', 'ipacertprofilestoreissued': True, ...})

def __request(self, name, args):
payload = {'method': unicode(name), 'params': args, 'id': 0}
version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES)
payload = json_encode_binary(payload, version)

if self.__verbose >= 2:
root_logger.info('Request: %s',
 json.dumps(payload, sort_keys=True, indent=4))

response = self.__transport.request(
self.__host,
self.__handler,
json.dumps(payload),
verbose=self.__verbose >= 3,
)

try:
response = json_decode_binary(json.loads(response))
except ValueError as e:
raise JSONError(str(e))

if self.__verbose >= 2:
root_logger.info(
'Response: %s',
json.dumps(json_encode_binary(response, version),
   sort_keys=True, indent=4)
)
error = response.get('error')
if error:
try:
error_class = errors_by_code[error['code']]
except KeyError:
raise UnknownError(
code=error.get('code'),
error=error.get('message'),
server=self.__host,
)
else:
>   raise error_class(message=error['message'])
E   InternalError: an internal error has occurred




On 08/31/2015 03:25 PM, Fraser Tweedale wrote:

On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote:


On 08/18/2015 04:06 PM, Milan Kubík wrote:

On 08/11/2015 03:17 AM, Fraser Tweedale wrote:

On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kubík wrote:

On 08/05/2015 02:57 PM, Milan Kubík wrote:

Hi list,

I'm sending the test plan [1] for certificate profiles and preliminary
patches for it.
The plan covers basic CRUD test and some corner cases. I'm open to
more
suggestions.

More complicated tests involving certificate profiles will require the
code (and tests)
for CA ACLs merged, so it's not there at the moment.

There are some unfinished test cases in places I wasn't sure what the
result should be.
We need to iterate through these to fix it.


[1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan

Cheers,
Milan

Hi all,

have you had some time to look at the code and proposal?
Today I want to write a basic CRUD test for the ACLs as well as a few
test
cases to check if the ACL is being enforced. It should make it into
wiki
today or by tomorrow. I'll send an update then.

Cheers,
Milan


Hi Milan,

I have reviewed the V4/Certificate_Profiles/Test_Plan.  Couple of
comments:

- Test case: Import profile with incorrect values
   - Expected result: refused with error.
   - A simple way to provoke this condition is to add a number to
 ``policyset.serverCertSet.list``.
   - A similar test case should exist for certprofile-mod.

- Test case: Delete default profile
   - As discussed elsewhere, expected result should be failure.
 I filed ticket #5198 to make it so :)

I will review the patch soon.

Cheers,
Fraser

Hello,

how is the review 

Re: [Freeipa-devel] [PATCH 0308] Server Upgrade: fix traceback caused by cidict

[Petr Viktorin]

On 09/03/2015 01:01 PM, Martin Basti wrote:
> https://fedorahosted.org/freeipa/ticket/5283
> 
> Patch attached.

ACK.


This was caused by commit 3bf91ea, specifically the rushed reaction to
Christian's comment:
> Please use sorted(reference) instead of sorted(reference.keys()),
> set(tree) instead of set(tree.keys()) and list(somedict) instead of
> list(somedict.keys()), too. The keys() call is unnecessary and frowned upon.

Turns out python-ldap's cidict is not a propper Mapping, so the keys()
call *is* necessary.
Sorry for missing that.


-- 
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 0308] Server Upgrade: fix traceback caused by cidict

[Martin Basti]

On 09/03/2015 01:42 PM, Petr Viktorin wrote:

On 09/03/2015 01:01 PM, Martin Basti wrote:

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

Patch attached.

ACK.


This was caused by commit 3bf91ea, specifically the rushed reaction to
Christian's comment:

Please use sorted(reference) instead of sorted(reference.keys()),
set(tree) instead of set(tree.keys()) and list(somedict) instead of
list(somedict.keys()), too. The keys() call is unnecessary and frowned upon.

Turns out python-ldap's cidict is not a propper Mapping, so the keys()
call *is* necessary.
Sorry for missing that.



Pushed to master: 0c5e41cc79f75e12094773cdf5a296dd06052763

--
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] 916 vault: add vault container commands

[Jan Cholasta]

On 2.9.2015 07:26, Endi Sukma Dewata wrote:

On 9/1/2015 10:22 AM, Simo Sorce wrote:

On Tue, 2015-09-01 at 17:15 +0200, Petr Vobornik wrote:

On 09/01/2015 04:39 PM, Jan Cholasta wrote:

On 1.9.2015 16:26, Jan Cholasta wrote:

On 26.8.2015 13:22, Petr Vobornik wrote:

On 08/25/2015 08:04 PM, Petr Vobornik wrote:

adds commands:
* vaultcontainer-show [--service |--user  ]
* vaultcontainer-add-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]
* vaultcontainer-remove-owner
   [--service |--user  ]
   [--users ]  [--groups ] [--services
]

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

Use cases:
1. When user/service is deleted, associated vault container looses
owner. There was no API command to set the owner.
2. Change owner of container by admin to manage access.

Show command was added to show current owners.

Find command was not added, should it be?




There is also a design for vault container ownership handling
created by
Endi - it's for future Vault 2.0.

http://www.freeipa.org/page/V4/Password_Vault_2.0#Adding_container_owner


This patch has a different API than the proposed - different way of
specifying the container. The design page uses path e.g.
/users/foobar.
This patch uses the same way as vaults e.g. --user=foobar. This means
that the implementation in this patch cannot manage ownership of
parent
vault containers e.g. cn=users,cn=vaults,cn=kra,$SUFFIX.

Do we want to go with this approach in 4.2?

Attaching also new path which removes setting of owner which doesn't
exist so that integrity is OK and that it is consistent with
removing of
user.

Updated patch attached - output fix.


We had a long discussion about this with Petr and we think the best
approach is as follows:

* Add new "Vault administrators" privilege. Vault
administrators will
have unrestricted access to vaults and vault containers, including the
power to add/remove owners of vaults and vault containers.

* Remove the ability of vault owners to add/remove other vault
owners. If vault owner needs to be changed, vault administrator has to
do it. Note that vault owners will still have the ability to
add/remove
vault members.

* When adding new vault container, set owner to the current
user. If
vault container owner needs to be changed, vault administrator has
to do
it.

* Allow adding vaults and vault containers only if the owner is
set
to the current user.

* Introduce commands to modify vault container owner and to delete
vault container, so the administrator has a choice between assigning
ownership or deleting an unowned container.


Also:

* Control access to vault data using an ipaProtectedOperation ACI.
Users which have read access to "ipaProtectedOperation;accessKRA" on a
vault can retrieve data from the vault and users which have write
access
to "ipaProtectedOperation;accessKRA" on a vault can archive data in the
vault.

Honza



+1

CCing Simo and Endi to check the proposal.

And Scott (related to #5216, #5215)


Sounds reasonable to me.
I can see that allowing owners to hand over vaults w/o admin
intervention may have some appeal in some use cases, but I also see it
can bring downsides with it, so all in all I think I agree with the
above points.

Simo.



Not a total objection, but if many people in unrelated groups are using
vaults, and they are sharing the vaults only with members of each group,
having to ask a Vault Administrator for each ownership change sounds a
bit cumbersome. Since the Vault Adminstrator will have access to all
vaults in all groups, only a small number of people can be trusted to
hold that role. If there are many ownership changes the Vault
Administrator will have to handle all those requests, and the vault
users may have to wait until the change is completed.

If owners are allowed to add others as owners, the vaults will be pretty
much maintenance free to the admin.


Owners can still manage members, which is IMO good enough for sharing a 
vault with other users.




Regardless, please update the wiki page to describe the new behavior
when it's implemented:
http://www.freeipa.org/page/V4/Password_Vault_1.1


Sure.

I have updated and rebased Petr's patch 916.

Patch 488 obsoletes Petr's patch 918.

Patch for vault data access control is not included, because I was not 
able to make GER work correctly with "ipaProtectedOperation;accessKRA".


--
Jan Cholasta
From d9a3cfa7cfcf4402f5d83a61d2a7745a71d8cca3 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Tue, 25 Aug 2015 19:56:00 +0200
Subject: [PATCH 1/4] vault: add vault container commands

adds commands:
* vaultcontainer-show [--service |--user |--shared ]
* vaultcontainer-del [--service |--user |--shared ]
* vaultcontainer-add-owner
 [--service |--user |--shared ]
 [--users ]  [--groups ] [--services ]
* vaultcontainer-remove-owner
 [--service |--user |--shared ]
 [--users ]  [--groups ] [--services ]

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

[Martin Basti]

On 09/03/2015 02:57 PM, Simo Sorce wrote:

On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote:

On 09/02/2015 10:37 PM, Simo Sorce wrote:

On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:

On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:

On 08/26/2015 11:27 PM, Simo Sorce wrote:

This patchset implements https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to install
kra instances and the ability to install a CA (via ipa-ca-install) with
externally signed certs.

However it is massive enough that warrants review and pushing, the resat
of the changes can be applied later as this work should not disrupt the
classic install methods.

In order to build my previous patches (530-533) are needed as well as a
number of updated components.

I used the following coprs for testing:
simo/jwcrypto
simo/custodia
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 > 1.3.4.4)
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in replicas,
eventually his patches should be committed in 389-ds-base 1.3.4.4 when
it will be released.

We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a
replica).

The domain must be raised to level 1 in order to use replica promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca


These patches are also available in this git tree rebnase on current
master:
https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review

Simo.




I'm running in a issue when upgrading RPMs:

2015-08-31T10:53:32Z DEBUG   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
  return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
line 48, in run
  server.upgrade()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1596, in upgrade
  upgrade_configuration()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
line 1508, in upgrade_configuration
  custodia.upgrade_instance()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line
57, in upgrade_instance
  self.__gen_keys()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line
51, in __gen_keys
  KeyStore.generate_server_keys()
File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
generate_server_keys
  ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
set_key
  conn.modify_s(dn, mods)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
364, in modify_s
  return self.result(msgid,all=1,timeout=self.timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
465, in result
  resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
469, in result2
  resp_type, resp_data, resp_msgid, resp_ctrls =
self.result3(msgid,all,timeout)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
476, in result3
  resp_ctrl_classes=resp_ctrl_classes
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
483, in result4
  ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
106, in _ldap_call
  result = func(*args,**kwargs)

2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed,
exception: NO_SUCH_OBJECT: {'desc': 'No such object'}
2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT
No such object

Have you found out what this was about ?

I just found a different probelm affecting ipa-server-upgrade on my
master, it tracebacks trying to update the schema, which is odd:

2015-09-02T19:06:39Z DEBUG   [5/8]: updating schema
2015-09-02T19:06:39Z DEBUG flushing 
ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket from SchemaCache
2015-09-02T19:06:39Z DEBUG retrieving schema for SchemaCache 
url=ldapi://%2fvar%2frun%2fslapd-PROMO-LAN.socket 
conn=
2015-09-02T19:06:40Z DEBUG Processing schema LDIF file 
/usr/share/ipa/60kerberos.ldif
2015-09-02T19:06:40Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

[Simo Sorce]

On Thu, 2015-09-03 at 15:21 +0200, Martin Basti wrote:
> 
> On 09/03/2015 02:57 PM, Simo Sorce wrote:
> > On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote:
> >> On 09/02/2015 10:37 PM, Simo Sorce wrote:
> >>> On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:
>  On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:
> > On 08/26/2015 11:27 PM, Simo Sorce wrote:
> >> This patchset implements https://fedorahosted.org/freeipa/ticket/2888
> >> and introduces a number of required  changes and dependencies to 
> >> achieve
> >> this goal.
> >> This work requires the custodia project to securely transfer keys
> >> between ipa servers.
> >>
> >> This work is not 100% complete, it still misses the ability to install
> >> kra instances and the ability to install a CA (via ipa-ca-install) with
> >> externally signed certs.
> >>
> >> However it is massive enough that warrants review and pushing, the 
> >> resat
> >> of the changes can be applied later as this work should not disrupt the
> >> classic install methods.
> >>
> >> In order to build my previous patches (530-533) are needed as well as a
> >> number of updated components.
> >>
> >> I used the following coprs for testing:
> >> simo/jwcrypto
> >> simo/custodia
> >> abbra/sssd-kkdcproxy (for sssd 1.13.1)
> >> lkrispen/389-ds-current (for 389 > 1.3.4.4)
> >> vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
> >> mkosek/freeipa-4.2-fedora-22 (misc)
> >> fedora/updates-testing (python-gssapi 1.1.2)
> >>
> >> Ludwig's copr is necessary to have a functional DNA plugin in replicas,
> >> eventually his patches should be committed in 389-ds-base 1.3.4.4 when
> >> it will be released.
> >>
> >> We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
> >> that may cause installation issues in some case (re-install of a
> >> replica).
> >>
> >> The domain must be raised to level 1 in order to use replica promotion.
> >>
> >> In order to promote a replica the server must be first joined as a
> >> regular client to the domain.
> >>
> >> This is the flow I usually use for testing:
> >>
> >> # ipa-client-install
> >> # kinit admin
> >> # ipa-replica-install --promote --setup-ca
> >>  >> etc...>
> >>
> >> These patches are also available in this git tree rebnase on current
> >> master:
> >> https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review
> >>
> >> Simo.
> >>
> >>
> >>
> > I'm running in a issue when upgrading RPMs:
> >
> > 2015-08-31T10:53:32Z DEBUG   File
> > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> > execute
> >   return_value = self.run()
> > File
> > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
> > line 48, in run
> >   server.upgrade()
> > File
> > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> > line 1596, in upgrade
> >   upgrade_configuration()
> > File
> > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> > line 1508, in upgrade_configuration
> >   custodia.upgrade_instance()
> > File
> > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py",
> >  line
> > 57, in upgrade_instance
> >   self.__gen_keys()
> > File
> > "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py",
> >  line
> > 51, in __gen_keys
> >   KeyStore.generate_server_keys()
> > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
> > generate_server_keys
> >   ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
> > File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
> > set_key
> >   conn.modify_s(dn, mods)
> > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> > 364, in modify_s
> >   return self.result(msgid,all=1,timeout=self.timeout)
> > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> > 465, in result
> >   resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
> > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> > 469, in result2
> >   resp_type, resp_data, resp_msgid, resp_ctrls =
> > self.result3(msgid,all,timeout)
> > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> > 476, in result3
> >   resp_ctrl_classes=resp_ctrl_classes
> > File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> > 483, in result4
> >   ldap_result =
> > self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)

Re: [Freeipa-devel] [PATCH 0304] Installer: do not modify /etc/hosts before user agreement

[David Kupka]

On 02/09/15 14:12, Martin Basti wrote:

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

This also fixes: https://fedorahosted.org/freeipa/ticket/5266

Patch attached.



Looks good an 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] [PATCH 0307] Server Install: print message that client is being installed

[Martin Basti]

On 09/03/2015 02:42 PM, Simo Sorce wrote:

On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote:

On 09/02/2015 06:00 PM, Simo Sorce wrote:

On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote:

Client installation is done as "Restarting web server". This step
deserve own message.

Patch attached

I've seen various cases like this. And I can't understand why these
steps aren't embedded in the actual instance install steps that need the
restart (which implicitly also provide a message).

In the promotion patchset I did move steps like this into the proper
instances, so I would prefer you do the same with the install path as
that is more appropriate.

Simo.


We need restart httpd after CA, DNS(optional) installation, so thats why
it is outside of httpd instance.

You need to restart httpd always after CA install as it changes the
proxy settings, but why do you need to restart it after DNS
installation ?

It is needed due changes in resolv.conf


(I think it is fine to restart it twice if it is really needed after DNS
change).

IMO it is waste of time to restart httpd twice in one minute

Can we resolve this in 4.4, where might be place to finish improvements 
in installer? (If this is not blocking replica promotion)


Martin^2



Client install has no own step yet, it is just call of ipa-client-install.

This is fine, ipa-client-install is another ball of wax.

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] [PATCHSET] Replica promotion patches

[Simo Sorce]

On Thu, 2015-09-03 at 10:57 +0200, Martin Basti wrote:
> 
> On 09/02/2015 10:37 PM, Simo Sorce wrote:
> > On Wed, 2015-09-02 at 15:22 -0400, Simo Sorce wrote:
> >> On Mon, 2015-08-31 at 14:45 +0200, Tomas Babej wrote:
> >>> On 08/26/2015 11:27 PM, Simo Sorce wrote:
>  This patchset implements https://fedorahosted.org/freeipa/ticket/2888
>  and introduces a number of required  changes and dependencies to achieve
>  this goal.
>  This work requires the custodia project to securely transfer keys
>  between ipa servers.
> 
>  This work is not 100% complete, it still misses the ability to install
>  kra instances and the ability to install a CA (via ipa-ca-install) with
>  externally signed certs.
> 
>  However it is massive enough that warrants review and pushing, the resat
>  of the changes can be applied later as this work should not disrupt the
>  classic install methods.
> 
>  In order to build my previous patches (530-533) are needed as well as a
>  number of updated components.
> 
>  I used the following coprs for testing:
>  simo/jwcrypto
>  simo/custodia
>  abbra/sssd-kkdcproxy (for sssd 1.13.1)
>  lkrispen/389-ds-current (for 389 > 1.3.4.4)
>  vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
>  mkosek/freeipa-4.2-fedora-22 (misc)
>  fedora/updates-testing (python-gssapi 1.1.2)
> 
>  Ludwig's copr is necessary to have a functional DNA plugin in replicas,
>  eventually his patches should be committed in 389-ds-base 1.3.4.4 when
>  it will be released.
> 
>  We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
>  that may cause installation issues in some case (re-install of a
>  replica).
> 
>  The domain must be raised to level 1 in order to use replica promotion.
> 
>  In order to promote a replica the server must be first joined as a
>  regular client to the domain.
> 
>  This is the flow I usually use for testing:
> 
>  # ipa-client-install
>  # kinit admin
>  # ipa-replica-install --promote --setup-ca
>    etc...>
> 
>  These patches are also available in this git tree rebnase on current
>  master:
>  https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review
> 
>  Simo.
> 
> 
> 
> >>> I'm running in a issue when upgrading RPMs:
> >>>
> >>> 2015-08-31T10:53:32Z DEBUG   File
> >>> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
> >>> execute
> >>>  return_value = self.run()
> >>>File
> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py",
> >>> line 48, in run
> >>>  server.upgrade()
> >>>File
> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> >>> line 1596, in upgrade
> >>>  upgrade_configuration()
> >>>File
> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py",
> >>> line 1508, in upgrade_configuration
> >>>  custodia.upgrade_instance()
> >>>File
> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", 
> >>> line
> >>> 57, in upgrade_instance
> >>>  self.__gen_keys()
> >>>File
> >>> "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", 
> >>> line
> >>> 51, in __gen_keys
> >>>  KeyStore.generate_server_keys()
> >>>File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 181, in
> >>> generate_server_keys
> >>>  ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
> >>>File "/usr/lib/python2.7/site-packages/ipakeys/kem.py", line 127, in
> >>> set_key
> >>>  conn.modify_s(dn, mods)
> >>>File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> >>> 364, in modify_s
> >>>  return self.result(msgid,all=1,timeout=self.timeout)
> >>>File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> >>> 465, in result
> >>>  resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
> >>>File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> >>> 469, in result2
> >>>  resp_type, resp_data, resp_msgid, resp_ctrls =
> >>> self.result3(msgid,all,timeout)
> >>>File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> >>> 476, in result3
> >>>  resp_ctrl_classes=resp_ctrl_classes
> >>>File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> >>> 483, in result4
> >>>  ldap_result =
> >>> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
> >>>File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line
> >>> 106, in _ldap_call
> >>>  result = func(*args,**kwargs)
> >>>
> >>> 2015-08-31T10:53:32Z DEBUG The ipa-server-upgrade command failed,
> >>> exception: NO_SUCH_OBJECT: {'desc': 'No such object'}
> >>> 2015-08-31T10:53:32Z ERROR LDAP error: NO_SUCH_OBJECT
> >>> No such object
> >> 

[Freeipa-devel] [PATCHES 362-366] Realmdomains handling improvements

[Tomas Babej]

Hi,

this couple of patches fix https://fedorahosted.org/freeipa/ticket/5278
and improve our handling of realmdomains in general.

Tomas
From 7298b240843b5a86569b3e99cd793f42fd007acf Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 3 Sep 2015 12:13:32 +0200
Subject: [PATCH] util: Add detect_dns_zone_realm_type helper

https://fedorahosted.org/freeipa/ticket/5278
---
 ipalib/util.py | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/ipalib/util.py b/ipalib/util.py
index 5a761fb0f7ee6c0851d6f1128cecc4ddd8b397f2..23f36a63dd5747239102e6153b6c0c1e774daa59 100644
--- a/ipalib/util.py
+++ b/ipalib/util.py
@@ -799,3 +799,58 @@ def get_topology_connection_errors(graph):
 if not_visited:
 connect_errors.append((m, list(visited), list(not_visited)))
 return connect_errors
+
+def detect_dns_zone_realm_type(api, domain):
+"""
+Detects the type of the realm that the given DNS zone belongs to.
+Note: This method is heuristic. Possible values:
+  - 'current': For IPA domains belonging in the current realm.
+  - 'foreign': For domains belonging in a foreing kerberos realm.
+  - 'unknown': For domains whose allegiance could not be detected.
+"""
+
+# First, try to detect _kerberos TXT record in the domain
+# This would indicate that the domain belongs to IPA realm
+
+kerberos_prefix = DNSName('_kerberos')
+domain_suffix = DNSName(domain)
+kerberos_record_name = kerberos_prefix + domain_suffix
+
+response = None
+
+try:
+result = resolver.query(kerberos_record_name, rdatatype.TXT)
+answer = result.response.answer
+
+# IPA domain will have only one _kerberos TXT record
+if (len(answer) == 1 and
+len(answer[0]) == 1 and
+answer[0].rdtype == rdatatype.TXT):
+
+record = answer[0][0]
+
+# If the record contains our current realm, it is 'ipa-current'
+if record.to_text() == '"{0}"'.format(api.env.realm):
+return 'current'
+else:
+return 'foreign'
+
+except DNSException as e:
+pass
+
+# Try to detect AD specific record in the zone.
+# This would indicate that the domain belongs to foreign (AD) realm
+
+gc_prefix = DNSName('_ldap._tcp.gc._msdcs')
+ad_specific_record_name = gc_prefix + domain_suffix
+
+try:
+# The presence of this record is enough, return foreign in such case
+result = resolver.query(ad_specific_record_name, rdatatype.SRV)
+return 'foreign'
+
+except DNSException as e:
+pass
+
+# If we could not detect type with certainity, return unknown
+return 'unknown'
-- 
2.1.0

From cb6efd05e12b441f70385c7e8c5cdf605c173456 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 3 Sep 2015 12:40:17 +0200
Subject: [PATCH] realmdomains: Minor style and wording improvements

https://fedorahosted.org/freeipa/ticket/5278
---
 ipalib/plugins/realmdomains.py | 75 +-
 1 file changed, 60 insertions(+), 15 deletions(-)

diff --git a/ipalib/plugins/realmdomains.py b/ipalib/plugins/realmdomains.py
index 871ea79c4b6225919d2700420a56eebb816bc025..83c8abd76a220f365f751ec399e6b1535a8e575e 100644
--- a/ipalib/plugins/realmdomains.py
+++ b/ipalib/plugins/realmdomains.py
@@ -133,16 +133,46 @@ class realmdomains_mod(LDAPUpdate):
 del_domain = entry_attrs.get('del_domain')
 force = options.get('force')
 
+current_domain = get_domain_name()
+
+missing_soa_ns_record_error = _(
+"DNS zone for each realmdomain must contain "
+"SOA or NS records. No records found for: %s"
+)
+
+# User specified the list of domains explicitly
 if associateddomain:
 if add_domain or del_domain:
-raise errors.MutuallyExclusiveError(reason=_("you cannot specify the --domain option together with --add-domain or --del-domain"))
-if get_domain_name() not in associateddomain:
-raise errors.ValidationError(name='domain', error=_("cannot delete domain of IPA server"))
+raise errors.MutuallyExclusiveError(
+reason=_(
+"The --domain option cannot be used together "
+"with --add-domain or --del-domain. Use --domain "
+"to specify the whole realm domain list explicitly, "
+"to add/remove individual domains, use "
+"--add-domain/del-domain.")
+)
+
+# Make sure our domain is included in the list
+if current_domain not in associateddomain:
+raise errors.ValidationError(
+name='realmdomain list',
+error=_("IPA server domain cannot by omitted")
+)
+
+# 

Re: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError

[Tomas Babej]

On 09/03/2015 12:54 PM, Michael Šimáček wrote:
> After porting to gssapi, the ipa command prints ugly traceback when
> kerberos credentials are not available. Rewrapping to CCacheError when
> getting the principal name results in nicer error message.
> 
> https://fedorahosted.org/freeipa/ticket/5272
> 
> 

This fixes the issue, however, I am getting a trailing forward slash in
the error message:

$ ipa user-find
ipa: ERROR: Kerberos error: did not receive Kerberos credentials/

-- 
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] cert profiles - test plan + patches

[Tomas Babej]

On 09/03/2015 01:40 PM, Lenka Doudova wrote:
> Hi,
> 
> I took a look at it at Milan's request.
> 
> patch 0008 - tracker looks ok, ACK
> patch 0009 - test cases look ok as well, but can't get it to run, 10 out
> of 14 tests fail, starting with internal error, which I haven't been
> able to track down, nor fix it.

You can investigate the internal error by inspecting the
/var/log/httpd/error_log on the IPA server that executed the command.

There should be a traceback.

> 
> Lenka
> 
> === FAILURES
> ===
>  TestProfileCRUD.test_create_duplicate
> _
> 
> self =  object at 0x7f36459e7110>
> user_profile =
>  at 0x7f36459e73d0>
> 
> def test_create_duplicate(self, user_profile):
> msg = u'Certificate Profile with name "{}" already exists'
>>   user_profile.ensure_exists()
> 
> ipatests/test_xmlrpc/test_certprofile_plugin.py:178:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _
> ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists
> self.create(force=True)
> ipatests/test_xmlrpc/ldaptracker.py:206: in create
> result = command()
> ipatests/test_xmlrpc/ldaptracker.py:127: in run_command
> result = cmd(*args, **options)
> ipalib/frontend.py:443: in __call__
> ret = self.run(*args, **options)
> ipalib/frontend.py:761: in run
> return self.forward(*args, **options)
> ipalib/frontend.py:782: in forward
> return self.Backend.rpcclient.forward(self.name, *args, **kw)
> ipalib/rpc.py:947: in forward
> return self._call_command(command, params)
> ipalib/rpc.py:924: in _call_command
> return command(*params)
> ipalib/rpc.py:1075: in _call
> return self.__request(name, args)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _
> 
> self = 
> name = 'certprofile_import'
> args = (('caIPAserviceCert_mod',), {'all': False, 'description':
> 'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion Default
> policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
> ', 'ipacertprofilestoreissued': True, ...})
> 
> def __request(self, name, args):
> payload = {'method': unicode(name), 'params': args, 'id': 0}
> version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES)
> payload = json_encode_binary(payload, version)
>
> if self.__verbose >= 2:
> root_logger.info('Request: %s',
>  json.dumps(payload, sort_keys=True, indent=4))
>
> response = self.__transport.request(
> self.__host,
> self.__handler,
> json.dumps(payload),
> verbose=self.__verbose >= 3,
> )
>
> try:
> response = json_decode_binary(json.loads(response))
> except ValueError as e:
> raise JSONError(str(e))
>
> if self.__verbose >= 2:
> root_logger.info(
> 'Response: %s',
> json.dumps(json_encode_binary(response, version),
>sort_keys=True, indent=4)
> )
> error = response.get('error')
> if error:
> try:
> error_class = errors_by_code[error['code']]
> except KeyError:
> raise UnknownError(
> code=error.get('code'),
> error=error.get('message'),
> server=self.__host,
> )
> else:
>>   raise error_class(message=error['message'])
> E   InternalError: an internal error has occurred
> 
> 
> 
> 
> On 08/31/2015 03:25 PM, Fraser Tweedale wrote:
>> On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote:
>>>
>>> On 08/18/2015 04:06 PM, Milan Kubík wrote:
 On 08/11/2015 03:17 AM, Fraser Tweedale wrote:
> On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kubík wrote:
>> On 08/05/2015 02:57 PM, Milan Kubík wrote:
>>> Hi list,
>>>
>>> I'm sending the test plan [1] for certificate profiles and preliminary
>>> patches for it.
>>> The plan covers basic CRUD test and some corner cases. I'm open to
>>> more
>>> suggestions.
>>>
>>> More complicated tests involving certificate profiles will require the
>>> code (and tests)
>>> for CA ACLs merged, so it's not there at the moment.
>>>
>>> There are some unfinished test cases in places I wasn't sure what the
>>> result should be.
>>> We need to iterate through these to fix it.
>>>
>>>
>>> [1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan
>>>
>>> Cheers,
>>> Milan
>> Hi all,
>>
>> have you had some time to look at the code and proposal?
>> Today I want to write a basic CRUD test for the ACLs as well as a few
>> test
>> cases to check if the ACL is being enforced. It should make it into
>> 

Re: [Freeipa-devel] cert profiles - test plan + patches

[Martin Basti]

On 09/03/2015 01:40 PM, Lenka Doudova wrote:

Hi,

I took a look at it at Milan's request.

patch 0008 - tracker looks ok, ACK
patch 0009 - test cases look ok as well, but can't get it to run, 10 
out of 14 tests fail, starting with internal error, which I haven't 
been able to track down, nor fix it.


Can you check /var/log/httpr/errors_log what the internal error is?

Martin^2


Lenka

=== FAILURES 
===
 TestProfileCRUD.test_create_duplicate 
_


self = object at 0x7f36459e7110>
user_profile = 
object at 0x7f36459e73d0>


def test_create_duplicate(self, user_profile):
msg = u'Certificate Profile with name "{}" already exists'
>   user_profile.ensure_exists()

ipatests/test_xmlrpc/test_certprofile_plugin.py:178:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _

ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists
self.create(force=True)
ipatests/test_xmlrpc/ldaptracker.py:206: in create
result = command()
ipatests/test_xmlrpc/ldaptracker.py:127: in run_command
result = cmd(*args, **options)
ipalib/frontend.py:443: in __call__
ret = self.run(*args, **options)
ipalib/frontend.py:761: in run
return self.forward(*args, **options)
ipalib/frontend.py:782: in forward
return self.Backend.rpcclient.forward(self.name, *args, **kw)
ipalib/rpc.py:947: in forward
return self._call_command(command, params)
ipalib/rpc.py:924: in _call_command
return command(*params)
ipalib/rpc.py:1075: in _call
return self.__request(name, args)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _


self = 
name = 'certprofile_import'
args = (('caIPAserviceCert_mod',), {'all': False, 'description': 
'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion 
Default

policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
', 'ipacertprofilestoreissued': True, ...})

def __request(self, name, args):
payload = {'method': unicode(name), 'params': args, 'id': 0}
version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES)
payload = json_encode_binary(payload, version)

if self.__verbose >= 2:
root_logger.info('Request: %s',
 json.dumps(payload, sort_keys=True, 
indent=4))


response = self.__transport.request(
self.__host,
self.__handler,
json.dumps(payload),
verbose=self.__verbose >= 3,
)

try:
response = json_decode_binary(json.loads(response))
except ValueError as e:
raise JSONError(str(e))

if self.__verbose >= 2:
root_logger.info(
'Response: %s',
json.dumps(json_encode_binary(response, version),
   sort_keys=True, indent=4)
)
error = response.get('error')
if error:
try:
error_class = errors_by_code[error['code']]
except KeyError:
raise UnknownError(
code=error.get('code'),
error=error.get('message'),
server=self.__host,
)
else:
>   raise error_class(message=error['message'])
E   InternalError: an internal error has occurred




On 08/31/2015 03:25 PM, Fraser Tweedale wrote:

On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote:

On 08/18/2015 04:06 PM, Milan Kubík wrote:

On 08/11/2015 03:17 AM, Fraser Tweedale wrote:

On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kubík wrote:

On 08/05/2015 02:57 PM, Milan Kubík wrote:

Hi list,

I'm sending the test plan [1] for certificate profiles and preliminary
patches for it.
The plan covers basic CRUD test and some corner cases. I'm open to
more
suggestions.

More complicated tests involving certificate profiles will require the
code (and tests)
for CA ACLs merged, so it's not there at the moment.

There are some unfinished test cases in places I wasn't sure what the
result should be.
We need to iterate through these to fix it.


[1]:http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan

Cheers,
Milan

Hi all,

have you had some time to look at the code and proposal?
Today I want to write a basic CRUD test for the ACLs as well as a few
test
cases to check if the ACL is being enforced. It should make it into
wiki
today or by tomorrow. I'll send an update then.

Cheers,
Milan


Hi Milan,

I have reviewed the V4/Certificate_Profiles/Test_Plan.  Couple of
comments:

- Test case: Import profile with incorrect values
   - Expected result: refused with error.
   - A simple way to provoke this condition is to add a number to
 ``policyset.serverCertSet.list``.
   - A similar test case should exist for certprofile-mod.

- Test case: Delete default profile
   - As discussed elsewhere, expected result 

Re: [Freeipa-devel] [PATCH] Updated no of legacy permission in ipatests

[Tomas Babej]

On 09/03/2015 08:16 AM, Abhijeet Kasurde wrote:
> Ping
> 
> On 08/27/2015 10:37 AM, Abhijeet Kasurde wrote:
>> Hi All,
>>
>> This patch fixes bug - https://fedorahosted.org/freeipa/ticket/5264
>>
>> Thanks,
>> Abhijeet Kasurde
> 

ACK, the patch needs a minor rebase on master due to python3 refactoring.

-- 
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 0307] Server Install: print message that client is being installed

[Simo Sorce]

On Thu, 2015-09-03 at 10:19 +0200, Martin Basti wrote:
> On 09/02/2015 06:00 PM, Simo Sorce wrote:
> > On Wed, 2015-09-02 at 17:57 +0200, Martin Basti wrote:
> >> Client installation is done as "Restarting web server". This step
> >> deserve own message.
> >>
> >> Patch attached
> > I've seen various cases like this. And I can't understand why these
> > steps aren't embedded in the actual instance install steps that need the
> > restart (which implicitly also provide a message).
> >
> > In the promotion patchset I did move steps like this into the proper
> > instances, so I would prefer you do the same with the install path as
> > that is more appropriate.
> >
> > Simo.
> >
> 
> We need restart httpd after CA, DNS(optional) installation, so thats why 
> it is outside of httpd instance.

You need to restart httpd always after CA install as it changes the
proxy settings, but why do you need to restart it after DNS
installation ?

(I think it is fine to restart it twice if it is really needed after DNS
change).

> Client install has no own step yet, it is just call of ipa-client-install.

This is fine, ipa-client-install is another ball of wax.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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